Configure your tenant for Microsoft Entra Verified ID
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.
Microsoft Entra Verified ID is a decentralized identity solution that helps you safeguard your organization. The service allows you to issue and verify credentials. Issuers can use the Verified ID service to issue their own customized verifiable credentials. Verifiers can use the service's free REST API to easily request and accept verifiable credentials in apps and services. In both cases, your Azure AD tenant needs to be configured to either issue your own verifiable credentials, or verify the presentation of a user's verifiable credentials issued by a third party. In the event that you are both an issuer and a verifier, you can use a single Azure AD tenant to both issue your own verifiable credentials and verify those of others.
In this tutorial, you learn how to configure your Azure AD tenant to use the verifiable credentials service.
Specifically, you learn how to:
- Create an Azure Key Vault instance.
- Set up the Verified ID service.
- Register an application in Azure AD.
The following diagram illustrates the Verified ID architecture and the component you configure.
- You need an Azure tenant with an active subscription. If you don't have an Azure subscription, create one for free.
- Ensure that you have the global administrator or the authentication policy administrator permission for the directory you want to configure. If you're not the global administrator, you need the application administrator permission to complete the app registration including granting admin consent.
- Ensure that you have the contributor role for the Azure subscription or the resource group where you are deploying Azure Key Vault.
Create a key vault
Azure Key Vault is a cloud service that enables the secure storage and access of secrets and keys. The Verified ID service stores public and private keys in Azure Key Vault. These keys are used to sign and verify credentials.
If you don't have an Azure Key Vault instance available, follow these steps to create a key vault using the Azure portal.
By default, the account that creates a vault is the only one with access. The Verified ID service needs access to the key vault. You must configure your key vault with access policies allowing the account used during configuration to create and delete keys. The account used during configuration also requires permissions to sign so that it can create the domain binding for Verified ID. If you use the same account while testing, modify the default policy to grant the account sign permission, in addition to the default permissions granted to vault creators.
Set access policies for the key vault
A Key Vault access policy defines whether a specified security principal can perform operations on Key Vault secrets and keys. Set access policies in your key vault for both the Verified ID service administrator account, and for the Request Service API principal that you created. After you create your key vault, Verifiable Credentials generates a set of keys used to provide message security. These keys are stored in Key Vault. You use a key set for signing, updating, and recovering verifiable credentials.
Set access policies for the Verified ID Admin user
In the Azure portal, go to the key vault you use for this tutorial.
Under Settings, select Access policies.
In Add access policies, under USER, select the account you use to follow this tutorial.
For Key permissions, verify that the following permissions are selected: Create, Delete, and Sign. By default, Create and Delete are already enabled. Sign should be the only key permission you need to update.
- To save the changes, select Save.
Set up Verified ID
To set up Verified ID, follow these steps:
In the Azure portal, search for Verified ID. Then, select Verified ID.
From the left menu, select Getting started.
Set up your organization by providing the following information:
Organization name: Enter a name to reference your business within Verified IDs. Your customers don't see this name.
Domain: Enter a domain that's added to a service endpoint in your decentralized identity (DID) document. The domain is what binds your DID to something tangible that the user might know about your business. Microsoft Authenticator and other digital wallets use this information to validate that your DID is linked to your domain. If the wallet can verify the DID, it displays a verified symbol. If the wallet can't verify the DID, it informs the user that the credential was issued by an organization it couldn't validate.
The domain can't be a redirect. Otherwise, the DID and domain can't be linked. Make sure to use HTTPS for the domain. For example:
Key vault: Select the key vault that you created earlier.
Under Advanced, you may choose the trust system that you want to use for your tenant. You can choose from either Web or ION. Web means your tenant uses did:web as the did method and ION means it uses did:ion.
The only way to change the trust system is to opt-out of the Verified ID service and redo the onboarding.
Select Save and get started.
Set access policies for the Verified ID service principals
When you set up Verified ID in the previous step, the access policies in Azure Key Vault are automatically updated to give service principals for Verified ID the required permissions.
If you ever are in need of manually resetting the permissions, the access policy should look like below.
|Service Principal||AppId||Key Permissions|
|Verifiable Credentials Service||bb2a64ee-5d29-4b07-a491-25806dc854d3||Get, Sign|
|Verifiable Credentials Service Request||3db474b9-6a0c-4840-96ac-1fceb342124f||Sign|
Register an application in Azure AD
Your application needs to get access tokens when it wants to call into Microsoft Entra Verified ID so it can issue or verify credentials. To get access tokens, you have to register an application and grant API permission for the Verified ID Request Service. For example, use the following steps for a web application:
Sign in to the Azure portal with your administrative account.
If you have access to multiple tenants, select the Directory + subscription. Then, search for and select your Azure Active Directory.
Under Manage, select App registrations > New registration.
Enter a display name for your application. For example: verifiable-credentials-app.
For Supported account types, select Accounts in this organizational directory only (Default Directory only - Single tenant).
Select Register to create the application.
Grant permissions to get access tokens
In this step, you grant permissions to the Verifiable Credentials Service Request Service principal.
To add the required permissions, follow these steps:
Stay in the verifiable-credentials-app application details page. Select API permissions > Add a permission.
Select APIs my organization uses.
Search for the Verifiable Credentials Service Request service principal and select it.
Choose Application Permission, and expand VerifiableCredential.Create.All.
Select Add permissions.
Select Grant admin consent for <your tenant name>.
You can choose to grant issuance and presentation permissions separately if you prefer to segregate the scopes to different applications.
Service endpoint configuration
- Navigate to the Verified ID service in the Azure portal.
- Select Registration.
- Notice that there are two sections:
- DID registration
- Domain ownership verification.
- Select on each section and download the JSON file under each.
- Create a website that you can use to distribute the files. If you specified https://contoso.com as your domain, the URLs for each of the files would look as shown below:
Once that you have successfully completed the verification steps, you are ready to continue to the next tutorial. If you selected ION as the trust system, you will not see the DID registration section because it doesn't apply to ION. When using ION, you only have to distribute the did-configuration.json file.