carla_urrea

I've been working as a software engineer since 2014, particularly as a backend engineer and doing system design. I consider myself a language-agnostic developer but if I had to choose, I like to work with Ruby, Python, and Elixir.  

After realizing how fun it was to create content and share experiences with the developer community I made the switch to Developer Advocacy. I like to learn and work with new technologies. 

When I'm not coding or creating content you could probably find me going on a bike ride, hiking, or just hanging out with my dog, Dasha. 

Senior Developer Advocate

Carla Urrea Stabile

Nowadays you could replace your physical driver's license with a digital, cryptographically verifiable one. Let's learn about it and how to start using them.

A driver's license is a document that gives legal authorization for people to drive certain types of vehicles, and they're often made of plastic and have the size of a credit card, so you usually store it in your wallet. Some countries, like Australia, the UK, and the US, use driver's licenses to prove their citizens' identity.

As driver's licenses continue to play a crucial role in verifying your identity, it makes sense that they evolve alongside our increasingly digital world. That's where Mobile Driver's Licenses come in. In this blog post, you'll learn more about them and how to use them.

## What is a Mobile Driver's License (mDL)?

Let's start from the beginning. **A Mobile Driver's License (mDL) is a driving license that resides on a mobile device** instead of physically in your wallet. The beauty behind an mDL is that **they are cryptographically verifiable**, meaning you can use cryptography to verify their information and authorship.

An mDL is a type of [Verifiable Credential (VC)](https://auth0.com/blog/what-are-verifiable-credentials-why-you-should-care/#What-are-Verifiable-Credentials) and they're an [ISO Standard](https://www.iso.org/standard/69084.html). As a VC, mobile driver's licenses also have an issuing authority, which is the authorized organization issuing the driver's license; for example, in the US, that'd be [the DMV](https://en.wikipedia.org/wiki/Department_of_motor_vehicles). There is an mDL holder, and it's the person to whom the mDL is issued. Finally, there is an mDL verifier, which is the entity that can verify the authorship of the mDL.

### mDL Step by Step

![mDL Roles](https://images.ctfassets.net/23aumh6u8s0i/7xGF2PSKekpejYPX11EOse/157c1415ce452ff436954197c1e90eb7/mdl-roles.png)

1. **Issuing:** A user can request an mDL from an issuing authority using their digital wallet. In mDL, this wallet is called an mDoc reader. An mDoc is a document that resides on a mobile device, so the mDoc reader can retrieve an mDoc for verification purposes. The issuer will verify the user's details and use their private key to sign and issue the mDL.

2. **Presenting:** A user can show their mDL using an application called an mDL reader to prove their identity, for example. This application would request the mDL data, which must be verified later.

3. **Verifying:** The mDL reader is in charge of cryptographically verifying the mDL data.

<include src="SmallBannerCTA"
         imgLink="https://images.ctfassets.net/23aumh6u8s0i/12gXwIIea5F2nkS1hNQFWy/70e57fab64095553831e4f4a0ee497d9/mdl-logo.png"
         text="Want to learn more about mDL?"
         linkText="Visit → mdl.me"
         link="https://mdl.me"/>

## Where Are We Today?

Today, many countries have started implementing and deploying pilots for Mobile Driver's Licenses. In the US, for example, there are already [multiple states that have mDL implementations](https://www.aamva.org/jurisdiction-data-maps#anchorformdlmap) in place. [The TSA (Transport Security Administration) has been accepting digital credentials as proof of identity since early 2022](https://www.tsa.gov/travel/frequently-asked-questions/when-will-phased-digital-id-rollout-start-which-airportsstates).

In November 2023, the [European Union also submitted a proposal to introduce mobile driver's licenses](https://data.consilium.europa.eu/doc/document/ST-15808-2023-INIT/en/pdf) and make them fully equivalent to their physical counterpart.

These are just a few examples to tell you that Mobile Driver's Licenses are coming to stay, and many other countries will start piloting and adopting them. Many companies are also beginning to build their own mDL readers and implementations; in fact, [the mDL ISO Standard was tested at the Interoperability Event](https://blog.spruceid.com/iso-iec-18013-7-interoperability-event-results/) where companies joined forces to test their implementations. Some mDL readers and mDL implementers included **Google, the National Institute of Standards and Technology (NIST), Okta, Samsung**, and more. You can read more about it in the [event results publication](https://docs.google.com/document/d/1M4ufcKqmj8gycNovslOSWzFB2nB1o1eu/edit?ref=blog.spruceid.com#heading=h.gjdgxs).


## Where to Use mDL?

Mobile Driver's Licenses have many potential use cases, but some of the most relevant are:

- Prove your Identity: as mentioned above, many countries use driver's licenses as proof of identity, and mDLs should be equivalent to prove someone's identity.
- Improve business processes involving Know Your Customer (KYC) and Anti-Money Laundering (AML)

## Getting Started with mDL

There are a few ways you can get started with mDL, the first one being going to [mdl.me](https://mdl.me) to learn more about it, how it works, and use the debugger to understand what's happening under the hood.

You can also start playing with a library like the one we crafted at [Auth0 Lab, mDL](https://github.com/auth0-lab/mdl). This NodeJS library allows you to issue and verify mDL [CBOR](https://cbor.io/) encoded documents. This library allows you to have a good start to understand how mDL works but **it's important to mention the library alone allows you to create, parse and validate mDL but it's not enough if you need to exchange mDLs.** So for example if you want to present mDL you need to implement a protocol such as the one in the [ISO/IEC DTS 18013-7](https://www.iso.org/standard/82772.html).

### Using the mDL library

First, you need to install the library. For that, run the following in your terminal:

```bash
npm install @auth0/mdl
```

> Note this blog post is for educational purposes and not meant to be used in production. In order to use mDL you'd need a protocol on top to exchange the data, such as the one in [ISO/IEC DTS 18013-7](https://www.iso.org/standard/82772.html) for presenting mDLs.


### Issuing a Credential

Let's take a look at what the code for issuing a new credential would look like:

```js
import { MDoc, Document } from "@auth0/mdl";
import fs from "node:fs";

// Create Document: representation of the mDL data
const document = await new Document('org.iso.18013.5.1.mDL')
  .addIssuerNameSpace('org.iso.18013.5.1', {
    family_name: 'Jones',
    given_name: 'Ava',
    birth_date: '2007-03-25',
  })
  .useDigestAlgorithm('SHA-512')
  .addValidityInfo({
    signed: new Date('2023-10-24'),
    validUntil: new Date('2050-10-24'),
  })
  .addDeviceKeyInfo({ deviceKey: devicePublicKeyJWK })
  .sign({
    issuerPrivateKey,
    issuerCertificate,
    alg: 'ES256',
  });

// Create MDoc
const mdoc = new MDoc([document]);

// CBOR encode the MDoc
const encodedMdoc = mdoc.encode();
```

This script is doing a few things. First, it adds the document type `org.iso.18013.5.1.mDL` to the `Document` instance; this refers to the mDoc document type that is used to identify the ISO driving license standard. Then, it adds the name and birth date attributes of the holder.

The digest algorithm is set to `SHA-512`, and it's used to compute the digest of each attribute. A digest algorithm is a cryptographic hash function that maps a large block of data into a fixed-size output (512 bits or 64 bytes in this case). The verifier will use the same algorithm to verify the disclosed attributes. This is related to the way that [selective disclosure](https://www.w3.org/TR/vc-data-model/#dfn-selective-disclosure) is implemented in mDL.

Then you'll see the `validityInfo`, which is the period of time the document is valid, and finally the device key information in the `addDeviceKeyInfo` method. Here, you specify the public key of the device that will hold the mDL to ensure that the mDL will only be used by the device that holds the corresponding private key. In other words, a presentation will only be accepted if it's signed with the private key that corresponds to the public key in the mDL.

Finally, you use the `sign` method to sign the document using the issuer's private key and certificate.

### Requesting a Credential

Now let's take a look at what should happen on the verifier side. The verifier is the entity that will request the mDL from the holder to later on verify its authenticity. 

Depending on the use case, the holder could have an application on their device that can serve as mDL reader (for example if they're opening a bank account online from their phone) or they could have be requested to show their mDL and the mDL reader resides in another device (for example, to enter a bar and prove that the holder is 18 years old or more, the person at the entrance could have an mDL reader where people can present their mDLs).

The mDL reader requests the mDL data that it needs and the holder uses the digital wallet to present the credential. When the holder presents the credential, the verifier needs to first generate an [ephemeral key pair](https://csrc.nist.gov/glossary/term/ephemeral_key_pair) and a nonce. An ephemeral key pair it's a short-term key pair generated when needed, and the nonce is a random value that is used to prevent replay attacks. The verifier then sends the nonce and the ephemeral public key to the holder. 

You could use [the JOSE package](https://www.npmjs.com/package/jose), for example, to generate these short-term keys. After installing `jose` with `npm install jose` you could do something like the following:

```js
const {generateKeyPair} = require('jose');
const ephemeralKey = await generateKeyPair('ES256')
```

### Generating a Device Response

Once the holder receives the nonce and the ephemeral key, their device can generate a device response. The device response is a signed message that contains the mDL and the nonce.

```js
const deviceResponseMDoc = await DeviceResponse.from(mdoc)
  .usingPresentationDefinition(PRESENTATION_DEFINITION_1)
  .usingHandover([holderNonce, clientId, responseUri, verifierGeneratedNonce])
  .authenticateWithMAC(DEVICE_JWK, ephemeralPublicKey, 'HS256')
  .addDeviceNameSpace('com.foobar-device', { test: 1234 })
  .sign();

const encodedSessionTranscript = getSessionTranscriptBytes(
  { client_id: clientId, response_uri: responseUri, nonce: verifierGeneratedNonce },
  holderNonce,
);

const deviceResponse = deviceResponseMDoc.encode();

sendToVerifier({ deviceResponse, encodedSessionTranscript });
```

With the mDL issued to the holder, the device creates a new device response using the `DeviceRespose` class. The `usingHandover` method is used to specify the date the verifier sent along with a nonce generated by the holder. Here, the `PRESENTATION_DEFINITION_1` constant refers to [which proofs the verifier is requesting from the holder](https://identity.foundation/presentation-exchange/spec/v2.0.0/#presentation-definition). An example could be:

```js
export const PRESENTATION_DEFINITION_1 = {
  id: 'mdl-test-age-over-18',
  input_descriptors: [
    {
      id: 'org.iso.18013.5.1.mDL',
      format: {
        mso_mdoc: {
          alg: ['EdDSA', 'ES256'],
        },
      },
      constraints: {
        limit_disclosure: 'required',
        fields: [
          {
            path: ["$['org.iso.18013.5.1']['age_over_18']"],
            intent_to_retain: false,
          },
        ],
      },
    },
  ],
};
```

In this case, the verifier is asking for an mDL with just one of the holder's attributes to verify that the holder is over 18 years old. You can find other examples in the [mDL repository](https://github.com/auth0-lab/mdl/blob/41724db924161c680c6fff0aa80450a8a2aa7286/__tests__/issuing/config.ts#L108). 

The `authenticateWithMAC` method is used to specify the way in which the device response is authenticated. In this case, it's authenticated [with a MAC](https://datatracker.ietf.org/doc/html/rfc9052#name-mac-objects) using the `HS256` algorithm. The secret for this MAC is computed as follows:

- On the holder's side it uses the public ephemeral key generated by the verifier plus the private key of the device.
- On the verifier's side it uses the private ephemeral key generated by the verifier plus the public key of the device.

The `addDeviceNameSpace` method adds a namespace to the device response.

Finally, the `sign` method is used to sign the device response.

### Verifying the Device Response

Finally the verifier verifies the `DeviceResponse`.

```js
const verifier = new Verifier([ISSUER_CERTIFICATE]);
await verifier.verify(encoded, {
  ephemeralReaderKey: ephemeralPrivateKey,
  encodedSessionTranscript,
});
```

First you need to construct a `Verifier` instance with a list of the issuer's certificates you trust.

Then you call the `verify` method with the encoded device response, the private key of the ephemeral key pair, and the encoded session transcript. This is a structure defined by the ISO standard. You can learn more about it in the  [ISO 18013.5 (section 9.1.5.1 - Session transcript)](https://www.iso.org/standard/69084.html)

## What's Coming: Verify mDL with Auth0

You can [sign up for the waitlist](https://regionalevents.okta.com/mdlearlyaccess) to be one of the first to know when mDL with Auth0 is available in Early Access.

You can also go to [mdl.me](https://mdl.me) to learn more, and if you know about any other mDL libraries out there, let us know so we can include them in the list of resources!

What is a Mobile Driver's License (mDL) and How to Start Using Them

Verifiable Credentials can be stored on digital devices, and you can use cryptography to verify their data and authorship. Let's learn more about them and why you should care about them.

We often use physical credentials such as our passports or driver's licenses as proof of identity. Until recent years, these types of credentials have usually been used in-person or offline, but nowadays, it's possible to prove your identity through digital credentials on the web in a cryptographically secure, privacy-respecting, and machine-verifiable way. In this blog post, you'll learn about these verifiable credentials, why you should use them, and when. 

## What are Verifiable Credentials?

When you think about a credential, you can often think of a physical credential like a passport, a driver's license, or an employee badge. A credential refers to a [set of one or more claims made by an issuer](https://www.w3.org/TR/vc-data-model/#dfn-credential); in the passport example, the photo, name, or identification number are the claims made by a government to identify a subject. 

When we talk about Verifiable Credentials (VCs), we are referring to a [W3C standard](https://www.w3.org/TR/vc-data-model/) for digital, cryptographically verifiable credentials. These credentials can represent the same information as a physical credential, but they add the use of digital signatures, making them more trustworthy than their physical version. You can store them on your device, which makes them more convenient and available almost everywhere. 

In the verifiable credentials context, there are a few important roles:

- **Holder**: it's the entity that possesses the verifiable credential. Holders could be, for example, students, employees, and customers. 
- **Issuer**: the entity that asserts claims about the subject, creates and transmits the verifiable credential to the holder. For example, governments, corporations, and non-profit organizations can be issuers. 
- **Subject**: the entity about which claims are made. For example, human beings, animals, and things. 
  - Often, the holder of a verifiable credential and subject can be the same, but only sometimes. For example, a parent can be the holder of the verifiable credential of their child (subject)
- **Verifier**: the entity that receives and processes verifiable credentials, such as employers, security personnel, and websites.   
- **Verifiable Data Registry**: the system that creates and verifies verifiable credentials schemas. For example, government ID databases and trusted databases. 

![VCs Roles](https://images.ctfassets.net/23aumh6u8s0i/4Gc0xRKUsczAlJ2w7JEh1/22f16ee9cfe9924b4a23f46638646649/vcs.png)

The image above shows how each entity interacts with each other. The issuer issues credentials to the holder as well as identifies and verifies the verifiable credentials. The holder acquires, stores, and presents VCs to the verifier. The verifier verifies VCs against the Verifiable Data Registry, which maintains identifiers and schemas. 

If we think of an example, let's say you are a citizen of the Asgard country. Asgard's government can issue a verifiable credential so you can prove your identity. 

![Asgard country issue VC](https://images.ctfassets.net/23aumh6u8s0i/35vmzFohdAtzKYw0drPXZ7/4a369f5669ef1133b750a9502fe3e8c5/holder-issuer.png)

In this example, the **holder** of the verifiable credential would be you because you are the owner of it and Asgard's government would be the **issuer**. This would be one of those scenarios where the **subject** would be the same as the holder because Asgard's government created claims for you, such as full name, identification number, and so on. 

Later on, let's say the Asgard police stop you and ask you for your ID. You decide to use your VC, and you have it in your wallet, so you **present** it to them. In this case they'd act as the **verifier** and check against Asgard's government database (the **Verifiable Data Registry**) that the VC is legit. 

![Present VC Asgard](https://images.ctfassets.net/23aumh6u8s0i/1SLhpBZvsGcEuJDQypUuqt/ff34ca49671651f75d9b23af70d18885/holder-presenter.png)

## Verifiable Credentials Are Necessary 

Verifiable Credentials have many use cases in our day-to-day life, and as we move more into an online world, [we need to be able to disclose our identity without issuers knowing](https://auth0.com/blog/our-take-on-verifiable-credentials/#The-Reason-We-Believe-VCs-Will-Happen). Because VCs are available in your wallet, you can use them "offline", meaning the issuer doesn't know when and how often you use them. This is what makes VCs so powerful: they are convenient, and having them available in your wallet removes a lot of friction from a user's life. So, let's go ahead and explore some use cases. 

### Legal Identity 

It's essential that you're able to prove your identity in a way that can be quickly verified, and governments are in the position to provide such identification in a verifiable digital form. Some examples are:

- Digital Driver's License
  - You get stopped over a traffic violation; with a digital driver's license, you always have access to it, and you can use it to prove to the officers both your identity and that you can drive. 
- Digital passports 
  - The electronic passport can contain a list of all the places you've visited and visas, so immigration officers can quickly and easily evaluate your suitability when visiting a new country. 
- Proof of Birth
  - Imagine asking for refuge in a country in such desperate conditions that you don't have your physical credentials. Still, you were issued a [self-sovereign](https://en.wikipedia.org/wiki/Self-sovereign_identity) proof of birth, and attached to this is the proof of birth and marriage of your parents; since it's verifiable, you can show this at the border controls of the country you're seeking refuge.

### Finance 

In finance, we can think of banking, brokerage, insurance, etc. Some example use cases are: 

- Money transfers
  - Let's say you want to send money to your family abroad; you can share your identity profile as well as your family member's with the money transfer service. This allows them to verify the source and destination of funds automatically.
- Opening or closing bank accounts 
  - If you want to open an account, you can use your government-issued certificate to prove your identity. Later on, when you want to close the account, the bank needs to revoke the "account owner" claim as part of the closing account process. 

### Healthcare

In the healthcare industry, privacy is extremely important, and with VCs, we can guarantee that the holder of the credential can disclose only the information they need. Let's understand some use cases in this area: 

- Prescribed medicine
  - A pharmacy can receive a prescription for medication for a patient. The pharmacy can automatically verify the doctor's ability to write prescriptions and the patient's insurance coverage. 
- Proving Legal Disability Status 
  - You can have government-issued disability credentials without having to disclose your specific disability to the service or entity you're providing. Issuers can issue verifiable credentials that support [selective disclosure](https://www.w3.org/TR/vc-data-model/#dfn-selective-disclosure) so holders can present proof of claims without revealing the entire verifiable credential. 

### Professional Credentials 

You may need a prove that an entity is who they say they are, and they can do what they say. This allows you to trust universities, doctors, companies, etc. 

- Doctors 
  - Health providers could provide information about the doctors they have on staff, including verifiable credentials about their education, board certification, etc. 
- University Degrees 
  - You could verify someone's obtained degree from a university that has a digital certificate to issue verifiable credentials. 
- Companies 
  - You can have an electronic badge that proves your identity to your company. 


## How Does a VC Look Like?

Let's take a look at what a verifiable credential looks like. Let's think of someone's ID card: 

```json
{
  "@context": [
    "https://www.w3.org/2018/credentials/v1"
  ],
  "type": ["VerifiableCredential", "IDCard"],
  "id": "urn:credential:34502108-4540",
  "issuer": "did:web:asgard-state.auth0lab.com",
  "issuanceDate": "2020-07-20T13:58:53Z",
  "credentialSubject": {
    "id": "urn:id-card:personal:1",
    "personalIdentifier": "34502108",
    "name": "Hanna Herwitz",
    "dateOfBirth": "1984-09-17",
    "placeOfBirth": "Asgard City",
    "currentAddress": "24th Street 210, Asgard City, 1023",
    "gender": "Female"
  },
  "credentialStatus": {
    "id": "https://asgard-state.auth0lab.com/vcs/credential/status/14",
    "type": "CredentialStatusList2017"
  }
  "proof": {
    "type": "Ed25519Signature2020",
    "created": "2020-07-20T13:58:53Z",
    "proofPurpose": "assertionMethod",
    "verificationMethod": "https://asgard-state.auth0lab.com/keys/1",
    "proofValue": "z2ty8BNvrKCvAXGqJVXF8aZ1jK5o5uXFvhXJksUXhn61uSwJJmWdcntfqvZTLbWmQHpieyhdcrG43em37Jo8bswvR"
  }
}
```

This JSON represents the digital version of Hanna Herwitz's ID card. Let's take a look at some of the most relevant parts of the VC: 

### Type 
The credential type can be used to determine if a specific credential is appropriate for a particular use case. In the example above, the type value is ` ["VerifiableCredential", "IDCard"]`.

### Issuer 
Represents the issuer of the credential and has to be a URI or an object containing an ID property. The example above is the Asgard government with the value `did:web:asgard-state.auth0lab.com`. Note that the value starts with `did`; this is a [Decentralized Identifier](https://www.w3.org/TR/did-core/), a new identifier enabling verifiable, decentralized digital identity. However, it's not mandatory to use DIDs. 

### Credential Subject 

Refers to the subject of the verifiable credential; it can be a DID or an object containing an id property. In the example above, the subject data is: 

```json
"credentialSubject": {
  "id": "urn:id-card:personal:1",
  "personalIdentifier": "34502108",
  "name": "Hanna Herwitz",
  "dateOfBirth": "1984-09-17",
  "placeOfBirth": "Asgard City",
  "currentAddress": "24th Street 210, Asgard City, 1023",
  "gender": "Female"
}
```

### Cryptographic Proof

It is one of the most essential parts and **what makes this credential verifiable**. Refers to cryptographic proofs (can be an object or an array) that can be used to detect tampering and verify the authorship of a credential or the data derived from the VC. In the example above: 

```json
"proof": {
  "type": "Ed25519Signature2020",
  "created": "2020-07-20T13:58:53Z",
  "proofPurpose": "assertionMethod",
  "verificationMethod": "https://asgard-state.auth0lab.com/keys/1",
  "proofValue": "z2ty8BNvrKCvAXGqJVXF8aZ1jK5o5uXFvhXJksUXhn61uSwJJmWdcntfqvZTLbWmQHpieyhdcrG43em37Jo8bswvR"
}
```

## Verifiable Credentials in Action 

Now that you know what a VC looks like, let's look at them in action. 

We've developed a site, [verifiablecredentials.dev](https://verifiablecredentials.dev), where you can play around and debug verifiable credentials. 


### Issue a VC 

To obtain a new verifiable credential, navigate to [wallet.verifiablecredentials.dev](https://wallet.verifiablecredentials.dev/), where you'll see a demo wallet where you can start by adding your first VC. 

![ID Wallet Add VC](https://images.ctfassets.net/23aumh6u8s0i/5cQaJh6drruR9bx86ZnSAR/3978c6e7e745ac70152a91d00da61f06/Screenshot_2024-01-16_at_13.37.27.png)

Follow the steps, and you'll create your verifiable credential! 🎉

![ID Wallet VC created](https://images.ctfassets.net/23aumh6u8s0i/6S3VrXJpueAeXvqaE3vl05/7042036ccc4d40524cf352a55f224c50/Screenshot_2024-01-17_at_17.30.14.png)

### Present a VC 

You can use the [Presentation Debugger tool](https://verifiablecredentials.dev/presentation) to create a request that defines the characteristics you want a Verifiable Presentation to meet.

You can use ID Wallet to see your verifiable credential data in the Presentation Debugger tool.

![Presentation tool](https://images.ctfassets.net/23aumh6u8s0i/10ykc9VwNiJs2hLDeV6PEI/dfcaac31665344445c3087ff92f7d99b/Screenshot_2024-01-17_at_17.29.27.png) 

## Conclusion 

Verifiable Credentials are digital, cryptographically signed credentials that you can use in many aspects of your life. There are many use cases in healthcare, education, and legal contexts where VCs are extremely useful. 

Users need the means to exercise their identity and disclose their claims without issuers knowing, the same way they do offline. 

If you want to learn more about VCs, go to [verifiablecredentials.dev](https://verifiablecredentials.dev), where you can play around and create and present verifiable credentials.

What are Verifiable Credentials and Why You Should Care About Them

Vittorio

Vittorio Bertocci is a Principal Architect for Auth0. Before Auth0, he had a lengthy career with Microsoft, where Vittorio worked with Fortune 100 and Global 100 companies, including working on Microsoft’s Azure Active Directory team as principal program manager focusing on the developer experience. He contributed to the inception and launch of Microsoft's claims-based platform components (Windows Identity Foundation and ADFS, ADAL and MSAL SDKs, ASP.NET middleware). Vittorio is a well known speaker, educator and published author.

Principal Architect

Vittorio Bertocci

Damian Schenkelman

Damian was one of Auth0's earliest employees. He loves building products for developers and taking things from 0 to 1.
<br><br>
He played key roles in implementing product features and growing the engineering organization in the early stages, and later on defining Auth0's architecture for scale and creating new products. Today he helps shape Auth0's long term strategy and leads Auth0Lab, a small and amazing team doing research and development of forward-looking products.
<br><br>
He spends his spare time with family, and friends, exercising, and catching up on all things NBA.

VP R&D (Auth0Lab)

An in-depth explanation on Verifiable Credentials from identity first principles, and how and why we think they will happen

Our Take on Verifiable Credentials

Samuel Frank

Sam Frank is Auth0's Sr. Product Manager for new initiatives. He works within the Auth0 Lab to commercialize the team's new ideas so they're available for builders everywhere. As a former platform product manager and startup product lead, he knows the challenges that developers face when creating new apps and he leverages those experiences to focus our teams efforts delivering the next generation of identity tools.

Senior Product Manager

Dock Labs unlocks Decentralized Identifiers and Verifiable Credentials for your Auth0-powered App.

While crypto companies adjust to the [changing market conditions](https://www.cnbc.com/2022/07/14/why-the-2022-crypto-winter-is-unlike-previous-bear-markets.html) in the DeFi space, Web3 innovators continue to build new infrastructure for the decentralized internet. That work took a step forward earlier this month when [Dock Labs](https://www.dock.io/) released their [Auth0 Marketplace Integration](https://marketplace.auth0.com/integrations/dock-web-3-id), Web3 ID, to unlock sign-in with [Decentralized Identifiers (DIDs)](https://dock.io/decentralized-identifiers) and [Verifiable Credentials (VCs)](https://dock.io/verifiable-credentials) and enable privacy-preserving user verification for Web3. 

Using Web3 ID, developers can grant access and verify end-user eligibility by requesting private data from users' non-custodial identity wallet apps with the users' consent.

The DID and VC W3C standards are core building blocks to enable [Decentralized Identity](https://dock.io/decentralized-identity) scenarios. [The Auth0 Lab team](https://twitter.com/Auth0Lab) has been following the space closely, and we're excited to support Dock with this important work.

![Decentralized Identity](https://images.ctfassets.net/23aumh6u8s0i/5u8VLYCaCVcdwxArkg5ImV/66e439eeeb61d2c862055dd5324fa5ba/01.jpeg)

## The Genesis of Decentralized Identity

The 2010s saw a stream of news on the misuse of identity information ([1](https://www.vice.com/en/article/g5gk73/google-fired-dozens-for-data-misuse), [2](https://www.nytimes.com/2018/04/04/us/politics/cambridge-analytica-scandal-fallout.html), [3](https://www.theatlantic.com/technology/archive/2014/06/everything-we-know-about-facebooks-secret-mood-manipulation-experiment/373648/)). Governments responded with new regulations, like the European Union’s [General Data Protection Regulation (GDPR)](https://auth0.com/gdpr)  and the [California Consumer Privacy Act (CCPA)](https://auth0.com/ccpa). Technologists started thinking about their own solutions for how to design a web ecosystem that doesn't rely on large centralized players to arbitrate identity across the web. While Decentralized Identity won't solve every privacy concern, it will hopefully represent a move towards user control of their data.

One of the core tenets of Decentralized Identity is that users own and control their identity information. In Web2, users sign in with centralized identifiers like email addresses and social media profiles. Web3 users want decentralization, to own their assets and identifiers, and to preserve their privacy while accessing apps and services. Web3 introduced the ability to sign in using cryptocurrency wallets. But with crypto wallets, all the user data that a developer can verify is on the blockchain, like assets owned or transaction history. Putting personal user data on the blockchain can be a major privacy issue, as a public blockchain is immutable and… public.

### Dock Lab's Approach to Decentralized Identity

The need to have a Web3-native system that enables organizations to verify private user data led Dock Labs to build Web3 ID, a blockchain-based Authentication and Authorization system that puts user privacy first. With Web3 ID, users' private data is stored on their non-custodial wallet apps.

However, this notion poses all sorts of challenges. Users need both security and convenience. Traditionally, they offloaded these responsibilities to the major social IDPs, like signing in with Google, which provided both very well, but sacrificed user privacy and control as Web3 organizations realized that getting a user to successfully handle a private key with a wallet [can prove to challenge](https://www.cnbc.com/2021/12/14/common-defi-crypto-related-scams-and-how-to-protect-your-wallet.html).

Another challenge of Decentralized Identity is that it's an ecosystem play; a lot of independent actors need to adopt similar standards so the identity can operate between systems. To ensure that DIDs and their associated public keys are always available for verification, Dock publishes DIDs to a[ public blockchain](https://dock.subscan.io/) that anyone can reference. Even though blockchains aren't required for DIDs to work, blockchains solve ecosystem problems by making the data publicly available for anyone to build against.

In the meantime, the standards for Decentralized Identity are evolving and being solidified. The [World Wide Web Consortium (W3C)](https://www.w3.org/) recently [finalized the DID Core standard](https://www.w3.org/2022/07/pressrelease-did-rec.html.en). The W3C's working on [Verifiable Credentials continues to evolve the standard](https://www.w3.org/TR/vc-data-model/) to fit industry needs. Dock Lab's evolving toolset is keeping apprised and applying these developments.

## Dock in Depth

Dock Labs, the team behind Web3 ID, has been in the decentralized identity space since 2017. "We started Dock to enable organizations and individuals to create and share verified data," says Elina Cadouri, co-founder of Dock.

While Web3 ID allows developers to verify user data in Verifiable Credentials, Dock's Decentralized Identity Platform,[ Certs](http://certs.dock.io/), provides a highly secure and scalable solution to issue these credentials through a no-code dashboard or a simple-to-use API.

And it's all built on top of the Dock blockchain. A Proof of Stake distributed ledger purposely created by Dock Labs for identity use cases, with high throughput, energy, and cost efficiency.

"It's incredibly exciting to see other industries, not just Web3, realize what Decentralized Identity enables. With Verifiable Credentials, sectors like Supply Chain Management or Health & Safety can now issue fraud-proof certificates and instantly verifiable documents. We're helping them eliminate certificate fraud, prove the origin of goods and greatly reduce the time it takes to verify a document." says Nick Lambert, Dock's CEO.

## Dock Lab's Auth0 Marketplace Integration

DIDs are cryptographically-verifiable pseudonymous identifiers created by the user, owned by the user, and independent of any organization. When a user creates an account in the Dock Wallet app, a DID will automatically be created for them.

DIDs contain no personal data about the user. An example of a DID store on the Dock blockchain could look like this:

![Decentralized Identity](https://images.ctfassets.net/23aumh6u8s0i/6hr5rFreGh2B23kPF3lwd0/767f50538442baf0686b59132d95e586/02.png)

Each DID is supported by one or many Public-Private cryptographic key pairs.

When a user scans the QR Code generated by the Dock Web3 ID Auth0 integration, the user's Private Key associated with the DID digitally signs a Verifiable Credential. The user signs the VC to prove that they control the DID.

This Verifiable Credential contains:

- Any data the organization requests from the end-user during the sign-in process (i.e., name, email address, etc.)
- A challenge (a unique, one-time use identifier provided by the auth server to prevent replay attacks)
- Expiration for the Credential
- A cryptographic hash that ensures that the Credential wasn't modified since it was created and signed.

This Verifiable Credential is sent to Dock, who verifies that the Credential was indeed cryptographically signed by the correct user and grants the user access to the app.

![Decentralized Identity](https://images.ctfassets.net/23aumh6u8s0i/3Zr2T4b0sdZjM5KsuJiRM5/aa36a207d4e97313f405db429df6b0a1/03.png)

To add the Dock Web3 ID Integration to your tenant, head over to Auth0 [Marketplace integration](https://marketplace.auth0.com/integrations/dock-web-3-id), and check out the installation guide! Like with any integration, some claims about the partner's system aren't controlled by Auth0/Okta and are subject to changes by the partner.

## What's Next?

The Auth0 Lab team is actively exploring the best ways to enable developers to build applications that rely on Web3 identity constructs and help bridge the Web2 and Web3 worlds. You can follow our progress on [Twitter](https://twitter.com/auth0lab). If you're interested in speaking with the team, join our [Discord](https://discord.gg/xkbkz9rZcD) and start a thread.

The [Auth0 Marketplace](https://marketplace.auth0.com/) is looking for Web3 partners to build new extensions onto Auth0. Visit [https://auth0.com/integrate](https://auth0.com/integrate) to learn more.

Sign-in with Decentralized Identifiers with Dock Labs

How to issue Verifiable Credentials from Auth0 user data using MATTR's Auth0 Marketplace Integration

"verifiable"