Microsoft announced earlier in April 2021 the public preview of Verifiable Credentials.
What are they and what are the use cases and needs that they aim to fulfill?
What Verifiable Credentials are?
Let’s first start by explaining already what digital credentials are and some issues related to those. A credential is something that we already possess and use in the real world. It could be a driving license, a passport, a diploma, or anything that represents accreditation. The credentials that we use are released by an authority (for example: for a diploma a school, a passport, or the government). We all know that these types of credentials can be represented in a digital format such as a digital document (PDF), but nothing prevents these digital documents from being tampered with, or falsified by a third party.
Additionally, these credentials are released by central authorities, making them valid until it’s possible to verify them with the aforementioned authority. This means that, if an authority ceases somewhat to exist, the validity of the credential itself becomes questionable. Even in the case that the authority (e.g. a government) is so solid that the event of it ceasing to exist is unlikely, there is still a dependency on such authority to assert the validity of a credential, so that such authority must ensure that its infrastructure is highly available to satisfy this requirement.
A different way of creating and managing digital credentials could be envisioned to overcome the problems highlighted above. Digital credentials must possess the following characteristics:
Decentralized: they should not be issued by a central authority;
Persistent: they should be implicitly persistent, so should not require an issuing organization to exist;
Cryptographically verifiable and secure: it should be possible to verify the credential cryptographically so that there is tamper-proof evidence of its authorship;
Discoverable: it should be possible to discover information about the issuer at any time.
W3C (World Wide Web Consortium) started laying out the foundation of a data model to satisfy the basic requirements above. When a digital credential adheres to the W3C data model standard it’s called a Verifiable Credential (VC).
The Verifiable Credential data model depicts three (3) main actors:
Issuer: the issuer is an authority containing some information about the Subject (can be a person, a device, or an organization) and that can release that information as claims to the Holder.
Holder: the credentials released by the Issuer are normally managed by software that acts as a digital wallet to store the credentials and that acts on behalf of the Subject.
Verifier: a third party requesting information about the Subject, for example, a website. For verification purposes, the Holder can present all or part of the claims represented in the credentials that it holds, using any privacy-preserving technique to avoid disclosing personal information (e.g.: if a website requires to prove that the Subject is older than 18 years old, then the Holder can disclose just this specific information, avoiding sending personal information claims).
A Verifiable Credential is composed of three (3) main components:
Credential metadata: contains the credential identifier and properties of the credential itself.
Claim(s): a tamper-proof set of assertions made about the credential subject.
Proof(s): a proof mechanism to ensure the validity of the credential issuer and the subject’s claims.
What are the differences between federation models and VCs?
When talking about issuers and verifiers, we can think about a similarity we are used to knowing in many implementations today, which are federation models using certificates, Open ID Connect, or SAML protocols. However, the difference between federation models and verifiable credentials is substantial: in the first model, the Identity Provider (IdP) plays a central role in releasing information (claims) about the Subject to a Service Provider (SP), whilst in the second case the holder has the responsibility for deciding what information to disclose. In terms of user privacy, the difference is big: in the Verifiable Credential model, it’s the user who controls what information to disclose and has full control over his credentials, whilst in the federation model the user’s privacy is under the control of the IdP, that determines what information must be sent to the SPs that request for it.
Concerning user privacy we can recap the following key differences between the two models:
Just-In-Time issuance: in a federation model an issuer is contacted every time a service provider needs to assert the requestor’s identity, which demands the issuers’ infrastructure to be always available and also that the infrastructure sizing is proportionally scaled with the number of subjects that the IdP holds information for. In the Verifiable Credentials model, the credentials are held in a digital wallet or application under the users’ control, hence the issuer is not involved anymore when a service provider needs to request the credentials’ claims to the holder.
Information disclosure: in a federation model an identity provider holds the responsibility of disclosing attributes (claims) to requestors (service providers), hence controlling and tracking all information regarding which service providers the user visits and which attributes (claims) are sent to the service provider itself.
What are the use cases that can be fulfilled by VCs?
Verifiable Credentials can fulfil multiple use cases involving the presentation of the credentials to third parties that request them (verifier). In the W3C data model parlance, the item that is going to be presented by the holder to the verifier is called verifiable presentation, which contains a full or partial set of claims, as we saw in the previous chapter. Verifiable Credentials assume even more importance in the perspective where the presented claims will be handled by automated means, making instant decisions about accesses, job applications, and professional development.
W3C Verifiable Credentials needs on key domains
Here are a few use-case examples:
Finance: KYC (Know Your Customer) processes involving the verification of the customer’s address and the possession of a national ID card.
Healthcare: Automatic verification of prescriptions including insurance coverage.
Professional credentials: Automatic processing of job applications’ credentials (degrees, professional certifications, training certificates).
Legal identity: Digital credentials with claims that assert specific enablements from trusted certifying authorities (identical to how we present today our plastic ID/license cards to a third party that asks the, e.g. showing a driving license to a police officer requesting it).
The Microsoft implementation
The Microsoft implementation follows the W3C data model standards and builds on top of another standard tracking technology, called Decentralized Identifiers (DID), to allow organizations to release credentials and proofs under the users’ control, who decide in turn when and how to use them. Microsoft’s solution is built using the following components:
Azure AD Verifiable Credentials Service: Issues Verifiable Credentials upon users’ requests. Registers public key material on the ION distributed ledger to identify itself to other parties.
ION distributed ledger: blockchain public permissionless open network that holds information about decentralized identities (DIDs).
Microsoft Authenticator: an application that enables users to use DIDs and Verifiable Credentials, and facilitates the presentation of the latter.
Microsoft’s VC implementation and Stellium demo
We will see now a demo case where Stellium registers an Azure AD Verifiable Credentials Service in the ION blockchain network and then, issues to an employee requesting it the credential of Verified Employee in his Microsoft Authenticator application.
Step 1: Issuer registration on the ION public ID blockchain network
We registered our production tenant for the Azure Verifiable Credentials Service and our records are published in the ION public network.
Stellium Issuer information published on the ION network
We’ve created a Verifiable Credential that represents a Stellium Verified Employee and we are going to request this Verifiable Credential from the Microsoft Authenticator application.
Step 2: Issue Verified Employee credential from the Microsoft Authenticator app
We start now an application to display the QR codes that MS Authenticator can use to interact with the Stellium VC Issuer.
Once we scan the QR code with Microsoft Authenticator we are presented with the screen to request the Stellium Verified Employee credential. The Issuer requests an ID token verification as proof before releasing the credential, so I must authenticate with MFA to prove that I am a Stellium employee. Once authenticated I can add the Verified Employee card.
Step 3: Present the Verifiable Credential to a third-party application
After adding the credential to Microsoft Authenticator I can now use it to present it to a third-party web application (verifier).
The Holder application (Microsoft Authenticator) prompts for the permission request confirmation before sending the presentation of the claims. After the verification process, I can check at any moment all the interactions including the interaction history in Microsoft Authenticator.
We demonstrated a simple Proof-of-Concept to show the lifecycle of issuing a Verifiable Credential under the control of an employee, by using Microsoft Azure AD Verifiable Credentials Service and presenting it to a third-party application.
Verifiable Credential technology is promising but still in the early stages. The W3C standards are at the initial stage for specifying a data model, but more work is needed to gain maturity on interoperability on credentials verification processes, threat models, and enrichment of schema objects to account for complex scenarios. A unified approach to privacy approaches is also needed. In the next blog article, I will discuss the technical aspects of Verifiable Credentials and the current state-of-the-art of this technology, discussing also the above limitations and the current ongoing collaborative work by industry experts to address them. This technology is nevertheless bound to gain maturity and broad adoption, and it is worth exploring now the use cases to be ready for future production usage.
How can we help you?
At Stellium, we are exploring use cases for the introduction of Verifiable Credentials in the enterprise environment, we can help you analyze your business environment and explore together with Proof-of-Values how to take advantage of this promising privacy-preserving technology, to be ready when the general availability will be announced.
Would you like to get in touch about Verifiable Credentials and Decentralized Identities (DID)? Go ahead and set up a free online appointment with us for a consultation call.
