Credentials You Carry

53.0 What this chapter gives you#

1. You will be able to describe the three-party model of issuer, holder and verifier, and say precisely which arrow in the old two-party model it removes.
2. You will be able to write out the required parts of a W3C Verifiable Credentials Data Model 2.0 credential and say which of the three securing mechanisms you are looking at when you see one.
3. You will be able to read a decentralised identifier, split it into its parts by the specification’s own grammar, and explain what resolving it does and does not prove.
4. You will be able to explain selective disclosure by salted hash exactly, including the disclosure format, the digest and the key binding token, using real computed values.
5. You will be able to state honestly what BBS signatures give you that SD-JWT does not, what they cost, and why the hardware in shipping phones is the reason the industry did not simply adopt them.
6. You will be able to walk through an over-eighteen proof that reveals nothing except the answer, and say which parts of it are deployed, which are research, and which are marketing.
7. You will be able to compute a credential’s position in a bitstring status list and explain the herd-privacy argument for the 131,072 minimum.
8. You will be able to describe an ISO/IEC 18013-5 mobile driving licence at the level of its actual data structures, and list four concrete ways it differs from a W3C verifiable credential.
9. You will be able to explain how a wallet stores keys, how a credential is bound to a device, and why cloning resistance is a hardware claim rather than a protocol claim.
10. You will be able to judge, case by case, whether a proposed verifiable credential deployment solves a real problem or reinvents a database lookup with extra steps.

For most of the history of computing, proving something about yourself online has worked the same way. You tell a system who you are. The system looks you up in its own records. It believes its records. Everything you can prove is a consequence of what somebody else has already written down about you, in a place you cannot see, at a moment you were not present for.

That model has a name in this book: the lookup. It is enormously successful and it is not going away. But it has costs. The checker must be able to reach the record-holder at the moment of the check. The record-holder learns every time somebody asks. And whatever facts it chooses to return are the facts the checker receives, needed or not.

Verifiable credentials propose a different shape. The office that knows something about you writes it down once, signs it, and gives it to you. You keep it. When somebody needs to know it, you show it to them, and they check the signature. The office is not consulted, does not know the transaction happened, and does not need to be online. Identity stops being a question you ask a database and becomes a document you present.

This chapter takes that claim apart. We start with the plain idea, which is genuinely simple and genuinely old, because it is how paper has worked for centuries. We then spend a long time on where the simple story misleads, because in this field the gap between promise and deployed reality is unusually wide. Then we go through the specifications with real field names, dates and numbers: the W3C data model, decentralised identifiers, two different mathematics for showing part of a document, zero-knowledge proofs of a single attribute, the mobile driving licence standard, and the awkward question of revocation.

One person carries the whole chapter. Ravi Menon was born on 2 September 2007, so on 17 August 2026 he is eighteen years, eleven months and fifteen days old. He holds a mobile driving licence from a state motor vehicle authority and wants to buy something he must be over eighteen to buy. Every construction in this chapter is applied to Ravi, so that you can see what changes and what does not. The law and the practical methods of checking age are chapter 54’s subject; here the age question is simply the smallest useful thing a credential can be asked to prove.

The plain version#

Two ways to check a stranger#

Imagine you run a small cinema and you must not sell a ticket for a certain film to anybody under eighteen.

There are two ways you could do this. In the first, you ask the customer their name and their national number, you ring the government office, and somebody there looks in the register and tells you whether that person is old enough. This works. It also means the office knows that this person, at this cinema, at this hour, tried to see this film. It means that if the line is down you cannot sell tickets. And it means the office decides how much to tell you, which in practice will be more than you needed.

In the second, the customer hands you a card made by the government office in a way that is hard to forge, saying when they were born. You look at it, you do the arithmetic, you hand it back. The office is not involved and does not know you exist.

The second way is how paper has always worked, and it is what verifiable credentials are trying to rebuild in software. The whole subject is the second way, done with mathematics instead of holograms.

The letter that cannot be altered#

Here is the piece of mathematics that makes it possible, and you only need one idea.

There is a kind of lock where the key that closes it and the key that opens it are different. An office keeps one of the pair secret and publishes the other. When the office writes something down, it uses its secret key to produce a short block of numbers that goes with the text, and anybody who has the published key can check that the block and the text match. If a single character changes, they no longer match.

That block of numbers is a signature. It says that the office and nobody else produced this text, because only the office had the secret key, and that the text has not been altered since, because any change breaks the match.

So an office can write “the person described here was born on 2 September 2007”, sign it, and hand it over. Anybody who trusts that office, and who has the office’s published key, can check the statement without ever contacting the office. The statement carries its own proof with it. This is what people mean when they say a credential is verifiable: not that somebody has verified it, but that anybody can.

Three people in the room#

Once you have signed statements you can carry, three roles appear, and keeping them separate is most of the subject.

There is the office that writes the statement and signs it, because it knows something about you as a matter of record and is willing to say so. Call it the issuer. There is you, who receive the signed statement, keep it, and decide when to show it and to whom. Call yourself the holder. And there is whoever needs to know, the cinema or the bank or the landlord or the website, who receive the statement and check it. Call them the verifier.

The important thing is what is not in that list. There is no line from the verifier back to the issuer at the moment of the check. In the telephone version the cinema talks to the government; in this version it does not. That single missing line is the whole claim of the technology, and everything else in this chapter is either a consequence of it or a place where it turns out not to be quite true.

A page with windows in it#

Paper has a defect that nobody minded until recently. It cannot be partly shown.

When Ravi hands over his licence to prove he is old enough, the shop assistant sees his exact date of birth, his full name, his address, his photograph, his licence number and what vehicles he may drive. The shop needed one fact and received about nine. Multiply that by every counter, hotel, delivery and rental, and the personal information that leaks out of ordinary life through over-showing is enormous. It is nobody’s fault; it is a property of the medium.

An electronic statement need not behave that way. Instead of signing the readable text, the office signs a list of scrambled fingerprints, one per fact, each calculated from the fact plus a random number that only you receive. A fingerprint reveals nothing about the fact it came from. To show one fact you hand over that fact and its random number, and the verifier recomputes the fingerprint and finds it in the signed list. For the facts you withheld, the verifier sees only fingerprints, which tell it nothing.

The result is a document with windows. The signature covers the whole page. You choose which windows to open. That is selective disclosure, and it is the first thing that a carried credential can do that a card in a wallet cannot.

Saying yes without saying why#

There is a stronger trick, and it sounds impossible the first time you hear it.

Suppose the office signed Ravi’s date of birth and never signed anything as convenient as “over eighteen”. Selective disclosure does not help: the smallest thing Ravi can open a window on is the date itself, and that is far more than the shop needs, because a date of birth is one of the strongest identifying facts about a person.

What Ravi wants to hand over is neither the date nor a promise, but a piece of evidence: something the shop can check by calculation, which proves that the signed document contains a date of birth earlier than 17 August 2008, and which reveals nothing else at all. Not the date. Not the name. Not the signature. Not even enough to recognize Ravi if he comes back tomorrow.

This is what a zero-knowledge proof is. The name is unhelpful and the idea is not. It is a calculation the holder performs, using the secret document as input, producing a result the verifier can test. If the statement is true the test passes; if it is false the holder cannot produce anything that passes, except with a probability so small it can be ignored. And the result carries no information beyond the truth of the statement.

For decades this was theory that ran too slowly to use. It is now fast enough on a phone, which is a genuinely recent change.

Taking a document back after you have handed it out#

Now the hard part, which the enthusiasts skip.

Paper credentials expire, and that is the only control the issuer really has. If the office cancels your licence today and the card in your pocket says it is valid until 2031, the card keeps working anywhere that only looks at the card. Signed electronic statements have exactly the same problem for exactly the same reason: once the office has signed and handed it over, the signature keeps checking out, and you cannot reach into somebody’s pocket and unsign a document.

So the issuer publishes a list saying which of its credentials are still good. Each credential carries a note saying “I am number 94,567 on the issuer’s list”, and the verifier fetches the list and looks at entry 94,567.

Notice what just happened. We removed the line from the verifier back to the issuer, and revocation put it back. Not the same line, and not as bad a one, because the verifier fetches a whole list rather than asking about one person. But it is a line, and everything interesting about revocation is how much information leaks along it.

Ravi buys a game#

Let us put all of it together in the simplest possible story, and then spend the rest of the chapter on what this story leaves out.

Ravi Menon, born on 2 September 2007, applied to his state motor vehicle authority, which checked his birth record and issued him a driving licence. It also placed a copy on his phone: a file containing his details, signed with the authority’s secret key, with each detail fingerprinted separately so individual facts can be shown alone. His phone generated a fresh secret of its own, and the authority wrote the matching public half into the signed file. That is what makes the file his rather than anybody’s: to use it you must also prove you hold the phone’s secret.

On 17 August 2026 Ravi is in a shop buying a game rated eighteen and over. The till displays a code. Ravi’s phone reads it and asks him: “This shop is asking whether you are over eighteen. Share?” He agrees. The phone sends three things: the signed file with only the over-eighteen window opened, the fact itself, and a fresh signature made with the phone’s own secret proving that this transmission came from this phone at this moment.

The till checks three things. That the authority’s signature over the file is good, using the authority’s published key. That the fingerprint of the disclosed fact appears in the signed list. That the phone’s fresh signature matches the public half written into the file. All three pass, and the till says “over eighteen: yes”. It never learned Ravi’s name, address or date of birth, and the motor vehicle authority never learned that Ravi was in a shop.

That is the plain version, and it is a fair description of what the technology can do. Now we take it apart.

Where the plain version stops being true#

Somebody still has to decide which offices to believe#

The plain version says the till checks the authority’s signature using the authority’s published key. Where did the till get that key, and why does it believe it belongs to the authority?

This is not a detail. It is the entire problem of identity, moved one step to the left. A signature proves that whoever held a particular secret key signed particular bytes, and nothing about who that was. To get from “this key signed it” to “the motor vehicle authority signed it”, the verifier needs a trusted list of issuers and their keys, maintained by somebody, kept current, and distributed to every till.

The honest version: verifiable credentials do not remove the need for a central trusted authority. They move it from the moment of the transaction to the moment of setup, and they change it from a database of people into a register of issuers. That is much smaller and much less sensitive, and it is a real gain. It is not the same as having no central party. In North America the register is explicit and named: the American Association of Motor Vehicle Administrators runs a Digital Trust Service, live since 15 April 2024 with Utah and Maryland participating, whose whole job is to say which issuing authorities a reader should trust.

You hold a copy, not the original#

The plain version says you hold your credential and decide who sees it. Both halves need qualifying.

You hold a copy. The issuer still has the record the credential was made from. A university that issues you a signed degree certificate has not forgotten that you have a degree. A motor vehicle authority still runs the licence register and still knows your address. And “decide who sees it” is bounded by the fact that you are usually not in a position to refuse: if the only way to open a bank account is to present four attributes, you present four attributes. The holder’s control is real at the level of the protocol and thin at the level of the negotiation.

The honest version: the model gives the holder control over the transmission, not over the collection and not over the demand. That is a genuine improvement over a system where data moves between organizations without you in the loop. It is not self-sovereignty, a term that was popular in this field between roughly 2016 and 2020 and that has quietly fallen out of serious use because it promised something the architecture never delivered.

Showing less is not the same as being unknown#

Selective disclosure limits what a verifier learns in one transaction. It says much less than people assume about what verifiers learn collectively.

Two problems. First, the signature itself is a fixed value: in the deployed salted-hash designs the issuer’s signature is handed to every verifier unchanged, so two verifiers who compare notes see at once that they saw the same credential, even if neither learned a name. Second, the facts you do reveal are often identifying on their own. A postcode, a date of birth and a sex identify a large fraction of a population uniquely, a result Latanya Sweeney established in the late 1990s and which chapter 10 works through properly.

The honest version: selective disclosure is about minimizing disclosure, not about achieving anonymity. Unlinkability, meaning that two presentations of the same credential cannot be recognized as coming from the same credential, is a separate and harder property that requires different mathematics, and the versions of that mathematics with the strongest guarantees are the ones the industry has largely not deployed. We compare them properly later.

Cancelling a credential brings the issuer back into the room#

The plain version admitted that revocation needs a published list. It did not say how much that costs.

If the verifier fetches the list at the moment of the check, the issuer learns that somebody checked, when, and from where; if the lists are small the issuer can narrow down who; and if the verifier caches the list, a revoked credential keeps working until the cache expires.

The honest version: revocation reintroduces a communication path from verifier to issuer, and every design here trades freshness against privacy and load. The bitstring approaches make the leak small by making the fetch coarse. They do not make it zero. Practitioners genuinely disagree about whether revocation lists or very short-lived credentials are the better answer.

“Decentralised” is a claim about one layer, and often not that layer#

Decentralised identifiers are the identifier scheme most associated with this technology, and the word in the name does a great deal of work that the specification does not do.

A decentralised identifier is a string you can look up to get a small document containing public keys. How you look it up depends on the method named in the string. Some methods use blockchains, some use peer-to-peer protocols, and the most widely deployed in practice, did:web, resolves by fetching a file over HTTPS from a domain name. Its security therefore rests on DNS and the web certificate system, the same centralized infrastructure that ordinary web identity rests on and that chapters 26 to 31 cover.

The honest version: the identifier format is decentralized in that no single registry issues the identifiers. The trust is as decentralized as the method you choose, which for the most popular method is not decentralized at all. That was substantially the complaint behind the formal objections filed in 2022, which the W3C Director overruled on 30 June 2022 while requiring the working group to produce interoperable standard methods. That work was still incomplete as of August 2026.

The wallet is a new single point of failure#

Move all of somebody’s credentials onto one device and you have concentrated risk in a way paper never did. Losing the only device that holds your identity, your driving entitlement, your professional registration and your right to work is worse than losing a wallet of cards, and so is having it stolen unlocked.

The honest version: the security of the whole model reduces to the security of a consumer phone and the quality of its recovery process. That is not a criticism of the cryptography, which is sound. It is an observation that the weakest link moved. Chapter 24 deals with recovery as a subject in its own right, and it is the single least solved problem in this area.

The paper it replaces was often not the problem#

The last and most uncomfortable one. A great deal of effort in this field has gone into building credential infrastructure for situations where nobody was actually struggling.

If a company already has your employment record in its own system, issuing you a signed credential about it and verifying it back against a trust registry is a more complicated way of doing a database lookup that was working. If verifier and issuer are the same organization, or have a direct contract, a signed credential adds ceremony and removes nothing.

The honest version: this is a good technology with a narrow zone of genuine advantage and a wide zone of enthusiastic misapplication. Being able to tell the difference is worth more than knowing the field names, and the chapter finishes on exactly that.

The technical version#

The three roles and the arrow that was removed#

The W3C Verifiable Credentials Data Model 2.0, published as a W3C Recommendation on 15 May 2025, defines the ecosystem in terms of four things: an issuer, a holder, a verifier and a verifiable data registry. The registry is whatever a verifier consults to obtain the identifiers, keys, schemas and status information it needs. It is deliberately abstract, because it can be a blockchain, a database, a distributed ledger, a government trust list, or a plain HTTPS endpoint.

              +----------------------------+
              |  verifiable data registry  |
              |  keys, schemas, status     |
              +----------------------------+
                 ^         ^          ^
          write  |         | read     | read
                 |         |          |
   +---------+   |   +----------+     |   +-----------+
   | issuer  |---+   |  holder  |     +---| verifier  |
   +---------+       +----------+         +-----------+
        |    issue          |     present       ^
        +------------------>|------------------>+

   Note: no arrow from verifier back to issuer at the
   moment of presentation. That is the whole claim.

Compare that with the federated model of chapters 40 to 43, where a relying party redirects the user to an identity provider and a token comes back. There the identity provider is present at every login, learns every relying party the user visits, and must be reachable. The three-party credential model deletes that participation: the issuer acts once, at issuance, and is then absent. Everything that follows is either machinery for making that absence work, or an admission of where it is imperfect.

Inside a verifiable credential#

A verifiable credential in the 2.0 data model is a JSON-LD object. JSON-LD is JSON with a vocabulary attached, so that the meaning of each property name is fixed by a published context document rather than by convention. That decision is the source of most of the arguments in this field and we will return to it.

The properties that matter, with the section of the Recommendation that defines each:

The first value of @context must be the string identifying the version 2 credentials context. The type array must include VerifiableCredential. The issuer is a URL or an object with an id that is a URL. The credentialSubject carries the claims. Section 4.12 requires that a conforming document be secured by at least one securing mechanism, which is where the three competing approaches come in.

Ravi’s licence, expressed in this model and stripped to essentials:

{
  "@context": ["https://www.w3.org/ns/credentials/v2"],
  "type": ["VerifiableCredential", "DriverLicenceCredential"],
  "issuer": "did:web:mvd.example.gov",
  "validFrom": "2026-01-14T09:00:00Z",
  "validUntil": "2031-09-02T00:00:00Z",
  "credentialSubject": {
    "id": "did:key:z6MkpTHR8VNsBxYAAWHut2Geadd9",
    "familyName": "Menon",
    "givenName": "Ravi",
    "birthDate": "2007-09-02"
  },
  "credentialStatus": {
    "id": "https://mvd.example.gov/status/3#94567",
    "type": "BitstringStatusListEntry",
    "statusPurpose": "revocation",
    "statusListIndex": "94567",
    "statusListCredential":
      "https://mvd.example.gov/status/3"
  }
}

Two media types are registered in section 6.2 and Appendix C: application/vc for a credential and application/vp for a presentation. A presentation is the envelope a holder wraps one or more credentials in when showing them, and it is the thing that carries the holder’s own signature.

The 2.0 model was not the first. Version 1.0 became a W3C Recommendation on 19 November 2019 and version 1.1 on 3 March 2022. The visible changes in 2.0 are that issuanceDate and expirationDate became validFrom and validUntil, and that the securing mechanisms were split out into separate specifications.

Three ways to secure the same credential#

This is the part practitioners most often get wrong, because the phrase “verifiable credential” names a data model and not a format on the wire. The same credential can appear in at least three quite different byte layouts, and they do not interoperate.

The first is Data Integrity, defined in Verifiable Credential Data Integrity 1.0, a W3C Recommendation of 15 May 2025. The signature goes inside the JSON object as a proof property with a type of DataIntegrityProof, a cryptosuite naming the algorithm, a proofPurpose, a verificationMethod pointing at the key, and a proofValue. Because the same information can be written in many equivalent JSON-LD forms, the document must first be canonicalized, in practice by converting it to RDF and applying RDF Dataset Canonicalization. That is the reason many engineers dislike the format: the signature depends on a graph normalization algorithm rather than on the literal bytes.

The second is JOSE and COSE, defined in Securing Verifiable Credentials using JOSE and COSE, also a W3C Recommendation of 15 May 2025. Here the credential is the payload of an ordinary JSON Web Signature or CBOR Object Signing and Encryption structure, which chapter 39 covers as a format in its own right. The bytes signed are the bytes transmitted, with no canonicalization. Section 6.1 registers six media types: application/vc+jwt, application/vp+jwt, application/vc+sd-jwt, application/vp+sd-jwt, application/vc+cose and application/vp+cose. Per section 3.1.3 the registered JWT claims iss, sub, exp, iat and cnf are used, nbf is not recommended, and the old 1.0 practice of a vc claim wrapping the credential is forbidden.

The third is SD-JWT, which is the selective disclosure construction and which section 3.2 of the JOSE and COSE specification incorporates. It gets its own treatment below because it is where most real deployment is happening.

There is a fourth thing which is not a W3C securing mechanism at all: the ISO/IEC 18013-5 mobile document, which is CBOR and COSE and X.509 from top to bottom and does not use the W3C data model. It has its own section later, and as of August 2026 it is winning in the field.

Decentralised identifiers: syntax, documents, resolution#

Decentralized Identifiers (DIDs) v1.0 became a W3C Recommendation on 19 July 2022. A version 1.1 exists and was at Candidate Recommendation Snapshot stage as of 5 March 2026; it had not reached Recommendation by August 2026.

The grammar in section 3.1 is short enough to quote in full:

did                = "did:" method-name ":" method-specific-id
method-name        = 1*method-char
method-char        = %x61-7A / DIGIT
method-specific-id = *( *idchar ":" ) 1*idchar
idchar             = ALPHA / DIGIT / "." / "-" / "_"
                     / pct-encoded
pct-encoded        = "%" HEXDIG HEXDIG

Note that method-char allows only lowercase letters and digits, so did:WEB:example.com is not a DID. Section 3.2 extends this to a DID URL, which adds a path, a query and a fragment in the ordinary URL manner, so did:web:mvd.example.gov#key-1 names a specific key inside a specific document.

Resolving a DID returns a DID document. Section 5.1.1 makes exactly one property required, id, which must equal the DID that was resolved. Everything else is optional: controller, alsoKnownAs, verificationMethod, service, and the five verification relationships authentication, assertionMethod, keyAgreement, capabilityInvocation and capabilityDelegation. The relationships matter because they say what a key is for. A key listed under assertionMethod may sign credentials; a key listed only under authentication may not.

{
  "id": "did:web:mvd.example.gov",
  "verificationMethod": [{
    "id": "did:web:mvd.example.gov#key-1",
    "type": "JsonWebKey",
    "controller": "did:web:mvd.example.gov",
    "publicKeyJwk": {
      "kty": "EC", "crv": "P-256",
      "x": "f83OJ3D2xF1Bg8vub9tLe1gHMzV76e8T",
      "y": "x_FEzRu9m36HLN_tue659LNpXW6pCyStikY"
    }
  }],
  "assertionMethod": ["did:web:mvd.example.gov#key-1"]
}

Resolution is specified separately. Decentralized Identifier Resolution v1 was at Candidate Recommendation Snapshot stage on 6 August 2026. It defines a single resolve() function taking the DID and a set of options and returning didResolutionMetadata, the didDocument and didDocumentMetadata. The options include accept for the desired representation and versionId or versionTime for a historical state of the document, which matters when checking a signature made two years ago against keys that have since rotated. Errors use the RFC 9457 problem-details format and include INVALID_DID, NOT_FOUND, METHOD_NOT_SUPPORTED and REPRESENTATION_NOT_SUPPORTED.

The critical sentence about resolution is this. Resolving a DID tells you which keys the controller of that DID currently asserts, and nothing about who the controller is. did:web:mvd.example.gov resolves by fetching a JSON file over HTTPS from that domain, so its security is DNS plus the web PKI. did:key encodes the public key directly in the identifier, so resolution is pure decoding and the key can never be rotated. Neither is a statement about a person.

Methods, and what the registry actually tells you#

The method name in the middle of a DID selects an entirely different system. The W3C publishes a Group Note listing known methods, most recently dated 12 August 2026, and it is long. Mozilla’s formal objection in 2022 described the situation as “delegating that to a registry of 50+ methods”, and it has grown a great deal since. [UNVERIFIED: the exact number of DID methods listed in the W3C DID Methods Group Note of 12 August 2026]

The practical consequence is that “we use DIDs” tells a reviewer almost nothing. The question is which method, and then all the ordinary questions about that method’s infrastructure. That is the interoperability complaint the Director acknowledged on 30 June 2022, requiring that the working group’s next charter “should address and deliver proposed standard DID method(s) and demonstrate interoperable implementations”.

It is also worth saying plainly that DIDs are optional. The European wallet framework, which chapter 51 covers, selects SD-JWT VC and the ISO mobile document and does not require DIDs. The mobile driving licence uses X.509. A verifiable credential can name its issuer with an ordinary HTTPS URL. The association between verifiable credentials and DIDs is historical rather than technical.

Selective disclosure by salted hash: SD-JWT exactly#

Selective Disclosure for JSON Web Tokens became RFC 9901, a Proposed Standard, in November 2025, by Daniel Fett, Kristina Yasuda and Brian Campbell. It is the mechanism behind almost all selective disclosure now being deployed outside the ISO world, and it is simple enough to describe completely.

A Disclosure is a base64url encoding of a JSON array. For an object property the array has three elements in order: a salt, the claim name, and the claim value (section 4.2.1). For an array element it has two: a salt and the element (section 4.2.2). The salt should contain at least 128 bits of cryptographically secure random data.

The issuer computes, for each selectively disclosable claim, the digest of the ASCII bytes of that base64url string, and puts the digest into an _sd array in the payload (section 4.2.4.1) instead of the claim itself. The hash algorithm is named in an _sd_alg claim, defaulting to sha-256 (section 4.1.1). Hidden array elements are replaced by an object with the single key ... holding the digest (section 4.2.4.2). Issuers may add decoy digests so that the number of entries in _sd does not reveal how many claims exist.

The wire format is a single string with tilde separators:

<JWT>~<Disclosure 1>~<Disclosure 2>~ ... ~<Disclosure N>~

The trailing tilde is required. When key binding is used, the last segment is not empty but a Key Binding JWT, and the whole thing is called an SD-JWT+KB. The KB-JWT has header typ of kb+jwt and must carry iat, aud, nonce and sd_hash, where sd_hash is the digest of everything before it. That binds the presentation to a particular verifier and a particular challenge, and stops a captured presentation being replayed elsewhere.

The credential profile on top of this is SD-JWT-based Verifiable Digital Credentials. As of August 2026 it was still an Internet-Draft, draft-ietf-oauth-sd-jwt-vc-18 of 3 August 2026, in the IESG state “AD Evaluation::Revised I-D Needed”. This is worth stating plainly: the format the European wallet framework has selected, and which a great deal of production software already implements, was not yet an RFC in August 2026. It defines the media type application/dc+sd-jwt and a header typ of dc+sd-jwt, with vc+sd-jwt accepted transitionally. It requires a vct claim naming the credential type, and it forbids iss, nbf, exp, cnf, status and vct from being selectively disclosable, while permitting sub and iat to be.

Ravi’s licence as an SD-JWT, with real values#

Here is the construction carried out for real. These digests were computed for this book with SHA-256 over the ASCII bytes of each Disclosure, exactly as RFC 9901 section 4.2.4.1 requires, and you can reproduce them.

Take one claim, the boolean age_over_18, with the salt eI8ZWm9QnKPpNPeNenHdhQ. The JSON array is:

["eI8ZWm9QnKPpNPeNenHdhQ", "age_over_18", true]

Base64url encoded, that Disclosure string is 63 characters:

WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImFnZV9vdmVyXzE4IiwgdHJ1ZV0

The SHA-256 digest of those 63 ASCII bytes, base64url encoded without padding, is 43 characters:

vWOFmlm-0uNWtEwcQ_68HPqts9ttJxVo6ee9hRahQJc

Doing the same for six claims gives the following table. Every digest here is real.

The issued credential’s payload contains none of the six claims, only the six digests:

{
  "iss": "https://mvd.example.gov",
  "vct": "https://mvd.example.gov/vct/licence/1",
  "iat": 1768382400,
  "exp": 1946937600,
  "_sd_alg": "sha-256",
  "_sd": [
    "vt3p8AW8ESRTxjWfKgePsC24PH5uh5CD4XgN2hl9Kdw",
    "0pX_Xfgb6dWluG2QtdN26PiQclPq_1HkAK_55Zs48hM",
    "MaZeirDID2g59Bt3xi_VsbV5u01nCdY8Y-9LQTqj21k",
    "vWOFmlm-0uNWtEwcQ_68HPqts9ttJxVo6ee9hRahQJc",
    "W3Fw8Fn_XjLPOZyHUf_Uz2Ip8ya4Kaic-d7oI5iLbIc",
    "u3_SDyJjAEPUrm2XYplvj27FNrumrdyXW3wfrf5ic5g"
  ],
  "cnf": { "jwk": { "kty": "EC", "crv": "P-256",
                    "x": "...", "y": "..." } }
}

At the till, Ravi presents the JWT, exactly one Disclosure, and a Key Binding JWT:

eyJhbGciOiJFUzI1NiIsInR5cCI6ImRjK3NkLWp3dCJ9.eyJpc3Mi
Li4ufQ.SIG~WyJlSThaV205UW5LUHBOUGVOZW5IZGhRIiwgImFnZV
9vdmVyXzE4IiwgdHJ1ZV0~eyJhbGciOiJFUzI1NiIsInR5cCI6Imt
iK2p3dCJ9.eyJub25jZSI6Ii4uLiJ9.SIG2

The verifier decodes the one Disclosure, computes its SHA-256, finds vWOFmlm-0uNW... in the _sd array, and therefore knows the issuer signed the statement that this subject is over eighteen. It sees five other digests and learns nothing from them. It checks the KB-JWT signature against the key in cnf, and the nonce against the one it just generated.

Now the honest part. Every verifier Ravi shows this credential to receives the same JWT with the same issuer signature and the same cnf key, so two verifiers comparing logs can match on the signature bytes alone. The salted-hash construction gives selective disclosure and no unlinkability whatever. The standard mitigation is batch issuance: the issuer gives the holder many credentials with different salts and different holder keys, and the wallet uses each once. That works, at the cost of issuance volume and of the issuer seeing how fast you consume them, and it is the approach the European framework adopted after a public argument that chapter 51 sets out.

Selective disclosure by unlinkable proof: BBS#

There is a construction that does give unlinkability, and it is older than the problem it is now being asked to solve.

The scheme was implicitly proposed by Dan Boneh, Xavier Boyen and Hovav Shacham at CRYPTO 2004 in their paper “Short Group Signatures”, and cast as a standalone signature by Jan Camenisch and Anna Lysyanskaya at the same conference. A provably secure variant, BBS+, was published by Man Ho Au, Willy Susilo and Yi Mu at SCN 2006. The lineage goes back further: David Chaum described credentials that could be shown without identifying the holder in “Security without Identification: Transaction Systems to Make Big Brother Obsolete”, Communications of the ACM volume 28 number 10, October 1985, pages 1030 to 1044. Stefan Brands built a rival construction, and Microsoft bought his company Credentica in March 2008, publishing the result as U-Prove under the Open Specification Promise in March 2010. IBM’s Idemix took the Camenisch-Lysyanskaya line. None of them achieved wide deployment.

BBS works on pairing-friendly elliptic curves. The issuer signs a vector of messages, one per attribute, producing a single constant-size signature. The holder never shows it. Instead the holder runs a proof generation procedure that outputs a fresh zero-knowledge proof of knowledge of a valid signature over the disclosed messages, revealing nothing about the undisclosed ones and nothing about the signature. Two proofs from the same signature are indistinguishable from two proofs from different signatures.

The specification is “The BBS Signature Scheme”, an IRTF Crypto Forum Research Group draft. As of August 2026 the latest version was draft 10 of 8 January 2026 and it had expired without being replaced; it remains an active research group document and is not an RFC. That status matters and is routinely misrepresented in vendor material. Two ciphersuites are defined over BLS12-381, one using SHA-256 and one using SHAKE-256. The four operations are Sign, Verify, ProofGen and ProofVerify.

The sizes are exact and worth knowing. For BLS12-381 a compressed group element is 48 octets and a scalar is 32 octets. A signature is one group element and one scalar, so 80 octets regardless of how many attributes it covers. A proof is three group elements and four-plus-U scalars, where U is the number of undisclosed messages, so its length in octets is 272 plus 32 times U:

The W3C cryptosuite that wires this into the data model is Data Integrity BBS Cryptosuites v1.0, defining the bbs-2023 cryptosuite. As of 7 April 2026 it was a Candidate Recommendation Draft, not a Recommendation, and its section 4 features, credential-bound pseudonyms and blind signing, were marked at risk pending the corresponding IETF work reaching RFC status.

SD-JWT and BBS compared without marketing#

Both give selective disclosure. They are not otherwise comparable, and the honest comparison is uncomfortable for both sides.

The decisive line is the last. Selective disclosure by salted hash uses ordinary ECDSA over P-256, which every secure element in every shipping phone has performed in hardware for a decade. BBS needs pairing operations on BLS12-381, which no mainstream phone secure element does. That means a BBS holder key must live in software, which breaks the hardware binding that issuers of government identity documents insist on. This is not a preference; it is why the deployments went the way they went.

Against that, the cryptographers are right that salted hashes cannot deliver unlinkability. In June 2024 sixteen named cryptographers, including Jan Camenisch, Anna Lysyanskaya, Bart Preneel and Carmela Troncoso, wrote to the European Commission arguing exactly this about the European wallet framework. Chapter 51 covers that argument and its outcome. The dispute is real, it is between serious people, and as of August 2026 it is unresolved: the implementers shipped salted hashes with batch issuance as a mitigation, and the cryptographers continue to say that is not the same thing.

Zero-knowledge proofs of an attribute: the over-eighteen proof#

Selective disclosure lets Ravi reveal a field the issuer already computed. If the issuer signed only birth_date and never signed age_over_18, selective disclosure has nothing to offer. A zero-knowledge proof does.

Conceptually the proof is over a statement with three parts, all of which the verifier can state precisely and none of which reveals anything on its own:

1. There exists a document D and a signature S such that S is a valid signature over D under the public key of issuer I.
2. The field named birth_date inside D, parsed according to the document’s format, is a date earlier than 2008-08-17.
3. The field named device_key inside D is the public half of a key pair whose private half was used to sign this session’s challenge.

The holder knows D and S. The verifier knows I, the date threshold and the challenge. The holder produces a proof; the verifier checks it; the verifier learns that the three statements hold and nothing else. It does not learn the date of birth. It does not learn the signature. It cannot recognize the same holder returning tomorrow, because a fresh proof is generated each time and proofs of the same statement are indistinguishable.

Statement 2 is why this is harder than it sounds. Proving a range property about a number is standard; proving one about a field buried inside a CBOR document that has been hashed and signed means the proof system must model the parsing and the hashing too, which historically made the proofs far too slow for a phone.

That changed. In 2024 Matteo Frigo and abhi shelat published “Anonymous Credentials from ECDSA”, Cryptology ePrint Archive report 2024/2010, which builds a proof system around sumcheck and the Ligero argument system with specialized circuits for ECDSA on P-256 and efficient arguments about SHA-256. Their stated result is that a proof about an ECDSA signature can be generated in around 20 milliseconds, and that a full proof for an ISO mdoc presentation flow runs in a few hundred milliseconds on mobile devices. Crucially, their construction requires no change to the issuer, no change to the signature algorithm and no change to device hardware, because it proves a statement about a perfectly ordinary ECDSA signature over a perfectly ordinary mdoc.

Google open-sourced an implementation, the Longfellow ZK library, on 3 July 2025 under the Apache 2.0 licence, described in an IETF draft named draft-google-cfrg-libzk, and stated that it was undergoing two independent security reviews. The company had announced zero-knowledge age proofs in Google Wallet earlier in 2025 and named a partnership with Sparkasse for European age assurance.

Where does that leave us as of August 2026? Established fact: the mathematics works, the code exists, the performance is adequate on a phone, and the approach requires nothing of the issuer. Active research: the security analysis of these very new proof systems, which is why the reviews were commissioned. Marketing claim: any statement that zero-knowledge age proofs are a solved and deployed default. They are neither. The trade-off nobody advertises is proof size, since sumcheck-and-Ligero arguments are very much larger than the 64-byte ECDSA signature they wrap. [UNVERIFIED: the exact proof sizes reported in the Frigo and shelat benchmarks]

Revocation: status lists and the arithmetic of herd privacy#

Bitstring Status List v1.0 became a W3C Recommendation on 15 May 2025. The design is deliberately crude and the crudeness is the point.

The issuer maintains a bitstring. Each credential is assigned an index into it. A bit set to 1 means the status applies. Section 2.1 defines four statusPurpose values: revocation, which is permanent; suspension, which is reversible; refresh, meaning an updated credential is available; and message, for arbitrary application-defined states. Entries are one bit by default, but statusSize may be larger, in which case a statusMessage array must define what each value means. The bitstring is compressed with GZIP per RFC 1952 and then multibase-encoded as base64url without padding, and it is served inside a verifiable credential of its own.

Section 3.2 sets a minimum of 131,072 entries unless an ecosystem specification says otherwise. That is 2 to the power 17, chosen so the uncompressed bitstring is exactly 16,384 bytes.

Ravi’s credential carries "statusListIndex": "94567". Finding his bit is integer arithmetic: 94,567 divided by 8 is 11,820 with remainder 7, so his status lives in byte 11,820 of the decompressed bitstring, at bit position 7 counting from the most significant end.

The privacy argument is called herd privacy, and it is this: because the verifier downloads the whole list, the issuer learns only that somebody checked some credential in a population of at least 131,072, not which one. Section 6.1 says as much, and adds the caveat that this holds only if the number of credentials actually issued is large. A list of 131,072 entries with 400 credentials issued into it provides an anonymity set of 400, not 131,072, and the issuer knows it.

The compression behaviour matters in practice, because a list that is mostly zeroes compresses to almost nothing. These figures were computed for this book by GZIP-compressing a 131,072-bit list with revocations placed at random positions:

So a verifier fetching a status list is typically downloading a few hundred bytes to a few kilobytes. The load is trivial. The leak is the fetch itself: the issuer’s server sees an IP address, a time, and which list was requested. If the issuer partitions its population across lists in any meaningful way, by region or by cohort or by issuance batch, the request narrows the herd considerably. That is a real design discipline, not a theoretical worry.

The IETF parallel is Token Status List, draft-ietf-oauth-status-list, at draft 21 of 21 June 2026 and in the RFC Editor queue as of August 2026. It is the one SD-JWT VC uses, and it differs in detail: statuses of 1, 2, 4 or 8 bits, values 0x00 VALID, 0x01 INVALID and 0x02 SUSPENDED, a status_list claim carrying a URI and an index, delivery as a JWT or CWT, and DEFLATE with the ZLIB wrapper rather than GZIP.

The alternative that avoids all of this is to stop revoking and start expiring. Issue credentials valid for twenty-four hours, refresh them silently in the background, and a revoked credential dies within a day with no list, no fetch and no leak. The cost is that the wallet must be online regularly and the issuer sees every refresh, which is a different leak in a different place. Practitioners genuinely disagree about which is better, and the correct answer depends on how sensitive the fact of a check is compared with the fact of a refresh.

The mobile driving licence: ISO/IEC 18013-5#

Now the other family, which shares almost none of the above and is further ahead in deployment.

ISO/IEC 18013-5:2021, “Personal identification, ISO-compliant driving licence, Part 5: Mobile driving licence (mDL) application”, was published in September 2021 and runs to 152 pages. As of August 2026 a second edition was in progress: ISO/IEC DIS 18013-5 reached stage 40.60, close of voting, on 27 March 2026, at 176 pages. The add-on part that covers presenting an mDL over the internet rather than face to face is ISO/IEC TS 18013-7, whose second edition was published in May 2025 at 42 pages, superseding the first edition of October 2024.

Everything is CBOR, and signatures are COSE. There is no JSON, no JSON-LD, no linked data and no DID anywhere in it.

A credential, called an mdoc, has two halves. The IssuerSigned half contains the namespaced data elements and an issuerAuth structure. The DeviceSigned half is produced at presentation time and contains deviceAuth, which is either a deviceSignature or a deviceMac.

Selective disclosure works by salted digest, the same idea as SD-JWT with different spelling. Each data element becomes an IssuerSignedItem with four fields: digestID, random, elementIdentifier and elementValue. The random field is a fresh salt for that element. The issuer computes digests of the encoded items and puts them in the valueDigests map of a MobileSecurityObject, whose fields are version, digestAlgorithm, valueDigests, deviceKeyInfo, docType and validityInfo. That security object is what gets signed, as a COSE_Sign1, and that signature is issuerAuth.

IssuerSignedItem = {
  "digestID"          : uint,
  "random"            : bstr,
  "elementIdentifier" : tstr,
  "elementValue"      : any
}

MobileSecurityObject = {
  "version"        : tstr,
  "digestAlgorithm": tstr,
  "valueDigests"   : ValueDigests,
  "deviceKeyInfo"  : DeviceKeyInfo,
  "docType"        : tstr,
  "validityInfo"   : ValidityInfo
}

The namespace for the driving licence data is org.iso.18013.5.1. Table 5 in clause 7.2 lists the mandatory elements: family_name, given_name, birth_date, issue_date, expiry_date, issuing_country, issuing_authority, document_number, portrait and driving_privileges. Optional elements include resident_address, nationality, birth_place and signature_usual_mark. And critically, the standard defines age_over_NN elements: pre-computed booleans for any threshold the issuer chooses to include, so that age_over_18 and age_over_21 can be disclosed without disclosing birth_date at all. AAMVA’s own namespace adds further elements including age_in_years.

That last decision is the pragmatic answer to the whole zero-knowledge question: if the issuer simply signs the boolean, no clever mathematics is needed to disclose it. The costs are that the issuer must decide the thresholds in advance, that the booleans go stale as the holder ages, and that the pattern of which booleans are true is itself slightly identifying near a birthday.

Presentation face to face has three stages. Device engagement passes an ephemeral public key and the available transports, by QR code or NFC tap. Data retrieval runs over Bluetooth Low Energy, NFC or Wi-Fi Aware. Session keys are derived by HKDF from an ephemeral ECDH agreement, with separate keys per direction, and the session is protected with AES-GCM. The exchange is peer to peer; there is no server in the middle and no requirement for either device to be online.

Trust is X.509, not DIDs. An issuing authority operates an IACA, an Issuing Authority Certificate Authority, whose root signs document signer certificates, and those sign the mobile security objects. Annex B gives the profiles: document signer certificates carry an extended key usage of 1.0.18013.5.1.2 and a maximum validity of 457 days after their “not before” date, and the IACA root a maximum of 20 years. Readers obtain the acceptable IACA roots from a trust list, in North America AAMVA’s Digital Trust Service.

Deployment as of 2026 is real and uneven. In mid-January 2026 AAMVA listed 21 United States states plus Puerto Rico as having implemented an mDL. Apple’s Wallet supported driver’s licences or state IDs in 14 states plus Puerto Rico as of August 2026, having added Montana, North Dakota, West Virginia and Illinois during 2025 and Arkansas in May 2026, and having launched internationally for the first time in Japan. The United States Transportation Security Administration states that digital IDs can be used at more than 250 airports.

How an mdoc differs from a W3C verifiable credential#

These are not two flavours of one thing. They are two ecosystems with different encodings, different trust models and different governance, and a great deal of confusion follows from treating them as interchangeable.

Four further differences matter. The mdoc has a fixed registered data dictionary, so two implementations interoperate on meaning without negotiation, while the W3C model has an open vocabulary that is more flexible and needs more agreement. The mdoc specifies the transport down to the radio protocols; the W3C model says nothing about transport. The mdoc was designed first for offline face-to-face use, the W3C model first for online. And the ISO documents are paid standards, which has an underrated effect: you cannot read the normative text of the winning credential format without buying it.

Wallet security: key storage, binding, cloning resistance#

A credential that anybody can copy and use is a bearer token, and bearer tokens are the thing chapter 38 warns about at length. Everything in this section exists to stop that.

Key storage first. Modern phones contain a separate security processor: Apple’s Secure Enclave, present since the iPhone 5s in 2013, and on Android the hardware-backed Keystore with StrongBox, available since Android 9 in 2018. A key generated inside such a processor never leaves it. The application can ask for a signature and receive one; it cannot read the private key, and nor can the operating system or malware with root. Both platforms also support key attestation, in which the processor signs a statement, chaining to a manufacturer root, that a named key was generated inside genuine hardware. Chapter 23 covers the same machinery for passkeys.

Binding second. A credential is bound to a device by the issuer writing the public half of a device-resident key into the signed credential, and by the verifier insisting on a fresh signature from the matching private half. In SD-JWT VC this is the cnf claim in the payload and the KB-JWT at presentation, with nonce, aud and sd_hash tying the proof to this verifier and this moment. In an mdoc it is deviceKeyInfo inside the MobileSecurityObject and deviceAuth inside DeviceSigned, computed over a session transcript that includes the device engagement and the reader’s ephemeral key, so the proof cannot be lifted from one session into another. OpenID for Verifiable Credential Issuance goes one step further at issuance time: its JWT proof type carries a key_attestation in the header, so the issuer can require evidence that the key it is about to bind lives in hardware of a stated quality.

Cloning resistance third, and this is where honesty is required. Nothing in either protocol prevents copying the credential file. The file is just bytes; a backup contains it; a forensic image of the phone contains it. What prevents the copy from being used is that the copy does not contain the private key, because the private key was never in the file to begin with. Cloning resistance therefore is not a property of the credential format at all. It is a property of the hardware that holds the key, and of whether the verifier bothers to check the device signature.

That last clause is the practical failure mode. A verifier that checks the issuer’s signature and skips the device signature has built a system where a screenshot works, which is why the mDL standard makes device authentication mandatory.

There is a further subtlety in the mdoc device authentication choice. deviceAuth may be a deviceSignature, an ECDSA signature over the session transcript, or a deviceMac computed from a key agreed between the device key and the reader’s ephemeral key. The MAC option exists because some secure elements support key agreement but not signing arbitrary data. The privacy difference is significant: a signature is transferable evidence that this device took part, which the reader can show to a third party, while a MAC can be forged by the reader itself and so proves nothing to anyone else. That difference deserves an explicit decision.

Two things hardware does not fix. It does not stop a holder consenting to a request they should have refused, which is a hard user interface problem. And it does not survive loss of the device, which returns us to recovery, the subject of chapter 24.

Getting credentials in and out#

A format is not a system. Two protocols move credentials, and one browser interface is arriving to sit in front of them.

Issuance uses OpenID for Verifiable Credential Issuance, built on OAuth 2.0 and reusing its authorization code flow, token endpoint and pre-authorized code grant. The wallet obtains an access token, calls a credential endpoint, and supplies a proof of possession of the key it wants the credential bound to; the jwt proof type has header typ of openid4vci-proof+jwt and may carry a key_attestation, a signed statement that the key lives in hardware of a stated quality. Presentation uses OpenID for Verifiable Presentations, which reached OpenID Foundation Final Specification status on 10 July 2025, and which can carry SD-JWT VCs, W3C presentations and ISO mdocs alike.

The browser interface is the W3C Digital Credentials API, a Working Draft of 12 August 2026 from the Federated Identity Working Group. It exposes presentation through navigator.credentials.get() and issuance through navigator.credentials.create(), with a protocol field selecting the exchange protocol; section 5 names openid4vp-v1-unsigned, openid4vp-v1-signed, openid4vp-v1-multisigned, org-iso-mdoc for ISO/IEC TS 18013-7:2025, and openid4vci-v1. This is the piece that decides whether credentials become a normal part of the web or stay inside vendor apps, and in August 2026 it was still a Working Draft.

Where the model earns its keep, and where it does not#

Here is the judgement, stated as directly as the evidence allows.

It genuinely helps when the verifier cannot reach the issuer: a roadside check with no signal, a border post, a rural shop, a hospital during an outage. Offline verification of a signed document is something a database lookup structurally cannot do, and it is the strongest argument in the field. It genuinely helps when the fact of the check is sensitive. If a person proves an entitlement to a benefit, a health status or a professional registration, and the issuing body should not learn where and when, only the carried-credential model removes that observation. For some categories of person that is a safety property, not a privacy nicety.

It genuinely helps when the issuer and verifier are in different jurisdictions or sectors with no plausible route to a shared database: a degree issued in one country and checked by an employer in another is the canonical case, and it motivated the whole field. It genuinely helps when over-showing is the actual harm, age checking being the clearest example, and chapter 54 takes that subject on properly.

It does not help when the issuer and the verifier are the same organization; signing a statement to yourself and verifying your own signature is theatre. It does not help when the verifier must contact the issuer anyway, to check a live balance or a real-time watchlist, because once the connection is required the offline argument evaporates and a query returns better data. It does not help when the fact changes faster than the credential can be reissued, since a credential is a snapshot and anything whose status flips hourly should be a query.

It does not help when the hard part is knowing which issuers to trust, and nobody has agreed to run the register. A great many pilots have died at exactly this step, having built beautiful issuance and presentation flows with no governance underneath them. The technology has no answer to this and does not claim to.

A final observation about which parts of the stack are carrying the deployment. The successful systems in 2026 are the mobile driving licence, which uses CBOR, COSE and X.509 and no DIDs, and the European wallet, which uses SD-JWT VC and mdoc and no DIDs. The decentralised identifier layer, which absorbed the largest share of the field’s attention between 2016 and 2022, is the layer production deployments have most often left out. That is not a prediction that DIDs will fail; it is where the evidence stood in August 2026, and it should temper any reading of the enthusiasm in this area.

53.98 Common wrong ideas#

Wrong: A verifiable credential is verified by the issuer when it is presented. Right: It is verified by the verifier alone, by checking the issuer’s signature against a key the verifier already holds or can fetch from a trust list; the only routine case where the verifier contacts the issuer’s infrastructure is fetching a revocation status list, and that fetch is designed to be coarse enough not to identify the credential being checked.

Wrong: Verifiable credentials remove the need for a central authority. Right: They remove the need for a central database of people at the moment of the transaction and replace it with a register of acceptable issuers and their keys, which somebody must still run, fund and keep current; AAMVA’s mDL Digital Trust Service, live since 15 April 2024, exists for exactly this reason.

Wrong: Selective disclosure means the verifier cannot link your presentations. Right: In the salted-hash constructions that are actually deployed, SD-JWT under RFC 9901 and the ISO mdoc, the issuer’s signature and the holder’s bound public key are identical in every presentation, so two verifiers who compare records can trivially link them; unlinkability requires a different construction such as BBS, or the operational mitigation of issuing batches of single-use credentials.

Wrong: BBS signatures are a standard you can rely on today. Right: “The BBS Signature Scheme” is an IRTF Crypto Forum Research Group draft, at draft 10 of 8 January 2026 and expired as of August 2026, and the W3C cryptosuite that uses it, Data Integrity BBS Cryptosuites v1.0, was a Candidate Recommendation Draft of 7 April 2026 with its pseudonym and blind-signing features marked at risk; the blocking practical issue is that phone secure elements do ECDSA on P-256 and not pairings on BLS12-381.

Wrong: A DID proves who somebody is. Right: Resolving a DID returns a DID document listing the keys its controller currently asserts, and nothing more; did:web resolves by fetching a file over HTTPS and so inherits the trust properties of DNS and the web certificate system, while did:key encodes the key in the string itself and therefore cannot rotate or revoke, so the security question is always about the specific method and never about DIDs in general.

Wrong: A mobile driving licence is a W3C verifiable credential. Right: ISO/IEC 18013-5:2021 defines a CBOR document signed as a COSE_Sign1, with issuer trust in X.509 certificates from an IACA, its own registered dictionary in the org.iso.18013.5.1 namespace and its own Bluetooth, NFC and Wi-Fi Aware transports; it shares the salted-digest idea with SD-JWT and essentially nothing else with the W3C stack.

Wrong: Proving you are over eighteen without revealing your birth date requires zero-knowledge proofs. Right: ISO/IEC 18013-5 defines age_over_NN boolean elements that the issuer signs directly, so the wallet can disclose age_over_18 alone by ordinary selective disclosure; zero-knowledge proofs are needed only when the issuer did not pre-compute the threshold you need, and the Frigo and shelat construction of 2024 exists precisely so that no change to issuers or devices is required in that case.

Wrong: Putting a credential in a hardware-backed wallet makes it uncopyable. Right: The credential file is copyable by anyone with a backup or a forensic image; what is not copyable is the private key held in the Secure Enclave or in StrongBox, so cloning resistance depends entirely on the verifier actually checking the device signature or MAC against the key bound into the credential, and a verifier that skips that check has built a system a screenshot defeats.

Wrong: Revocation status lists tell the issuer nothing. Right: Bitstring Status List v1.0 requires a minimum of 131,072 entries so that a fetch reveals only that somebody in a large population was checked, but the issuer’s server still sees the requesting address, the time and which list was asked for, and the anonymity set is the number of credentials actually issued into that list rather than its nominal length, so partitioning a population across many small lists destroys the property the design exists to provide.

53.99 Chapter summary in 20 lines#

1. The three-party model replaces a lookup against the issuer’s database with a signed document that the holder stores and presents, removing the verifier-to-issuer connection at the moment of the check.
2. The W3C Verifiable Credentials Data Model 2.0 became a W3C Recommendation on 15 May 2025, following version 1.0 on 19 November 2019 and version 1.1 on 3 March 2022.
3. A conforming credential requires @context, type, issuer and credentialSubject, may carry validFrom, validUntil and credentialStatus, and must be secured by at least one mechanism under section 4.12.
4. The three W3C securing mechanisms are Data Integrity 1.0 with RDF canonicalization, JOSE and COSE with six registered media types, and SD-JWT, all specified separately from the data model.
5. Decentralized Identifiers v1.0 became a W3C Recommendation on 19 July 2022 after the Director overruled formal objections from Google, Mozilla and one other member on 30 June 2022, on condition that the group deliver interoperable standard methods.
6. A DID is did: followed by a lowercase method name and a method-specific identifier, and resolving it returns a DID document whose only required property is id, with keys in verificationMethod and their permitted uses given by relationships such as assertionMethod.
7. DID resolution is specified separately, was at Candidate Recommendation Snapshot stage on 6 August 2026, and defines a single resolve() function returning resolution metadata, the document and document metadata.
8. The security of a DID is the security of its method, so did:web rests on DNS and the web certificate system while did:key cannot rotate keys at all, and “we use DIDs” tells a reviewer nothing on its own.
9. Selective Disclosure for JSON Web Tokens became RFC 9901, a Proposed Standard, in November 2025, replacing each hidden claim with a SHA-256 digest of a salted, base64url-encoded Disclosure array listed in an _sd array.
10. An SD-JWT is transmitted as the JWT and its Disclosures joined by tildes with a trailing tilde, and an SD-JWT+KB ends instead with a Key Binding JWT of typ kb+jwt carrying iat, aud, nonce and sd_hash.
11. SD-JWT VC, the profile the European framework selected, was still an Internet-Draft in August 2026 at draft 18 of 3 August 2026, defining the media type application/dc+sd-jwt and a mandatory vct claim.
12. Salted-hash selective disclosure gives no unlinkability, because the issuer’s signature and the bound holder key are identical in every presentation, and the deployed mitigation is batch issuance of single-use credentials.
13. BBS, from Boneh, Boyen and Shacham at CRYPTO 2004 and made provably secure as BBS+ by Au, Susilo and Mu at SCN 2006, produces a fresh unlinkable proof each time, with an 80-octet signature and a proof of 272 plus 32 octets per undisclosed message on BLS12-381.
14. BBS is not deployed at scale because phone secure elements perform ECDSA on P-256 and not pairings on BLS12-381, so a BBS holder key cannot be hardware-bound, and its specification remained an expired IRTF draft in August 2026.
15. A zero-knowledge age proof asserts that a valid issuer signature exists over a document whose birth date falls before a threshold and whose device key signed this session, revealing nothing else, and Frigo and shelat’s 2024 construction generates ECDSA proofs in around 20 milliseconds.
16. Bitstring Status List v1.0, a W3C Recommendation of 15 May 2025, sets a minimum of 131,072 entries, compresses with GZIP and multibase, and defines the purposes revocation, suspension, refresh and message.
17. Index 94,567 lies in byte 11,820 at bit 7, and a 131,072-entry list compresses to 51 bytes when empty and about 3.2 kilobytes at 2 per cent revoked, so the cost is trivial and the residual leak is the fetch itself.
18. ISO/IEC 18013-5:2021, published in September 2021 with a second edition at close of voting on 27 March 2026, defines the mobile driving licence as CBOR signed with COSE, with issuer trust in X.509 certificates from an IACA.
19. The mdoc discloses selectively through IssuerSignedItem salted digests in a MobileSecurityObject, defines age_over_NN booleans so a threshold can be shown without a birth date, and binds to the device through deviceKeyInfo and deviceAuth.
20. The model earns its keep when the verifier cannot or should not contact the issuer, when the fact of the check is sensitive, and when over-showing is the harm, and earns nothing when issuer and verifier share a database or nobody will run the register of trusted issuers.

Chapter sources: W3C Verifiable Credentials Data Model v2.0, Recommendation of 15 May 2025, sections 1.3, 4.2, 4.3, 4.5, 4.7 to 4.12, 6.2 and Appendix C, with its predecessors the Recommendations of 19 November 2019 (v1.0) and 3 March 2022 (v1.1); W3C Verifiable Credential Data Integrity 1.0, Recommendation of 15 May 2025, sections 2.1, 2.4.3 and 3.1; W3C Securing Verifiable Credentials using JOSE and COSE, Recommendation of 15 May 2025, sections 3.1.1, 3.1.3, 3.2 and 6.1; W3C Bitstring Status List v1.0, Recommendation of 15 May 2025, sections 2.1, 3.2, 3.3 and 6.1; W3C Decentralized Identifiers (DIDs) v1.0, Recommendation of 19 July 2022, sections 3.1, 3.2 and 5.1.1, with the Director’s Decision on the DID 1.0 Formal Objections of 30 June 2022; W3C Decentralized Identifiers (DIDs) v1.1, Candidate Recommendation Snapshot of 5 March 2026; W3C Decentralized Identifier Resolution v1, Candidate Recommendation Snapshot of 6 August 2026; the W3C Group Note “DID Methods” of 12 August 2026; W3C Data Integrity BBS Cryptosuites v1.0, Candidate Recommendation Draft of 7 April 2026, sections 3.4.5, 4.1, 4.2 and 4.3; W3C Digital Credentials API, Working Draft of 12 August 2026 from the Federated Identity Working Group, sections 5, 7 and 7.3.1; RFC 9901, “Selective Disclosure for JSON Web Tokens”, Proposed Standard, November 2025, by Daniel Fett, Kristina Yasuda and Brian Campbell, sections 4, 4.1.1, 4.2.1 to 4.2.4.2 and 4.3; draft-ietf-oauth-sd-jwt-vc-18 of 3 August 2026, sections 2.1, 2.2.1, 2.2.2.3 and 4.3, in IESG state AD Evaluation; draft-ietf-oauth-status-list-21 of 21 June 2026, in the RFC Editor queue; draft-irtf-cfrg-bbs-signatures, “The BBS Signature Scheme”, draft 10 of 8 January 2026, IRTF Crypto Forum Research Group, sections 3.5.4, 3.6.1 and 7.2; RFC 9457, RFC 1950, RFC 1951 and RFC 1952; ISO/IEC 18013-5:2021, Part 5 Mobile driving licence (mDL) application, first edition September 2021, 152 pages, clause 7.2 Table 5, clauses 8.3 and 9.1 and Annex B, with ISO/IEC DIS 18013-5 at stage 40.60 on 27 March 2026 at 176 pages; ISO/IEC TS 18013-7:2025, second edition May 2025, 42 pages, superseding ISO/IEC TS 18013-7:2024 of October 2024; the AAMVA mDL Implementation Guidelines version 1.6 of July 2026 and the announcement that AAMVA’s mDL Digital Trust Service went live on 15 April 2024 with Utah and Maryland; OpenID for Verifiable Presentations 1.0, approved as an OpenID Final Specification on 10 July 2025, and OpenID for Verifiable Credential Issuance 1.0, Appendix F on proof types; David Chaum, “Security without Identification: Transaction Systems to Make Big Brother Obsolete”, Communications of the ACM volume 28 number 10, October 1985, pages 1030 to 1044; Dan Boneh, Xavier Boyen and Hovav Shacham, “Short Group Signatures”, CRYPTO 2004, pages 41 to 55, with Camenisch and Lysyanskaya at the same conference, and Au, Susilo and Mu, “Constant-Size Dynamic k-TAA”, SCN 2006, pages 111 to 125; Tessaro and Zhu, “Revisiting BBS Signatures”, EUROCRYPT 2023, ePrint 2023/275; Matteo Frigo and abhi shelat, “Anonymous Credentials from ECDSA”, ePrint 2024/2010, and the Google Longfellow ZK library open-sourced on 3 July 2025 under Apache 2.0 with the IETF draft draft-google-cfrg-libzk; Microsoft’s acquisition of Credentica in March 2008 and the release of U-Prove under the Open Specification Promise in March 2010; the founding of Rebooting the Web of Trust in San Francisco in November 2015; the June 2024 open letter “Cryptographers’ Feedback on the EU Digital Identity’s ARF” signed by sixteen cryptographers; AAMVA jurisdiction data summarized in January 2026 giving 21 states plus Puerto Rico, Apple newsroom material of November 2025 with subsequent state additions to August 2026, and the United States Transportation Security Administration statement that digital IDs are accepted at more than 250 airports.