The issuer / holder / verifier model lies at the heart of wallet-based credentials.
This is meant as a high level introduction to some of the fundamentals of the model. It tries to stay agnostic to specific implementation details such as credential formats, methods of credential transportation, DIDs, etc. If you already know all about those, you won’t learn much here!
Key terms
Issuer
Issuers create verifiable credentials and transmit them to a holder.
An issuer has a set of private keys, and a related set of public keys. When issuing a credential, one of these keypairs’ private key is used to sign the credential, the associated public key is stored in a verifiable data registry.
Holder
Holders retain verifiable credentials in a digital identity wallet. They receive presentation requests from verifiers, and send to them in response a verifiable presentation.
The holder is the pivotal role in the Issuer / Holder / Verifier model. It is their choices of which issued credentials to accept, and which presentation requests to respond to (and how) that places them at the heart of the model.
Verifier
Verifiers make presentation requests of holders, and verify the data that the holder transmits to them in a verifiable presentation. They do this by checking the cryptographic signatures of verifiable presentations, using the public keys associated with the credentials.
Typical use-cases
Standard
Issuer, Holder and Verifier are separate entities.
At a glance Issuing authorities issue credentials to holders. Verifiers that trust those holders and wish to consume their issued credentials may do so, as long as they have access to the verifiable data registry containing the issuer’s keys and metadata.
An issuing authority is any issuer with a set of holders who desire claims signed by it, and a set of verifiers that wish to consume those claims.
Closed-Ecosystem
Issuer and Verifier are the same entity. Holder is distinct.
At a glance The issuer of the credential issues credentials which their own service(s) will request the presentation of. Access to the verifiable data registry is limited to only the issuer and their own verification services.
Particularly useful in workforce settings.
Self-Asserted
Issuer and Holder are the same entity. Verifier is distinct.
At a glance The issuer of the credential is the holder to whom the credential is issued. Most useful in the case a holder wants to make self-asserted claims about themselves, though it’s possible the subject(s) of the credential may be any person or thing.
While it’s possible to sign a self-asserted credential, verifiers have little reason to verify it (or trust it for anything more than an opinion or preference) having in effect just received it from the issuer.
Standard use-case scenario
Alice has completed her Driving Theory test after many weeks practise and revision. She passes, and the examination centre presents her with a QR code to scan with her digital identity wallet that contains claims including her test score and date of test.
It’s signed by the testing centre’s private key. Their public key is available from their website, which acts as their verifiable data registry. It uses a schema common to all driving examination centres, which agreed it to encourage the use of digital credentials in place of old paper printouts that people kept losing.
When Alice goes for her practical test, the instructor first asks her to present her theory certificate.
The practical test centre knows the schema of the credential it wishes to accept, and trusts the examination centres, as they’re both members of the same governance framework for driving tests, operated by the Driving and Vehicle Licensing Agency.
Once the certificate is presented and verified the instructor knows to continue with the practical test.
- Practical driving centre trusts a large set of theory examination centres, of which Alice’s centre was one.
- The examination centre’s website acts as a basic verifiable data registry from which to retrieve that centre’s public key.
- The practical driving centre may have already retrieved the key ahead of time – it knows the set of issuers that it trusts, so may have pre-acquired the key or already had it cached.
Closed-ecosystem scenario
Bob recently got a new job at a government agency. As part of his onboarding, he went through a series of ID verification checks, each of which issued him a verifiable credential (a set of standard-use cases) which he can reuse with different services. The agency then requested him to present these credentials, and after their verification issued him a government agency employee credential. This credential contains his employee number, as well as details of his role, and what access rights he has throughout the building.
This credential is signed by the government agency, and presented to access areas of the building throughout the day that have restricted access.
As the government agency is the only service that ever needs to verify this specific credential, they don’t publish their verification data registry in a way that’s externally accessible.
- Verifiable data registry isn’t accessible outside of the agency
- The government agency issued credential and claims within it have no value outside of the agency
- Bob can still use the ID verification service issued credentials elsewhere, as those don’t have the same closed-ecosystem restriction
Self-asserted credential scenario
Carol has a set of preferences that she always uses when she signs up to new services and games. She always tries to get the username or character name DarkCarol, and she always chooses dark themes over light themes when there’s a choice.
Some services and games allow for self-asserted credentials to be accepted during registration to speed up the process of configuring the account for the user. One such credential’s schema contains fields for username and theme preference, so Carol issues herself with this credential. As these are self-attested claims, she doesn’t worry about signing the credential or having to store keys for verifiers to access.
There’s no other authority for Carol’s preference of her preferred theme or username than herself! And the verifier has no reason to doubt the truth of the claim, because each time it’s presented, it was done so by the user.
When she registers for services that accepts these claims, she presents this credential alongside other required credentials that are signed by third party issuing authorities, such as proof of address. In this way, registration forms allow for a mix of user preferences and verifiable data when setting up an account.
- Carol is making claims about herself.
- She doesn’t sign the credential, or care about verifiers being able to check the signatures.
- Most verifiers wouldn’t bother for such credentials even if they could!
- Self-asserted credentials can be used in conjuncture with standard use-case credentials to accept user preferences and opinions
Ancillary terms
Subject
The person or thing that a verifiable credential is about. They are generally – though not always – the holder to whom the credential is issued.
Claim
An individual attribute pertaining to a subject. Taking the form of key-value pairs. Generally the keys are a string, and the values a string, number, date, etc.
When forming presentation requests and verifiable presentations, all claims from a given credential may be requested and presented (full disclosure), a subset of claims (partial disclosure), the choice of which claims to expose up to the holder (selective disclosure), or the result of a predicate executed across a set of claims (zero-knowledge proof).
Digital Identity Wallet
A repository for a holder’s verifiable credentials. Often taking the form of a mobile app, and/or a cloud-based service. Sometimes conflated with payment and crypto wallets.
A wallet and its operator (typically the subject of credentials stored within the wallet) perform the role of the holder. Wallets are so significant in terms of how users interact with credential that when speaking generally about the topic I use the term wallet-based credentials.
Verifiable Data Registry
The location in which public keys, and other useful data such as credential schemas, or revocation registries may be found. The accessibility of a verifiable data registry its keys, are important in determining which verifiers are able to verify credentials from a given issuer.
Presentation Request
A request that a verifier transmits to a holder, requesting the presentation of a set of credentials that fulfil some criteria.
Verifiable Presentation
The holder’s response to a presentation request. It will be formed from data derived from the verifiable credentials in the holder’s wallet.
Credential Format
A specific format of a verifiable credential. Each credential format has its own set of features, and sometimes distinct terminology.
Credential Schema
A description of the set of claims a given verifiable credential should/must/may contain, including the key names and the associated data type of the values.
Revocation Registry
A registry containing revocation information about a set of verifiable credentials issued by an issuer.
Selective Disclosure
A holder’s ability to choose which claims of a verifiable credential are returned in their verifiable presentation. Not supported by all credential formats.
Zero-knowledge proof (zkp)
Disclosing information about the contents of a credential, without exposing the claims themselves. For example, answering a request for presentation that answers the question “Are you over 18?” without exposing an actual DOB. Not supported by all credential formats.
Resources
Articles on this site that mention topics relating to the model will be categorised under wallet-based credentials.
If you’d like to learn more about how implementations of the issuer / holder / verifier model work, check out some of the links below.
General Topic Books
Self-Sovereign Identity: Decentralized digital identity and verifiable credentials by Alex Preukschat and Drummond Reed
Specifications
Credentials
ISO-18013-5 and ISO-18013-7 at ISO
The Verifiable Credentials Data Model at W3C
AnonCreds at Hyperledger
Communication and Identification
Decentralised Identifiers (DIDs) at W3C
DIDComm Messaging at DIF
OpenId for Verifiable Credentials (OID4VC) at OIDF
With thanks to Kian Momtahan, for reviewing drafts of this Fundamentals piece.