TamgaNetwork

Concepts

Credentials: X.509, SD-JWT VC and mdoc

A verifiable credential is a document with a digital seal: a diploma, a student card, an identity document, a ticket. This page explains who is identified how, what a credential contains, and how it travels.

Who is identified, and how

  • Institutions are identified by X.509 certificates chained to a national root authority — the same approach as the EUDI Wallet, and one regulators can read. The institution’s identifier is derived from its certificate and is listed in the trust list.
  • People have no global identifier. Each copy of a credential is bound to a key that lives on your phone. The wallet keeps several copies and gives each verifier a different one, so two verifiers cannot match you by comparing what they received.
  • Your national ID number exists only inside your identity credential, and is shared only when a request asks for it and you approve.

What about DIDs?

Decentralized Identifiers (DIDs) are common in the W3C credential world. Tamga uses X.509 for institutions because the EU’s EUDI architecture does, and because certificates already have legal standing. A did:web bridge for interoperability is planned; it is not needed to issue or verify.

Two formats, one data model

  • SD-JWT VC (IETF) — the main format, for online presentation: websites, employers, institutions. Each field is hidden behind a salted hash and revealed only if you approve it.
  • ISO 18013-5 mdoc — the mobile driving licence format, for close-range and age checks. Today the identity credential also comes as an mdoc: an age check receives age_over_18 and nothing else.

The document type is a stable name such as urn:tamga:edu:DiplomaCredential:1; its definition sits in a public catalogue, and every credential carries a hash of that definition.

An SD-JWT VC diploma (decoded, shortened)
{
  "iss": "https://issuer.tamga.network/example-university",
  "vct": "urn:tamga:edu:DiplomaCredential:1",
  "vct#integrity": "sha256-…",
  "iat": 1790000000,
  "cnf": { "jwk": { … } },
  "status": { "status_list": {
    "idx": 48213,
    "uri": "https://status.tamga.network/…" } },
  "_sd": [ "…", "…", "…" ],
  "degree_title": "…"
}
vct#integrity
hash of the type definition in the catalogue
cnf.jwk
the device key of this copy
_sd
hidden fields: salted hashes only
degree_title
revealed only if you approve
header · x5c
the university's X.509 certificate chain

How a credential travels

Issuer

OpenID4VCI · 10 copies

Wallet

keys on the device

Verifier

OpenID4VP · checks A–E

  • Issuance (OpenID4VCI). The institution shows a QR code; the PIN is shown on the same screen but never sent inside the link. Or the wallet starts from the institution directory and proves your identity first. The wallet receives ten copies, each bound to a different device key.
  • Presentation (OpenID4VP). The verifier’s request is signed with its registered certificate; the wallet checks it against the trust list, shows what is asked, and sends an encrypted answer with only the approved fields plus a proof that the key is on this phone.
  • Checks. Signature and device proof, document type, issuer authorization on the issue date, revocation status, and freshness of the data — then one of three answers: accepted, rejected or indeterminate.

Key point

The verifier never contacts the issuer. It needs the issuer’s certificate status (from the signed trust list) and the revocation list (published by the issuer at a fixed interval and cached). A copied screenshot fails: it carries no device proof.

Next: how to share less data when presenting a credential.