Self-Sovereign Identity and Distributed Ledger / Blockchain
Lets start with details of the underlying blockchain technology, Self-Sovereign Identity concept and its potential.
Claims, Proofs and Attestations are important concepts of an identity.
An identity claim is an assertion made by the person, business or a thing. Such as "My name is Antony and my date of birth is 1 Jan 1901"
A proof is some form of document that provides evidence for the claim. Such as photocopies of passports, birth certificates, and utility bills.
An attestation is when a third party validates that according to their records, the claims are true. For example a University may attest to the fact that someone studied there and earned a degree.
There is an updated version of this article at my medium blog
https://medium.com/@ealtili/self-sovereign-identity-and-distributed-ledger-blockchain-f15937f2b2ed
1 Introduction
1.1 Bitcoin / Blockchain / Distrubuted Ledger
Bitcoin was introduced as a crypto currency with blockchain technology. It introduced the concept as a distributed storage that ensures integrity of the data and solves an integral trust issue. Blockchain consists of a cryptographically linked list of blocks, which allows only to append blocks. New blocks are added and linked after they have been verified from Blockchain nodes in the network. This process ensures the integrity because blocks in the Blockchain cannot be changed.
The blockchain was introduced as part of the peer-to-peer crypto currency Bitcoin. If a user wants to use Bitcoin, user needs to have a wallet. User manages his/her account using this wallet. User can make transactions such as buying goods and paying with Bitcoin using wallet. To perform such a transaction, the user has to transfer the right amount of bitcoins to the seller. Bitcoin utilize blockchain as transaction register to keep record of all transactions. A blockchain is a cryptographically linked list of blocks where each block consists of transactions, the hash value of the previous block and a nonce. A transaction consists of input and output amount of bitcoins as well as the address of the sender and receiver. Bitcoin uses public key cryptography where the public key represents the address of a user. Bitcoin is a public-permissionless blockchain, which means that anybody can host a copy of the Bitcoin blockchain. Miners are Special self-appointed entities of the Bitcoin peer-to-peer network, collecting transactions and try to solve a cryptographic problem. Solving this problem serves the proof-of-work that ensures the validity of the transactions in the block. The cryptographic problem of the proof-of-work consists of finding the right hash value of a block that starts with the predefined prefix. Miners are using special hardware to calculate the hash values. A nonce is added to the calculation and increased each time another hash results. To calculate the proof-of-work, a few quintillion or more hash values have to be calculated. After the proof-of-work was successfully calculated, the miner broadcasts the block to the p2p network. Every miner in the network verifies the calculation and if it is correct, the block is added to the blockchain. This approach increases the transaction security and trust because the whole block is verified. Additionally, the blockchain solves a general trust issue by allowing Different independent miners are verifying a new block. There is no trust relationship between the different miners required.
Miners are motivated to do mining by receiving a incentive from the Bitcoin network. This incentive should increasingly motivate miners to buy better mining hardware. Only the first one who finished calculating the proof-of-work for a block receives the related incentive. This incentive is created by sum up the transaction fees. A transaction fee is charged indirectly when processing a transaction. It appears indirectly because the bitcoin transaction output is slightly lower than the input and the difference is the fee for the miner. This system motivates thousands of miners in the world to calculate the proof-of-work. Because each miner has a copy of the blockchain and verifies each new broadcasted block, no trusted central authority is required that observes the blockchain and its activity. The incentive for calculating the proof-of-work for one block is now 12.5 bitcoins and changes with the active number of miners. The cryptographic problem becomes more complex after a certain time, which should motivate miners to buy stronger hardware. The provided incentive motivates thousands of miners doing their job and invest into computing power. A known problem with the proof-of-work is the 51% attack. This attack describes the case if there is one miner who holds 51% of the computation power of the whole Bitcoin network. This miner could double spend bitcoins as well as invalidate other transactions and potentially prevent people from sending bitcoins. This attack is not a theoretical problem, it can become real when the big mining pools start incorporating with each other and become the dominant mining power. Which is the case of Bitcoin Cash, Bitcoin Gold and Ethereum are all suffered from 51% attack.
Blockchain is an append-only, ordered and replicated log of transactions. Blockchain technology is used as crypto currencies, e-Voting, Identity or as decentralized domain name service (DDNS) etc. Distributed ledger is a decentralized database of records stored and replicated across many servers, which communicates to ensure most accurate and up to date records of transactions are maintained. Distributed ledger relies on similar principles of consensus mechanism as blockchain. A DLT can be considered a first step towards a blockchain, but importantly it won’t necessarily construct a chain of blocks and not necessarily append only. Cryptographic signing and linking groups of records in the ledger, to form a chain is what sets blockchain apart from DLT.
1.2 Digital Identity
Digital identities, are simplified digital representations of things including people. Digital identity consists of a set of attributes related to an identity. Identity management is management of digital identities and their corresponding data. Identity management built on the distributed ledger or blockchain technology would enable a decentralized identity model, which reduces the centralization and trust issues for certain use cases.
1.3 Self-Sovereign identity (SSI)
Self-Sovereign identity model tries to remove the trust issue that comes with identity management. SSI tries to give the user fully control over his/her own data. The usage of different online services requires an efficient digital identity management approach. These identities often contain sensitive personal data. It is important to know about how and where these sensitive data are stored and who can access it. The four main identity models are:
Isolated Identity Model
Isolated Identity Model is the combination of the service provider (SP) and the identity provider (IdP), which means that the SP manages the user’s identity data as well as their credentials. In this case, the users authenticates themselves directly at the SP.
Central Identity Model
Central identity model separates the IdP from the SP. This separation is the main difference and advancement because the identity data are stored at the IdP. When a user wants to access an online service, she has to first authenticate herself at the IdP and afterwards the identity data are transferred to the SP. In this model, the user does not have any control over her own identity data. An example for this scenario is using Facebook because the user does not have control over her own data stored at Facebook.
User-Centric Identity Model
User-centric model stores the user’s identity data in the user’s domain. This domain could be a secure token such as a smart card. Sharing identity data of a user requires explicit user consent. An example for a use case scenario where this model is used is the Bank or Citizen Card.
Federated Identity Model
Federated identity distributes identity data across multiple IdPs instead of storing it in one central place. Multiple IdPs provide the required identity data to access a service. These IdPs are working together in a federation, which requires a trust relationship between the IdPs. Federated IdPs share a user’s common identifier. This model can be used to realize Single-Sign on (SSO). SSO would be the authentication subset of federated Identity Management.
Self-sovereign identity Model
In a Self-Sovereign identity (SSI) model, user fully owns and controls own data. In A SSI system:
- Each user has to have the full control over her data
Each user must have full control over own identity data. This includes not only what identity data are being stored but also who has access to these data. The user should be able to add or import identity attributes as well as delete or revoke them at her leisure. Also, all access of identity data of a user should be logged for later verification.
- Ensure security and privacy of user’s identity data
All identity data have to be stored and processed in a highly secure manner. Additionally, the user’s privacy has to be preserved. For instance, unlinkability between the user wallet and identity data increases the user’s privacy.
- Fully portability of the data
User should be able to use identity data wherever they want.
- No trust in a central authority (*)
- Ensure data integrity (*)
- Transparency of the identity data is maintained (*)
The blockchain/distributed ledger technology is a suitable fit for these requirements. User decides what kind of data are going to be stored in the ledger and who is going to access it.
1.4 SSI Architecture
The architecture of a Self-Sovereign identity system based on the blockchain/dlt technology. The blockchain/dlt offers the possibility to realize a system without semi-trusted parties such as central certificate authorities (CAs) or registration authorities (RAs). Only public or permissionless blockchains provide a fully semi-trust less environment. If a blockchain is private or permissioned, only authorized parties have access to the ledger, which requires at least some kind of trust relationship to these entities. Even though authorized parties are independent of each other, trust in the chosen parties or in the selection process of becoming a trusted party is still necessary. Independent authorities should host a copy of the ledger that helps reducing the required trust.
A simple use case is the citizen of a country A can import their identity data using the existing identity infrastructure. Identity nodes are used to import qualified identity data into the user’s ledger. A citizen should be able to use her smart phone to access or share her identity data wherever they want where each identity’s data access is logged.
A software on a phone or computer is an “identity wallet” where identity data would be stored on device. Users can choose a human-memorable name for their identity. Then the platform converts the name to a unique identity called DID (decentralized identifiers). Decentralized Identifiers (DIDs) are a new type of identifier for verifiable, "self-sovereign" digital identity. DIDs are fully under the control of the DID subject, independent from any centralized registry, identity provider, or certificate authority. DIDs are URLs that relate a DID subject to means for trustable interactions with that subject. DIDs resolve to DID Documents — simple documents that describe how to use that specific DID. Each DID Document may contain at least three things: proof purposes, verification methods, and service endpoints. Proof purposes are combined with verification methods to provide mechanisms for proving things. For example, a DID Document can specify that a particular verification method, such as a cryptographic public key or pseudonymous biometric protocol, can be used to verify a proof that was created for the purpose of authentication. Service endpoints enable trusted interactions with the DID controller.
A simple example of a Decentralized Identifier (DID) did:example:123456789abcdefghi
Identity wallet with a self-generated identification number derived from public key, and a corresponding private key.
Each DID record is assigned with a public-private key pair where the signatures of the documents can be created using the private key and the signature can be verified using the public key. A corresponding public key is published in the metadata under ‘publicKey’. Each DID is associated with a separate DID method specification which is specific to a ledger or network. A DID method specifies the set of rules related to registration, resolution, modification, and revocation.
Minimal self-managed DID Document
{
"@context": "https://w3id.org/did/v1",
"id": "did:example:123456789abcdefghi",
"authentication": [{
// used to authenticate as did:...fghi
"id": "did:example:123456789abcdefghi#keys-1",
"type": "RsaVerificationKey2018",
"controller": "did:example:123456789abcdefghi",
"publicKeyPem": "-----BEGIN PUBLIC KEY...END PUBLIC KEY-----\r\n"
}],
"service": [{
// used to retrieve Verifiable Credentials associated with the DID
"type": "VerifiableCredentialService",
"serviceEndpoint": "https://example.com/vc/"
}]
}
At this stage, user created a self-sovereign identity. User then use this identity, along with identity claims, and get attestations from relevant authorities. User can use attested claims as identity information.
Since the ledger is public, it should not expose any Personally Identifiable Information (PII) directly on the ledger. To achieve the privacy of the public ledger, only the following items are stored in the ledger:
DIDs - A globally unique identifier that does not require a centralized registration authority because it is registered with distributed ledger technology or other form of decentralized network
Public keys - known to everyone and a private or secret key known only to the recipient of the message.
Service endpoints - Enables interaction with the identity owner via an associated agent
Proofs - Hashed or zero-knowledge proof artifacts that enable identity validators, identity owners, and relying parties to prove the validity period of that particular information
The above four basic pieces of data represent the identity owner through the off-ledger agents.
Off-Ledger Storage
The first additional part is the off-ledger storage. Storing sensitive data in the blockchain might not be a good idea even though if these data are encrypted. The problem that occurs by storing data in the blockchain is that these data cannot be modified or deleted anymore afterwards. This might be an important feature in some cases but not when dealing with sensitive data. In the SSI system, person related data are stored off-ledger only a unique identifier is stored in the blockchain. This special identifier is cryptographically linked to the off-ledger data storage. Different storage services such as cloud storages can be used as off-ledger storage.
Verifiable Claims and Zero Knowledge Proofs
A claim becomes a verified claim if there is proof of the claim. Indy supports cryptographically secure verifiable claims as follows. Let’s think Alice wants to prove her medical license to the hospital where she works at.
- a) If Alice is a doctor registered under the Doctor’s Association, Alice asks the association to send a verifiable claim to the hospital to prove the validity of her medical license.
- b) Then the Doctor’s Association creates a DID on the ledger with a claim schema with the public key P.
- c) Then the Doctor’s Association creates a document that shows the validity of Alice’ medical license and signs the document with the private key of the P. Then the signed document (or its digest) is added to the ledger as a transaction under the DID of the Doctor’s Association.
- d) Then the hospital verifies the signed document using public key P of the Doctor’s Association and makes sure that the document is signed by the Doctor’s Association.
In the physical world, a credential might consist of:
- Information related to the subject of the credential (for example, a photo, name, and identification number)
- Information related to the issuing authority (for example, a city government, national agency, or certification body)
- Information related to the specific attribute(s) or properties being asserted by issuing authority about the subject
- Evidence related to how the credential was derived
- Information related to expiration dates.
A verifiable credential can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. Holders of verifiable credentials can generate presentations and then share these presentations with verifiers to prove they possess verifiable credentials with certain characteristics. Both verifiable credentials and verifiable presentations can be transmitted rapidly, making them more convenient than their physical counterparts when trying to establish trust at a distance.
Data Import
A SSI system deals with identity data. These data can have different levels of quality. For instance, a national authority can issue qualified identity data of a person. In contrast, a person enter person related data on their own. The authenticity of these self-entered data cannot be guaranteed. Therefore, it can be beneficial for a user that the SSI system supports the import of qualified data. The qualified data import is not straightforward because a special transformation of the data during the import process has to be performed. This transformation process converts the data format from the received format to the SSI system supported format. The received data format can vary depending on its source. This is a necessary step in order to provide selective disclosure and attribute attestation at a later point.
Extending Trust Models
A SSI system decreases the required trust, compared to traditional identity management systems, by using the distributed ledger technology. Nevertheless, the trust in such a system can be elevated to an even higher level by combining the SSI system with current trust schemes such as Web-of-Trust.
Decentralized Public Key Infrastructure
A SSI system can be seen as the implementation of an open decentralized identity layer that includes a decentralized public key infrastructure (DPKI) based on the distributed ledger technology (DLT). The DPKI differs from the well-known public key infrastructure (PKI) by not depending on central certificate authorities, such as authorities for issuing certificates (CA) or registration authorities (RA). The dependence from these authorities can be eliminated by changing the root of trust from the authorities to the identity owner. Central authorities have the characteristic that their failure can cause critical consequences for the user. No single point of failure.
Interoperability
The SSI system uses various methods, like not relying on proprietary software, to increase the interoperability significantly. Resilience: Combining the decentralized architecture with cryptographically verifiable data increases the resilience of such a system. Key recovery: DPKI offers the opportunity to build robust key recovery systems by using a combination of key escrow services and social recovery of keys shared across trusted DPKI connections.
Following key items were designed to accomplish the interchangeability:
DIDs - Globally unique identifiers that don’t require any centralized resolution authority (can be resolved by a distributed ledger).
DDOs (DID descriptor objects) - A JSON object which exposes the public keys and service endpoints for interacting with the entity identified by the DID.
Verifiable claims - The standard format for exchange of digital identity attributes and their relationships.
Agents - A standard for communication between the agents that support off-ledger activities.
Interoperability of Digital Certificates
In self-sovereign identities, the hierarchical Public Key Infrastructure (PKI) model is replaced by the DID/DDO model. The peers in the network use their own DDOs as the root of trust. But DID and DDO key material and metadata can be used to generate an X.509 certificate which is the most widely established format. X.509 certificates can be used as verifiable claims with the DID/DDO model. In this way, hierarchical/federated identity systems can be coupled with decentralized identity systems.
GDPR Compliance
A SSI system can support the GDPR compliance when dealing with Digital IDs.
Consent
The GDPR mentions that a user must give explicit consent in order to process and collect the user’s data. A SSI system can be extended by a, for the user and its experience optimized, graphical user interface which is personal identity data management system (PIMS). This PIMS will provide fine granular control over what data are being shared together with revocation mechanisms. Some Blockchains support smart contracts, which could be used to enforce the user’s consent decisions.
Pseudonymization
The GDPR describes pseudonymization as process, where citizens’ personal data are being transformed in such a way that the resulting data cannot be linked to a specific person without providing additional information. In the SSI system, only identifiers are stored in the Blockchain. Those identifiers are cryptographically generated and cannot be linked to a specific person. An idea is to extend the SSI system and introduce qualified Anonymity by generating service provider and sector specific identifiers associated to a user. This is achieved by pairwise creating identifiers where a specific identifier is associated to each single counterpart. Different techniques can be used for the creation process, depending on data protection considerations.
Right to Erasure (Right to be Forgotten)
The GDPR’s right to erasure describes the right of a citizen to request the deletion of personal data. In a SSI system, the user fully owns the identity data; therefore, the user can simply delete the whole identity and its related data. The erasure is realized by not storing any private data in a public accessible place such as the decentralized ledger itself. Instead, only identifiers, linked to identity data, are stored in the ledger. The access relies on the user’s consent and is enforced by SSI consent mechanisms. The consent mechanism also enables the revocation of previously granted data access.
Records of Processing Activities
Maintain a record of processing activities that includes variety of information such as the processing purposes, the involved categories as well as envisaged time limits. The design of the SSI system provides opportunities to realize this.
Data Portability
In the GDPR, the right of data portability describes the right that a person is able to transfer personal data from one place to another. The SSI system supports this right by providing an open identity layer for the Internet, which offers the possibility to access and use it worldwide. This possibility is enabled because the SSI system combines different technologies that enable the data portability such as the distributed ledger with standardized data exchange formats such as XDI.
Data Protection by Design and by Default
Data protection by default means that the data protection mechanisms are already a part of the system’s design, which is the case in the SSI system. This includes that, by default, appropriate technical and organizational measures should ensure the protection of the processed personal data. The SSI system implements state-of-the-art techniques for both to preserve the user’s privacy as well as to protect the processed data. One of these state-of-the-art techniques are Zero-Knowledge Proofs (ZKP), which allow an identity owner to prove the correctness of identity specific elements without revealing any unnecessary additional information. For instance, by proving the possession of a driving license without disclosing the complete driving license.
Identity Derivation from existing ID
Another big possibility is offered by the SSI system when it comes to identity derivation. With extending the SSI system, it should be possible to derive identity data from existing ID infrastructure. This is realized by transforming the identity assertion into the SSI format. The big advantage when communicating directly with existing ID infrastructure is to have only one transformation method instead of deriving identity data from different members, where each would require its own identity translation. This way, the existing ID infrastructure is elevated to a global scale by generating a global Self-Sovereign identity.
Verifiable Claims
A new concept that is introduces by the SSI system are verifiable claims. A claim is an attribute related to a specific person. Verifiable claims are non-reputable sets of statements made by an entity about another entity. These claims are cryptographically generated. For instance, a verifiable claim could be issued by a University, which affirms that a related person is holding a degree of this University or a healthcare provider that provides medical attestations.
Verifiable Credentials
Credentials are a part of our daily lives; driver's licenses are used to assert that we are capable of operating a motor vehicle, university degrees can be used to assert our level of education, and government-issued passports enable us to travel between countries. These credentials provide benefits to us when used in the physical world, but their use on the Web continues to be elusive.
Currently it is difficult to express education qualifications, healthcare data, financial account details, and other sorts of third-party verified machine-readable personal information on the Web. The difficulty of expressing digital credentials on the Web makes it challenging to receive the same benefits through the Web that physical credentials provide us in the physical world.
A verifiable credential can represent all of the same information that a physical credential represents. The addition of technologies, such as digital signatures, makes verifiable credentials more tamper-evident and more trustworthy than their physical counterparts. Holders of verifiable credentials can generate presentations and then share these presentations with verifiers to prove they possess verifiable credentials with certain characteristics. Both verifiable credentials and verifiable presentations can be transmitted rapidly, making them more convenient than their physical counterparts when trying to establish trust at a distance.
The roles of the core actors and the relationships between them in an ecosystem where verifiable credentials are expected to be useful. A role is an abstraction that might be implemented in many different ways. The separation of roles suggests likely interfaces and protocols for standardization. The following roles are introduced:
holder
A role an entity might perform by possessing one or more verifiable credentials and generating presentations from them. Example holders include students, employees, and customers.
issuer
A role an entity might perform by creating a verifiable credential, associating it with a specific subject, and transmitting it to a holder. Example issuers include corporations, non-profit organizations, trade associations, governments, and individuals.
subject
A role an entity might perform by having one or more verifiable credentials asserted about it. Example subjects include human beings, animals, organizations and things. While in many cases the holder of a verifiable credential is the subject, in certain cases it is not. For example, a parent (the holder) might hold the verifiable credentials of a child (the subject), or a pet owner (the holder) might hold the verifiable credentials of their pet (the subject).
verifier
A role an entity might perform by requesting and receiving a verifiable presentation that proves the holder possesses the required verifiable credentials with certain characteristics. Example verifiers include employers, security personnel, and websites.
verifiable data registry
A role a system might perform by mediating the creation and verification of identifiers, keys, and other relevant data, such as verifiable credential schemas and revocation registries, which might be required to use verifiable credentials. Some configurations might require correlatable identifiers for subjects. Example verifiable data registries include trusted databases, decentralized databases, government ID databases, and distributed ledgers. Often there is more than one type of verifiable data registry utilized in an ecosystem.
A claim is a statement about a subject. A subject is an entity about which claims can be made. Claims are expressed using subject-property-value relationships.
Individual claims can be merged together to express a graph of information about a subject. The example below extends the claim by adding the claims that Pat knows Sam and that Sam is employed as a professor.
A credential is a set of one or more claims made by the same entity. Credentials might also include an identifier and metadata to describe properties of the credential, such as the issuer, the expiry date and time, a representative image, a public key to use for verification purposes, the revocation mechanism, and so on. The metadata might be signed by the issuer. A verifiable credential is a set of tamper-evident claims and metadata that cryptographically prove who issued it. Examples of verifiable credentials include digital employee identification cards, digital birth certificates, and digital educational certificates.
Figure above shows the basic components of a verifiable credential, but abstracts the details about how claims are organized into information graphs, which are then organized into verifiable credentials. Figure below shows a more complete depiction of a verifiable credential, which is normally composed of at least two information graphs. The first graph expresses the credential itself, which contains credential metadata and claims. The second graph expresses the digital proof, which is usually a digital signature.
Enhancing privacy is a key design feature therefore, it is important for entities using this technology to be able to express only the portions of their persona that are appropriate for a given situation. The expression of a subset of one's persona is called a verifiable presentation. Examples of different personas include a person's professional persona, their online gaming persona, their family persona, or an incognito persona.
A verifiable presentation expresses data from one or more verifiable credentials, and is packaged in such a way that the authorship of the data is verifiable. If credentials are directly presented, they become a presentation. Data formats derived from credentials that are cryptographically verifiable but do not of themselves contain credentials, might also be presentations. The data in a presentation is often about the same subject, but was issued by multiple issuers. The aggregation of this information typically expresses an aspect of a person, organization, or entity.
Figure above shows the components of a verifiable presentation, but abstracts the details about how verifiable credentials are organized into information graphs, which are then organized into verifiable presentations. Figure below shows a more complete depiction of a verifiable presentation, which is normally composed of at least four information graphs. The first graph expresses the presentation itself, which contains presentation metadata. The verifiablePresentation property in the graph refers to one or more verifiable credentials (each a self-contained graph), which in turn contains credential metadata and claims. The third graph expresses the credential graph proof, which is usually a digital signature. The fourth graph expresses the presentation graph proof, which is usually a digital signature.
Concrete Lifecycle Examples
The previous sections introduced the concepts of claims, credentials, and presentations using graphical depictions. This section provides a concrete set of simple but complete lifecycle examples of the data model expressed in one of the concrete syntaxes supported by W3C. The lifecycle of credentials and presentations in the Verifiable Credentials Ecosystem often take a common path:
- Issuance of one or more verifiable credentials.
- Storage of verifiable credentials in a credential repository (such as a digital wallet).
- Composition of verifiable credentials into a verifiable presentation for verifiers.
- Verification of the verifiable presentation by the verifier.
We will use concrete examples to illustrate the lifecycle above by demonstrating how to redeem an alumni discount from a university. In the example below, Pat receives an alumni credential from a university that will be stored in Pat's digital wallet.
A simple example of a verifiable credential
{
// set the context, which establishes the special terms we will be using
// such as 'issuer' and 'alumniOf'.
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
// specify the identifier for the credential
"id": "https://example.edu/credentials/1872",
// the credential types, which declare what data to expect in the credential
"type": ["VerifiableCredential", "AlumniCredential"],
// the entity that issued the credential
"issuer": "https://example.edu/issuers/565049",
// when the credential was issued
"issuanceDate": "2010-01-01T19:73:24Z",
// claims about the subject of the credential
"credentialSubject": {
// identifier for the subject of the credential
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
// assertion about the subject of the credential
"alumniOf": "<span lang='en'>Example University</span>"
},
// digital proof that makes the credential tamper-evident
"proof": {
// the cryptographic signature suite that was used to generate the signature
"type": "RsaSignature2018",
// the date the signature was created
"created": "2017-06-18T21:19:10Z",
// the public key identifier that created the signature
"creator": "https://example.edu/issuers/keys/1",
// the digital signature value
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
PAYuNzVBAh4vGHSrQyHUdBBPM"
}
}
Pat then presents the alumni credential above in order to receive a discount. The verifier, a ticket sales system, states that any alumni of "Example University" receives a discount on season tickets to sporting events. Using a mobile device, Pat starts the process of purchasing a season ticket. A step in the process requests an alumni credential and the request is routed to Pat's digital wallet. The digital wallet asks Pat if they would like to provide the previously issued verifiable credential. Pat selects the verifiable credential, which is then composed into a verifiable presentation. The verifiable presentation is then sent to the verifier and verified.
A simple example of a verifiable presentation
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": "VerifiablePresentation",
// the verifiable credential issued in the previous example
"verifiableCredential": [{
"id": "https://example.edu/credentials/1872",
"type": ["VerifiableCredential", "AlumniCredential"],
"issuer": "https://example.edu/issuers/565049",
"issuanceDate": "2010-01-01T19:73:24Z",
"credentialSubject": {
"id": "did:example:ebfeb1f712ebc6f1c276e12ec21",
"alumniOf": "<span lang='en'>Example University</span>"
},
"proof": {
"type": "RsaSignature2018",
"created": "2017-06-18T21:19:10Z",
"creator": "https://example.edu/issuers/keys/1",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..TCYt5X
sITJX1CxPCT8yAV-TVkIEq_PbChOMqsLfRoPsnsgw5WEuts01mq-pQy7UJiN5mgRxD-WUc
X16dUEMGlv50aqzpqh4Qktb3rk-BuQy72IFLOqV0G_zS245-kronKb78cPN25DGlcTwLtj
PAYuNzVBAh4vGHSrQyHUdBBPM"
}
}],
// digital signature by Pat on the presentation establishes consent and
// protects against replay attacks
"proof": {
"type": "RsaSignature2018",
"created": "2018-09-14T21:19:10Z",
"creator": "did:example:ebfeb1f712ebc6f1c276e12ec21#keys-1",
// 'nonce' and 'domain' protect against replay attacks
"nonce": "1f44d55f-f161-4938-a659-f8026467f126",
"domain": "4jt78h47fh47",
"jws": "eyJhbGciOiJSUzI1NiIsImI2NCI6ZmFsc2UsImNyaXQiOlsiYjY0Il19..kTCYt5
XsITJX1CxPCT8yAV-TVIw5WEuts01mq-pQy7UJiN5mgREEMGlv50aqzpqh4Qq_PbChOMqs
LfRoPsnsgxD-WUcX16dUOqV0G_zS245-kronKb78cPktb3rk-BuQy72IFLN25DYuNzVBAh
4vGHSrQyHUGlcTwLtjPAnKb78"
}
}
Some zero-knowledge cryptography schemes might enable holders to indirectly prove they hold a credential without revealing the credential itself. In these schemes, the original attribute, such as date of birth, might be translated into another value, such as "over the age of 15", which is cryptographically asserted such that a verifier can trust the value if they trust the issuer. For example, a claim specifying a subject's date of birth can be used as a predicate to prove the subject's age is within a given range, and therefore prove the subject qualifies for age-related discounts, without actually revealing the subject's birthdate.
Zero-Knowledge Proofs
A zero-knowledge proof is a cryptographic method where an entity can prove to another entity that they know a certain value without disclosing the actual value. A real world example is proving that an accredited university has granted a degree to you without revealing your identity or any other personally identifiable information contained on the degree.
The key capabilities introduced by zero-knowledge proof mechanisms are:
- The ability of a holder to combine multiple verifiable credentials from multiple issuers into a single presentation without revealing credential or subject identifiers to the verifier. This makes it more difficult for the verifier to collude with any of the issuers regarding the issued credentials.
- The ability of a holder to selectively disclose the claims in a credential to a verifier without requiring the issuance of multiple atomic credentials. This allows a holder to provide a verifier with precisely the information they need and nothing more.
- The ability of a holder to produce a derived credential that is formatted according to the verifier's data schema rather than the issuer's, without needing to involve the issuer after credential issuance. This provides a great deal of flexibility for holders to use the credentials they have been issued.
To use zero-knowledge verifiable credentials the issuer must issue a verifiable credential in a manner that enables the holder to present the information to a verifier in a privacy-enhancing manner. This implies that the holder will be able to prove the validity of the issuer's signature without revealing the values that were signed, or when only revealing certain selected values. The standard practice is to do so by proving knowledge of the signature, without revealing the signature itself. There are two requirements for verifiable credentials when they are to be used in zero-knowledge proof systems:
- The verifiable credential MUST contain a credential definition that may be used by all parties to perform various cryptographic operations in zero-knowledge.
- The verifiable credential MUST contain a proof that enables presentations to be derived that prove information contained in the original verifiable credential in zero-knowledge. The zero-knowledge presentation must not reveal any information not intended to be revealed by the holder.
The following example shows one method of using verifiable credentials in zero-knowledge. It makes use of a CL Signature, which allows the presentation of the verifiable credential in a way that supports the privacy of the holder and subject through the use of selective disclosure of the credential values. The example below provides the credential definition by using the credentialSchema property and a specific proof that is usable in the Camenisch-Lysyanskaya Zero-Knowledge Proof system.
A verifiable credential that supports CL Signatures
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"credentialSchema": {
"id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o",
"type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG"
},
"issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619",
"credentialSubject": {
"givenName": "Jane",
"familyName": "Doe",
"degree": {
"type": "BachelorDegree",
"name": "<span lang='fr-CA'>Baccalauréat en musiques numériques</span>",
"college": "College of Engineering"
}
},
"proof": {
"type": "AnonCredv1",
"issuerData": "5NQ4TgzNfSQxoLzf2d5AV3JNiCdMaTgm...BXiX5UggB381QU7ZCgqWivUmy4D",
"attributes": "pPYmqDvwwWBDPNykXVrBtKdsJDeZUGFA...tTERiLqsZ5oxCoCSodPQaggkDJy",
"signature": "8eGWSiTiWtEA8WnBwX4T259STpxpRKuk...kpFnikqqSP3GMW7mVxC4chxFhVs",
"signatureCorrectnessProof": "SNQbW3u1QV5q89qhxA1xyVqFa6jCrKwv...dsRypyuGGK3RhhBUvH1tPEL8orH"
}
}
The next example utilizes the verifiable credential above to generate a new derived verifiable credential with a privacy-preserving proof. The derived verifiable credential is then placed in a verifiable presentation that further proves that the entire assertion is valid. There are three requirements of most verifiable presentations when they are to be used in zero-knowledge systems:
- All derived verifiable credentials MUST contain a reference to the credential definition used to generate the derived proof.
- All derived proofs in verifiable credentials MUST NOT leak information that would enable the verifier to correlate the holder presenting the credential.
- The verifiable presentation MUST contain a proof enabling the verifier to ascertain that all verifiable credentials in the verifiable presentation were issued to the same holder without leaking personally identifiable information that the holder did not intend to share.
A verifiable presentation that supports CL Signatures
{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": "VerifiablePresentation",
"verifiableCredential": [{
"@context": [
"https://www.w3.org/2018/credentials/v1",
"https://www.w3.org/2018/credentials/examples/v1"
],
"type": ["VerifiableCredential", "UniversityDegreeCredential"],
"credentialSchema": {
"id": "did:example:cdf:35LB7w9ueWbagPL94T9bMLtyXDj9pX5o",
"type": "did:example:schema:22KpkXgecryx9k7N6XN1QoN3gXwBkSU8SfyyYQG"
},
"issuer": "did:example:Wz4eUg7SetGfaUVCn8U9d62oDYrUJLuUtcy619",
"credentialSubject": {
"degreeType": "BachelorDegree",
"degreeSchool": "College of Engineering"
}
},
"proof": {
"type": "AnonCredDerivedCredentialv1",
"primaryProof": "cg7wLNSi48K5qNyAVMwdYqVHSMv1Ur8i...Fg2ZvWF6zGvcSAsym2sgSk737",
"nonRevocationProof": "mu6fg24MfJPU1HvSXsf3ybzKARib4WxG...RSce53M6UwQCxYshCuS3d2h"
}
}],
"proof": {
"type": "AnonCredPresentationProofv1",
"proofValue": "DgYdYMUYHURJLD7xdnWRinqWCEY5u5fK...j915Lt3hMzLHoPiPQ9sSVfRrs1D"
}
}
Sources:
Verifiable Credentials Data Model 1.0
Decentralized Identifiers (DIDs) v0.13