Tamga Network

Chapter 7 · 2/5

Becoming a verifier

Registration, an access certificate and what may be asked of a person: the verifier's path.

6 min

Selective disclosureFour fields of a credential, each with its own digest; only the over-18 fact is revealed, the birth date stays hidden.fields in the credentialover 18#a3f9…18+: yesbirth date#7c21…hiddenfull name#e04b…hiddendocument no#19d6…hiddenwhat the verifier sees

An employer wants to see an applicant's diploma, a hotel a guest's identity, a concert gate a ticket, a website that a user is over 18. Anyone who asks for these from a person's wallet is, on the network, a verifierThe party that requests a credential from a person and checks it: an employer, a bank, a hotel, a website..

Trust lists are public: anyone can check the signature on a credential. But to ask a person's wallet for data, a verifier must register. The reason is simple: the wallet has to know who is asking and what they may ask for.

Two ways

  • The hosted verifier.You use Tamga Verify, the network's reference verifier: you add a button to your site and it does the rest. Results and values are given to you only, and only once.
  • Your own software. You verify on your own server with the open-source packages.

Registration is the same either way.

Step by step

  1. Application.Only legal entities register. The EU's common registration data set is used: official name, registration number, address, contact, a description of the service, whether it is a public body, whether it uses an intermediary and its data protection authority.
  2. A purpose for each use.You state why you ask and give your privacy policy: "ticket at the concert entrance", "diploma for a job application".
  3. Field review. The fields you want are reviewed against data minimisationThe principle of asking only for the data a transaction really needs.. For an age check, "over 18" is enough, not the date of birth.
  4. Access certificate. You receive an access certificateA certificate proving the verifier's identity and domain name; used to sign requests. that proves your institution and your site's domain name. Every request you send to a wallet is signed with it.
  5. Registration certificate. For each use, a registration certificate valid for up to 12 months is produced. The wallet compares your request with it.
  6. Conformance tests.Signed requests, the verification steps, the "cannot be verified right now" result on a stale list and not asking beyond scope are tested.
  7. Entry into the list. Your registration is added to the trust list; wallets recognise you.

How long does it take? That depends on the institution's preparation.

What the person sees

The consent screen shows the verifier's registered name, its purpose and the requested fields. If a hosted verifier is used, it is shown as the "intermediary". If the person approves, only the requested data goes; if not, nothing does.

Summary

  • Every institution that asks a wallet for data registers; only legal entities can.
  • Permitted fields follow data minimisation; requests are signed with an access certificate.
  • The consent screen shows who asks, for what and why; only what the person approves is shared.

Go deeper

Technical details and binding rules: