The Issue-Hold-Verify model is useful for understanding the basics of how self-sovereign identity (SSI) works, but it usually implies that the Issuer, Holder and Verifier are all people. There may indeed be people involved, and if so, they are people using applications that have been adapted to utilize verifiable credentials (VCs).
This blog post is about applications that have been adapted to utilize VCs, and the private digital connections for exchanging them. These applications live in Layer 4 of The VC Stack.
As VCs are in many ways just data containers, you would think that applications that need to interact with them can just treat them as they would any other data store.
Not so — and there are two main reasons for this:
- Most VCs today are held in individuals’ digital wallets, and strictly under their control; this means that applications can’t just read and write them as they would a regular database, accessing VCs requires the consent and cooperation of the Holder
- VCs are authenticatable data containers — their contents can be authenticated to verify who or what issued them, to whom or what they were issued, if they have been tampered with, and if they have been revoked
So, applications that need to interact with VCs need to take these differences into account, and doing so makes them ”VC-enabled”.
Let’s start with applications that need to issue VCs to holders.
Issuer applications typically execute in the trust domain of a business that manages the source data for VCs, and they issue VCs into the trust domain of an individual — their digital wallet.
(NOTE: in the future we envisage applications issuing authenticatable data containers between businesses, but that’s another story)
The entire process of issuing a VC to a holder typically involves these steps:
- Preparation: some kind of business event determines that a VC needs to be issued (e.g. a student passes a test); this initiates preparation for the issuing of the VC, including generation of the source data, identity-proofing of the target holder, and maybe some approval processes
- Connect: establishing a reliable connection with the target holder
- Staging: populating the VC attributes from system-of-record source data
- Build: creating the VC itself, including signing and encryption
- Offer: sending a VC offer over the connection from the issuer to the holder
- Wait: for the offer to be accepted (or rejected)
- Issue: once the offer is accepted, completing the issuance process
- Record: updating records in the issuing system to confirm that the VC has been accepted and fully issued
Clearly, this is a lot of work, involving multiple components, and also some waiting around – not simple.
However, from a business perspective, once the decision has been made that a VC should be issued, the business would like to see the entire process as “just do it, and tell me when it’s done” — for example:
“3,500 new students are starting school next month; issue them all with Digital Student Ids”.
To do this, we need a VC-enabled application, capable of managing the process of issuing Digital Ids to 3,500 students, and it is quite an involved process that may take several days to complete — but from a business standpoint, it’s just a business transaction.
StudentPass is an example of a VC-enabled application that does this rather well.
Whether the application is issuing one or one million VCs, most or all of the above steps must be completed, and most importantly, as some of the steps require action by the target holder, the entire process is seriously asynchronous.
Verifier applications are probably the most diverse category of VC-enabled applications, as they can range from a simple ticket verifier on a turnstile, or an identity verifier on a smart door, or in the login process of an IT application, to a complex resumé verifier, requesting, recording and acting on a set of proofs for each claimed academic credential or job position.
However simple or complex, the primary purpose of all verifier applications is to execute in some trust domain, requesting proof of assertions, claims or credentials originating in a different trust domain and held in one or more VCs, verify those assertions, and then act on the result.
Verifier applications typically carry out these steps:
- Preparation: of a proof request — deciding what attributes or predicates are going to be requested, and with what constraints (e.g. the VC must have been issued by the California DMV)
- Connect: establish a reliable connection with the target holder
- Request: send the proof request over the connection from the verifier to the holder
- Wait: for the holder to accept the proof request, and return the results
- Verify: that the proofs meet any required constraints, and that the VCs they originate from have not been revoked
- Record: optionally record the results — this may (e.g. for a single-use ticket credential) also include revoking the credential
- Act on the results: for example, opening a door, or allowing the individual to access a computer system, or reporting back that the individual does have the qualifications necessary for the job position
Note that some verification processes are initiated by the holder (for example, when a ticket holder approaches a turnstile), in which case the verifier application may be kicked into life by the holder presenting a QR code. The steps are very similar, except that the connection is initiated by the holder’s device.
In this case, the wallet application may include some streamlining to optimize the user experience (for example, as the wallet knows which credential attributes the holder wants to share, no need to wait for the holder to accept a proof request), but behind the scenes, the same processes need to be executed.
Now let’s look at a more complex verifier application — a resumé verifier.
Once an individual collects several VCs related to their education and career, as they are all by definition authenticatable on demand, we envisage that individual being able to wrap those VCs (or links to them) in a document that would be classed as a “verifiable resumé”.
The verifiable resumé can be published as any other resumé, on LinkedIn, Facebook, or the individual’s website or other social media platform.
This is fundamentally different from the “verifier asks holder for proof” model — in this use case the holder is publishing VCs (or selected claims from those VCs) for potentially anyone to verify on demand.
(Note that the verifiable resumé publisher would be a holder application.)
A verifier application in this scenario needs to do the following:
- Discovery: find the verifiable resumé somehow — maybe the holder sends the verifier a link, or it is embedded in their LinkedIn profile
- Filter: for each “claim” in the resumé, decide which ones they want to formally verify
- Verify: for each claim, verify the following:
- The subject of the claim is in fact the individual they think it is
- The issuer of the VC that contains the claim is in fact who the individual says it is
- The VC that contains the claim has not been tampered with
- The VC that contains the claim has not been revoked
- Record: optionally record the results of this process
- Act on the results: report back to the initiator that the selected claims have been verified
Holder applications’ primary purpose is to manage VCs on behalf of the holder or subject of those VCs, and executing in the trust domain of that holder.
Currently, most holder applications are self-contained digital wallets, running on devices such as smartphones and tablets.
In the future, we envisage VCs being held in types of locations other than wallets, and specialized holder applications being developed for one or more specific tasks:
- Providing simple storage or a secure enclave
- Receiving VC offers, handling proof requests
- Secure messaging with issuers, verifiers, and even other holders
- Managing the holder’s VCs (ordering, searching, filtering, categorizing, etc.)
- Managing VCs as a guardian on behalf of dependents, etc.
- Managing verifiable resumés
- VC backup, restore, archive, transfer
- Generation of printed VC proofs (e.g. QR codes, PDFs)
- Key management
We also envisage some future holder applications executing as Cloud applications, or embedded in autonomous hardware/software units such as robots and vehicles.
How does Credential Master help?
As a Verifiable Credentials Management system (VCM), Credential Master provides a wealth of functionality specifically for use by VC-enabled applications, to make them easier to develop and maintain, and to insulate them from the technical details of issuing and verifying VCs.
VC-enabled applications can run on the Salesforce platform, or external to the Salesforce platform.
In either case, Credential Master provides a comprehensive set of APIs that applications use to interact with VCs.
These APIs are designed to give applications access to the Credential Master data model, and make it straightforward to, for example, stage and offer multiple VCs in a single call, or to request a proof presentation from a holder and wait for the result.
See here for more details.
- VC-enabled applications, whether issuing, holding or verifying, have very specific requirements to meet, in order to reliably interact with VCs.
- Credential Master, as a Verifiable Credentials Management system, makes it easier to write and execute VC-enabled applications.
- Credential Master insulates applications from the technical details of the issuance and verification processes, making them both simpler to develop and maintain, and also makes them future-proof.
For more information, or if you have any questions about or comments on this blog post, please use our Contact Form.