Entra Verified ID

How Verifiable Credentials work in Entra Verified ID?

• Decentralized Identifiers (DIDs): IDs users create, own, and control independently of any organization or government. DIDs are globally unique identifiers linked to Decentralized Public Key Infrastructure (DPKI) metadata composed of JSON documents that contain public key material, authentication descriptors, and service endpoints.
• Trust System: In order to be able to resolve DID documents, DIDs are typically recorded on an underlying network that represents a trust system. Microsoft currently supports two trust systems, which are:
  • DID:ION (Identity Overlay Network) is a layer 2 open, permissionless network.
  • DID:Web is a permission-based model that allows trust using a web domain’s existing reputation.
• DID User Agent/Wallet: Microsoft Authenticator App enables users to use Decentralized Identities and Verifiable Credentials. Authenticator creates DIDs, facilitates issuance and presentation requests for verifiable Credentials.
• Microsoft Resolver: An API that looks up and resolves DIDs using the did:web or the did:ion methods and returns the DID Document Object (DDO).
• Entra Verified ID Service: An issuance and verification service in Entra ID and a REST API for Verifiable Credentials that are signed with the did:web or the did:ion method. They enable identity owners to generate, present, and verify claims. This forms the basis of trust between users of the systems.

Attestations avaialble in Verified ID

Attestations are different ways of providing claims used by the Entra verified ID issuing service to be inserted into a Verifiable Credential and attest the claims with Decentralized Identifier (DID). Multiple attestation types can be used in the rules definition. There are six types of attestations currently available:

• Directory based - Employee: Type of a credential where the claims come from a user profile in the Microsoft Entra ID directory. With directory based claims user can create Verifiable Credentials of type VerifiedEmployee, if the user in the directory is employee.
• ID token: ID token type attestation requires an interactive sign-in to an OpenID Connect (OIDC) identity provider in Microsoft Authenticator. Claims in the ID token that the identity provider returns can be used to populate the issued Verifiable Credential. The claims mapping section in the rules definition specifies which claims are used.
• ID token hint: This type of attestation will be used where the relying party application passes claim values in the issuance request payload. It is the relying party application’s responsibility to ensure that required claim values are passed in the request. How the claim values are gathered is up to the application.
• Verifiable credentials: Also known as presentation attestation, where the user presents another verifiable credential in the wallet during issuance and where claim values for issuance of the new credential are taken from the presented credential. An example of this can be when user present their VerifiedIdentity credential to get a VerifiedEmployee credential.
• Self-attested claims: This option is used, when user can type information directly into Authenticator app, Verifiable Credential will be issued with the information provided by user.
• Multiple Attestations: Type of a credential issuance where the claims come from more than one source. For example, user may be required to present an existing credential and also manually enter values for claims in Microsoft Authenticator.