TamgaNetwork

How Tamga works

Architecture: how Tamga runs

The concepts from the previous pages come together here: a handful of small services, public signed lists, a wallet that holds the documents, and a verifier that decides in five steps.

What lives where

The rule is simple: everything personal stays with the person; only non-personal trust data is public.

In the wallet · on the phone

  • Credentials: diploma, student card, identity, ticket
  • Device keys — one per copy
  • History of what was shared, with whom

Public · signed lists

  • Institutions, certificates, statuses
  • What each institution may issue, and when
  • Verifiers and the fields they may ask for
  • Revocation lists and the anchor log

No personal data in lists, logs or ledger

Not even a hash of it. Revocation lists hold one random position per credential copy, not names; addresses never encode the institution. Service logs record what happened, never who it happened to.

The services

Trust layer
trust.tamga.networkTrust lists — signed lists of institutions, verifiers and wallet providers, with a public anchor logETSI TS 119 612
schemas.tamga.networkCredential types — public catalogue of credential types and their definitionsSD-JWT VC Type Metadata
status.tamga.networkRevocation lists — revocation and suspension, published at fixed times; no personal dataToken Status List
Services
issuer.tamga.networkIssuing service — issues credentials for each institution on its own path, with the institution's keyOpenID4VCI
console.tamga.networkInstitution Console — institutions manage issuing, revocation and statistics—
verify.tamga.networkTamga Verify — hosted verifier and the “Sign in with Tamga” kit for websitesOpenID4VP
id.tamga.networkIdentity service — remote identity check (document + liveness) and the identity credential—
wallet.tamga.networkWallet provider — vouches that a wallet is the genuine app on a genuine device—
  • One issuing service, many institutions. Every institution is a tenant on its own path. Differences between institutions are configuration, never custom code. In the pilot the signing key moves to the university.
  • Identity check is separate. Only the identity service talks to the identity-verification provider. It issues an identity credential and keeps no photos afterwards — only an opaque, hashed record (a subject reference and a document-number hash). Universities match your record through that credential, not through the provider.
  • Genuine wallets only. The wallet provider signs a short-lived attestation for real wallet apps; issuers refuse to issue without it.

The five-layer check

Every verification runs the same pipeline, in the same order, and stops at the first failure. Each step has a permanent code, so a “rejected” always says why.

Verification pipeline
T0
request and answer belong together (nonce, audience, encryption)
A · format
signature, certificate chain, device proof, hidden fields intact
B · type
document type known, definition hash matches the catalogue
C · trust
issuer authorized for this type on the issue date (trust list)
D · status
not revoked or suspended; revocation list fresh and anchored
E · policy
every requested field present, nothing beyond the verifier's scope
→ outcome
ACCEPTED · REJECTED (with the failing step) · INDETERMINATE (could not check)

“Could not check” is not “fake”

If a list cannot be reached or is out of date, the answer is INDETERMINATE, shown separately from REJECTED. The difference between “this diploma is fake” and “I cannot check right now” decides whether someone is hired.

Lifecycles

  • Revocation is published at a fixed interval, never ad hoc, so the timing of a revocation reveals nothing about a person.
  • Suspending an institution stops new issuance at once; documents issued earlier stay valid, because authorization is judged on the issue date.
  • Copies run out by design; the wallet asks before it fetches fresh copies — it never refreshes silently.
  • Nothing is erased from the lists: every change is a new, signed version with its history.

Principles

  • Privacy and security by design — selective disclosure, a separate copy per verifier, keys that never leave the device.
  • Open standards — SD-JWT VC, ISO 18013-5 mdoc, OpenID4VCI/VP, X.509, IETF Token Status List, ETSI trust lists.
  • Algorithm agility — algorithms are named in every signed object and can be replaced without changing the architecture.
  • Ledger when it adds something — trust lists today; a permissioned Besu/QBFT ledger once at least two independent operators join (why).