Edit

Frequently Asked Questions (FAQ)

  • Article

Note

Azure Active Directory Verifiable Credentials is now Microsoft Entra Verified ID and part of the Microsoft Entra family of products. Learn more about the Microsoft Entra family of identity solutions and get started in the unified Microsoft Entra admin center.

This page contains commonly asked questions about Verifiable Credentials and Decentralized Identity. Questions are organized into the following sections.

The basics

What is a DID?

Decentralized Identifiers (DIDs) are unique identifiers that can be used to secure access to resources, sign and verify credentials, and facilitate application data exchange. Unlike traditional usernames and email addresses, DIDs are owned and controlled by the entity itself (be it a person, device, or company). DIDs exist independently of any external organization or trusted intermediary. The W3C Decentralized Identifier spec explains DIDs in further detail.

Why do we need a DID?

Digital trust fundamentally requires participants to own and control their identities, and identity begins at the identifier. In an age of daily, large-scale system breaches and attacks on centralized identifier honeypots, decentralizing identity is becoming a critical security need for consumers and businesses. Individuals owning and controlling their identities are able to exchange verifiable data and proofs. A distributed credential environment allows for the automation of many business processes that are currently manual and labor intensive.

What is a Verifiable Credential?

Credentials are a part of our daily lives; driver's licenses are used to assert that we're 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/regions. Verifiable Credentials provides a mechanism to express these sorts of credentials on the Web in a way that is cryptographically secure, privacy respecting, and machine-verifiable. The W3C Verifiable Credentials spec explains verifiable credentials in further detail.

Conceptual questions

What happens when a user loses their phone? Can they recover their identity?

There are multiple ways of offering a recovery mechanism to users, each with their own tradeoffs. We're currently evaluating options and designing approaches to recovery that offer convenience and security while respecting a user's privacy and self-sovereignty.

How can a user trust a request from an issuer or verifier? How do they know a DID is the real DID for an organization?

We implement the Decentralized Identity Foundation's Well Known DID Configuration spec in order to connect a DID to a highly known existing system, domain names. Each DID created using the Microsoft Entra Verified ID has the option of including a root domain name that will be encoded in the DID Document. Follow the article titled Link your Domain to your Distributed Identifier to learn more.

Why does the Microsoft Entra Verified ID support ION as its DID method, and therefore Bitcoin to provide decentralized public key infrastructure?

Microsoft now offers two different trust systems, Web and ION. You may choose to use either one of them during tenant onboarding. ION is a decentralized, permissionless, scalable decentralized identifier Layer 2 network that runs atop Bitcoin. It achieves scalability without including a special crypto asset token, trusted validators, or centralized consensus mechanisms. We use Bitcoin for the base Layer 1 substrate because of the strength of the decentralized network to provide a high degree of immutability for a chronological event record system.

Using the preview

Is any of the code used in the preview open source?

Yes! The following repositories are the open-sourced components of our services.

  1. SideTree, on GitHub
  2. An Android SDK for building decentralized identity wallets, on GitHub
  3. An iOS SDK for building decentralized identity wallets, on GitHub

What are the licensing requirements?

There are no special licensing requirements to issue Verifiable credentials. All you need is An Azure account that has an active subscription. Create an account for free.

How do I reset the Microsoft Entra Verified ID service?

Resetting requires that you opt out and opt back into the Microsoft Entra Verified ID service, your existing verifiable credentials configurations will reset and your tenant will obtain a new DID to use during issuance and presentation.

  1. Follow the opt-out instructions.
  2. Go over the Microsoft Entra Verified ID deployment steps to reconfigure the service.
    1. If you are in the European region, it's recommended that your Azure Key Vault, and container are in the same European region otherwise you may experience some performance and latency issues. Create new instances of these services in the same EU region as needed.
  3. Finish setting up your verifiable credentials service. You need to recreate your credentials.
    1. If your tenant needs to be configured as an issuer, it's recommended that your storage account is in the European region as your Verifiable Credentials service.
    2. You also need to issue new credentials because your tenant now holds a new DID.

How can I check my Microsoft Entra tenant's region?

  1. In the Azure portal, go to Microsoft Entra ID for the subscription you use for your Microsoft Entra Verified ID deployment.
  2. Under Manage, select Properties settings delete and opt out
  3. See the value for Country or Region. If the value is a country or a region in Europe, your Microsoft Entra Verified ID service will be set up in Europe.

How can I check if my tenant has the new Hub endpoint?

  1. Navigate to the Verified ID in the Azure portal.
  2. Navigate to the Organization Settings.
  3. Copy your organization’s Decentralized Identifier (DID).
  4. Go to the ION Explorer and paste the DID in the search box
  5. Inspect your DID document and search for the “#hub” node.
 "service": [
      {
        "id": "#linkeddomains",
        "type": "LinkedDomains",
        "serviceEndpoint": {
          "origins": [
            "https://contoso.com/"
          ]
        }
      },
      {
        "id": "#hub",
        "type": "IdentityHub",
        "serviceEndpoint": {
          "instances": [
            "https://verifiedid.hub.msidentity.com/v1.0/12345678-0000-0000-0000-000000000000"
          ],
          "origins": []
        }
      }
    ],

Yes, after reconfiguring your service, your tenant has a new DID use to issue and verify verifiable credentials. You need to associate your new DID with your domain.

Is it possible to request Microsoft to retrieve "old DIDs"?

No, at this point it isn't possible to keep your tenant's DID after you have opt-out of the service.

I cannot use ngrok, what do I do?

The tutorials for deploying and running the samples describes the use of the ngrok tool as an application proxy. This tool is sometimes blocked by IT admins from being used in corporate networks. An alternative is to deploy the sample to Azure App Service and run it in the cloud. The following links help you deploy the respective sample to Azure App Service. The Free pricing tier will be sufficient for hosting the sample. For each tutorial, you need to start by first creating the Azure App Service instance, then skip creating the app since you already have an app and then continue the tutorial with deploying it.

Regardless of which language of the sample you are using, they will pickup the Azure AppService hostname https://something.azurewebsites.net and use it as the public endpoint. You don't need to configure something extra to make it work. If you make changes to the code or configuration, you need to redeploy the sample to Azure AppServices. Troubleshooting/debugging will not be as easy as running the sample on your local machine, where traces to the console window shows you errors, but you can achieve almost the same by using the Log Stream.

Next steps