# Configure Persona with Microsoft Entra Verified ID > Issue Microsoft Entra Verified ID credentials from Persona’s tenant or your own Entra tenant, and accept existing credentials so users skip re-verification. Source: https://help.withpersona.com/articles/2sjBNj9gDT6ea7kShXVb5q/ Section: Marketplace and 3rd-Party Integrations > Authentication > Microsoft Entra Persona supports [Microsoft Entra Verified ID](https://www.microsoft.com/en-us/security/business/microsoft-entra) as both an **issuer** and a **verifier** of verifiable credentials (VCs). This article explains how each flow works and how to configure them in your integration. --- ## Overview Microsoft Entra Verified ID is a decentralized identity solution that allows organizations to issue tamper-proof digital credentials and request them from users across applications and ecosystems. Verifiable credentials are cryptographically signed, portable, and user-controlled — meaning the holder chooses what data to share and with whom. Persona fits into this ecosystem in two ways: - **As an issuer:** After a user completes a Persona verification, Persona can issue a verifiable credential on their behalf. The credential is stored in the user's Microsoft Authenticator wallet and can be reused across any Entra Verified ID-compatible service. - **As a verifier:** Persona can request and validate a previously issued verifiable credential as part of a verification flow, allowing users to skip re-verification if they already hold a trusted credential. ### Choosing an issuance model When Persona issues a credential, you choose which Microsoft Entra tenant it is issued from. The rest of this article is organized around that choice — the two models are configured separately and independently: | | [Persona as your Identity Verification Partner](#persona-as-your-identity-verification-partner) | [Your own Microsoft Entra tenant](#issuing-from-your-own-microsoft-entra-tenant) | | ---------------------------- | ----------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------- | | **Entra tenant used** | Persona's | Yours | | **Setup required in Entra** | None | Verified ID onboarding, a credential definition, and an app registration | | **Issuing authority (DID)** | Persona's — `did:web:withpersona.com` | Your tenant's DID | | **Branding** | Persona brand and logo | Your logo, colors, and per-credential design | | **Credential lifespan** | Set by Persona | Set by you, in your credential's rules definition | | **Claims in the credential** | Persona's standard claim set | Any subset of Persona's claim set that your rules definition declares | | **Credential type** | Persona's | Any type name you register | --- ## How it works ### Issuance flow 1. The user completes identity verification through Persona. 2. Upon successful verification, Persona calls Microsoft Entra's [Request Service API](https://learn.microsoft.com/en-us/entra/verified-id/get-started-request-api) to create an issuance request — either from Persona's Entra tenant, or from your tenant using the connection you configured. 3. Entra generates a verifiable credential containing the verified identity claims (e.g. first name, last name, document number, date of birth). 4. The user is prompted to scan a QR code or follow a deep link to add the credential to their **Microsoft Authenticator** app. If `field_key_pin` is included in the inquiry configuration, the user will be prompted to enter a PIN as an additional security measure during credential addition. 5. The credential is stored in the user's wallet and can be presented to any Entra Verified ID-compatible relying party without repeating the verification process. ### Verification flow 1. A user arrives at a verification step in your flow. 2. Persona sends a presentation request to Microsoft Entra. 3. The user opens Microsoft Authenticator, selects their credential, and presents it. 4. Entra validates the credential's signature and returns the result to Persona. 5. Persona evaluates the credential against your configured requirements (accepted issuers, required claims) and passes or fails the verification accordingly. --- ## Persona as your Identity Verification Partner In this model Persona issues the credential from a **Persona-controlled Entra tenant**. You do not need a Microsoft Entra tenant, an Azure subscription, or any Entra configuration at all. ### Issuer configuration No Entra setup is required on your end. To issue a credential at the end of a Persona verification flow: 1. Open the [inquiry template](https://app.withpersona.com/dashboard/inquiry-templates) you want to issue from. 2. Choose **Add → Module → Microsoft Entra Verified ID issuance**. 3. Leave **Issuer** set to **Persona-managed** (the default). ℹ️ The issuance module reads the user's verified name, address, and document details, so add it to a template that already contains a government ID verification. Without those fields the credential is issued with only the Persona metadata claims. #### Claims included in the credential Claims are derived from the Persona verification result. Persona sends the following claims on every issuance request: | Claim | Description | | ---------------------------- | ------------------------------------------------------------ | | `firstName` | Verified first name from the identity document | | `lastName` | Verified last name from the identity document | | `dateOfBirth` | Date of birth | | `addressStreet1` | Street address, line 1 | | `addressStreet2` | Street address, line 2 | | `addressCity` | City | | `addressSubdivision` | State, province, or subdivision | | `addressPostalCode` | Postal code | | `addressCountryCode` | Country code | | `documentNumber` | Document ID number | | `documentType` | Document class (for example, driver's license or passport) | | `documentIssuanceDate` | Date the document was issued | | `documentExpirationDate` | Date the document expires | | `documentIssuingCountryCode` | Country that issued the document | | `photo` | The user's selfie, if a selfie was captured | | `inquiryId` | The Persona inquiry the credential was issued from | | `referenceId` | Your own identifier for the user, if set on the inquiry | | `organizationId` | Your Persona organization | | `organizationName` | Your Persona organization name | | `environmentId` | The Persona environment (for example, production or sandbox) | | `inquiryTemplateId` | The inquiry template the credential was issued from | Claims with no value on the inquiry are omitted from the request. Each claim is populated from a field on your template, and you can repoint any of them to a different field on the issuance step's configuration panel. ### Verifier configuration When Persona verifies a credential, it checks the credential's **Decentralized Identifier (DID)** — a unique identifier showing which organization issued it. Persona's DID is `did:web:withpersona.com`. **Verification filtering levels** By default, Persona accepts any valid Entra Verified ID, including those not issued by Persona. You can narrow which credentials are accepted by configuring one or more of the following filters in the **Allowed Issuer** detection verification check: - **Issuing authority/DID** (`allowed_issuers`): Accept credentials from specific issuing organizations. For example, only accept credentials from Persona (`did:web:withpersona.com`) or include additional trusted partner DIDs. - **Persona organization** (`allowed_organization_ids`): Within Persona-issued credentials, specify which Persona organization the credential must come from. - **Environment ID** (`allowed_environments_ids`): Require credentials to be issued from a specific Persona environment (e.g., your production environment vs. a development or staging environment). - **Inquiry template ID** (`allowed_inquiry_template_ids`): Only accept credentials issued through specific inquiry templates. **Required claims** Specify which claims must be present in the presented credential for verification to pass. If a presented credential is missing a required claim, the verification will be rejected. ℹ️ Talk with your Persona account team to enable this product feature. ### Credential storage and validity Issued credentials are stored in the user's Microsoft Authenticator wallet. Key details: - Credentials are **cryptographically signed** and cannot be altered after issuance. - Validity period is set at issuance time and determined by Persona's configuration. - Users can present their credential to any Entra-compatible service without re-verifying. --- ## Issuing from your own Microsoft Entra tenant Use this model when you want the credential to carry **your** organization's brand and DID, control its lifespan, or include institution-specific claims. Persona connects to your Entra tenant with a client ID and secret you provide, and issues the credential you have defined there. Configuration has two halves: everything in **Microsoft Entra** (steps 1–3), then everything in the **Persona Dashboard** (steps 4–5). ### Prerequisites - An Entra tenant where you hold enough privilege to onboard Verified ID and register an application. Microsoft requires the **Authentication Policy Administrator** role for the Verified ID setup and **Application Administrator** for the app registration ([Microsoft Learn](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-configure-tenant)). - Issuing from your own tenant turned on for your Persona organization. Contact your Persona account team to arrange this before you start. - Admin access to your Persona Dashboard. ### Step 1: Onboard your tenant to Verified ID If your tenant has never issued a Verified ID, set the service up first. Microsoft offers two paths: - **[Quick setup](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-configure-tenant-quick)** — Microsoft provisions the signing key and a `did:web` identifier for you. Fastest to get running, but the signing key is shared, so credential validity is capped at six months and the tenant is limited to two requests per second. - **[Advanced setup](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-configure-tenant)** — you bring your own Azure Key Vault, register your decentralized identifier, and verify your domain. Choose this if you need a custom domain in your DID or a longer credential lifespan. ℹ️ Advanced setup is required if you want a custom domain registered for the tenant, and quick setup is not currently available in EDU tenants. If you use Key Vault, it must use the **Vault access policy** permission model — Azure RBAC is not supported. The trusted domain you verify here is what Microsoft Authenticator shows the user as the issuer, so use a domain that your users will recognize as yours. ### Step 2: Create the credential you want Persona to issue Persona passes the verification results as claims in the issuance request, which corresponds to Microsoft's **ID token hint** attestation. Create a custom credential that declares those claims: 1. In the [Microsoft Entra admin center](https://entra.microsoft.com/), go to **Verified ID → Credentials → Add a credential**. 2. Select **Custom credential**, then **Next**. 3. Enter a **Credential name**. This becomes the credential's type — note it down, you'll enter it in Persona as the **Credential Type**. 4. Paste your **rules definition**, declaring each claim you want Persona to populate under an `idTokenHints` attestation. Persona sends the same claim names listed in [Claims included in the credential](#claims-included-in-the-credential) above, so reference them as `$.`: ```json { "attestations": { "idTokenHints": [ { "mapping": [ { "outputClaim": "firstName", "required": true, "inputClaim": "$.firstName", "indexed": false }, { "outputClaim": "lastName", "required": true, "inputClaim": "$.lastName", "indexed": true }, { "outputClaim": "dateOfBirth", "required": false, "inputClaim": "$.dateOfBirth", "indexed": false }, { "outputClaim": "documentNumber", "required": false, "inputClaim": "$.documentNumber", "indexed": false }, { "outputClaim": "referenceId", "required": false, "inputClaim": "$.referenceId", "indexed": false } ], "required": false } ] }, "validityInterval": 63072000, "vc": { "type": ["YourCredentialType"] } } ``` `validityInterval` is the credential lifespan in seconds — the example above is two years. This is where you control lifespan; Persona does not override it. 5. Paste your **display definition** to control the credential's branding — logo, colors, and the label shown for each claim. See Microsoft's [rules and display definition reference](https://learn.microsoft.com/en-us/entra/verified-id/rules-and-display-definitions-model) and [credential design guide](https://learn.microsoft.com/en-us/entra/verified-id/credential-design). To display the user's selfie, map the `photo` claim and set its display type to `image/jpg;base64url`. 6. Select **Create**, then open the new credential and choose **Issue credential**. Entra shows a sample Request Service API payload — copy two values from it: - `authority` — your **Verified ID Authority (DID)**, which looks like `did:web:yourdomain.com` - `manifest` — your **Credential Manifest URL**, of the form `https://verifiedid.did.msidentity.com/v1.0/tenants//verifiableCredentials/contracts//manifest` ℹ️ You can also point Persona at a Microsoft-provided credential type such as `VerifiedEmployee`. Those use directory-based claims rather than the claims Persona sends, and the user must be signed in to their Entra account inside Microsoft Authenticator to receive one. For most use cases a custom credential is the better fit. ### Step 3: Register an application for the client ID and secret Persona authenticates to your tenant with the client credentials flow, so it needs its own app registration. This follows Microsoft's [app registration steps](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-configure-tenant): 1. In the Entra admin center, go to **Applications → App registrations → New registration**. 2. Give it a name (for example, "Persona Verified ID issuance"). 3. Set **Supported account types** to **Accounts in this organizational directory only (single tenant)**. No redirect URI is needed. 4. Select **Register**, then copy the **Application (client) ID** from the overview page — this is the **Client ID** you'll enter in Persona. 5. Go to **API permissions → Add a permission → APIs my organization uses**, search for **Verifiable Credentials Service Request**, choose **Application permissions**, and select **VerifiableCredential.Create.All**. 6. Select **Add permissions**, then **Grant admin consent** for your tenant. Persona's requests will fail without consent. 7. Go to **Certificates & secrets → New client secret**, add a description and expiry, and select **Add**. Copy the secret **Value** immediately — Microsoft will not show it again. 8. Note your **Tenant ID**, found on the Entra **Overview** page. ⚠️ Client secrets expire. Track the expiry you chose and create a replacement secret in Persona before that date, or issuance will start failing. ### Step 4: Add the connection in the Persona Dashboard 1. In the Persona Dashboard, go to **Integrations → Microsoft Entra** ([app.withpersona.com/dashboard/integrations/microsoft-entra](https://app.withpersona.com/dashboard/integrations/microsoft-entra)). 2. Select **Add Credential**, then choose **Microsoft Entra Verified ID Issuer**. 3. Fill in the form with the values you collected above: | Field | Value | | ---------------------------------- | ---------------------------------------------------------------------------------- | | **Nickname for Credential** | A label for this connection, e.g. "Production Entra tenant" | | **Tenant ID** | Your Entra tenant ID (Entra admin center → **Overview**) | | **Client ID** | The **Application (client) ID** from Step 3 | | **Client Secret** | The client secret **Value** from Step 3 | | **Verified ID Authority (DID)** | The `authority` value from Step 2, e.g. `did:web:yourdomain.com` | | **Credential Manifest URL** | The `manifest` value from Step 2 | | **Credential Type** | The credential name/type from Step 2 | | **Issuer Display Name (optional)** | The issuer name shown to users during issuance. Defaults to Persona if left blank. | 4. Under **Scopes**, leave **Microsoft Entra Verified ID issuance.** checked. This is the `VerifiableCredential.Create.All` permission you consented to in Step 3, and issuance fails without it. 5. Save the connection and confirm it appears in the credential list for the Microsoft Entra integration. Persona validates the form on save. If you see an error, check that: - The **Credential Manifest URL** is an `https` URL on the host `verifiedid.did.msidentity.com`. Persona rejects manifest URLs on any other host. - The **Verified ID Authority (DID)** starts with `did:`. - All three of authority, manifest URL, and credential type are filled in. - Customer-managed issuance is enabled for your organization — if it isn't, saving fails with "Customer-managed Microsoft Entra Verified ID connections are not enabled for this organization." Contact your Persona account team. ### Step 5: Point the issuance module at your connection 1. Open the [inquiry template](https://app.withpersona.com/dashboard/inquiry-templates) you want to issue from. If it doesn't already have the module, choose **Add → Module → Microsoft Entra Verified ID issuance** — add it to a template that includes a government ID verification, since the credential's claims come from the verified name, address, and document fields. 2. Select the issuance screen, and in the configuration panel on the right set **Issuer** to **Customer-managed**. 3. A **Connection** picker appears. Select the connection you created in Step 4. 4. Optionally review the field pickers below — **First name field**, **Last name field**, **Birthdate field**, the address fields, and the document fields — to repoint any claim at a different field on your template. 5. Optionally set a **PIN field** to require the user to re-enter a PIN when adding the credential to their wallet. 6. Publish the template. ### Step 6: Test the flow 1. Create an inquiry from the template and complete the verification. 2. At the issuance step, scan the QR code with **Microsoft Authenticator** and confirm the credential is added to the wallet. 3. Open the credential in the wallet and confirm your branding and claims appear as you defined them in Step 2. ℹ️ If Authenticator shows the credential as coming from an unverified issuer, the trusted domain on your DID has not been verified — revisit Step 1. If issuance fails outright, the most common causes are a missing admin consent in Step 3, an expired client secret, or a claim marked `"required": true` in your rules definition that the inquiry did not collect. --- ## User experience ### For end users (issuance) 1. Complete identity verification in your application. 2. When prompted, follow the steps shared during the inquiry. 3. After inquiry completion, confirm the credential details and add it to your wallet. 4. Your verified credential is now available to present to supported services. ### For end users (verification) 1. At the verification step, scan the QR code with Microsoft Authenticator. 2. Select the credential you wish to share. 3. Confirm the data fields being shared and approve the presentation. 4. Persona receives and validates the credential automatically. --- ## Frequently asked questions **Does my organization need a Microsoft Entra tenant to use this feature?** Not unless you want to issue from your own tenant. With Persona as your Identity Verification Partner, Persona uses its own Entra tenant. For verification, no tenant is required on your side either — Persona handles the presentation request and validation. **When should I issue from my own tenant instead?** When you need your own branding on the credential, control over its lifespan, a credential type and DID that belong to your organization, or institution-specific claims such as a student number or campus affiliation. **Can I use both models?** Yes. The issuer is set per issuance module, so different templates — or different steps — can issue from Persona's tenant and from yours. **Can I connect more than one Entra tenant?** Yes. Add a connection per tenant and select the one you want on each issuance module. **What wallet does the user need?** Users must have **Microsoft Authenticator** installed on their iOS or Android device to receive and present credentials. **Can I accept credentials from multiple issuing organizations?** Yes. You can configure Persona to accept credentials from multiple DIDs — for example, accepting both Persona-issued credentials and those from partner organizations or other vendors. **What happens if a user loses access to their Authenticator app?** The user would need to re-verify through Persona to receive a new credential. **Is the issued credential reusable across multiple services?** Yes. Once stored in the wallet, the credential can be presented to any relying party that supports Entra Verified ID without the user repeating the identity verification process. **What happens when my client secret expires?** Issuance requests to your tenant start failing. Create a new secret in Entra and update the connection in the Persona Dashboard before the expiry date. --- ## Related resources - [Microsoft Entra integration overview](https://help.withpersona.com/articles/76oPGnRkduS3sHbEpLNSku/) - [Microsoft Entra Verified ID documentation](https://learn.microsoft.com/en-us/entra/verified-id/) - [Advanced Microsoft Entra Verified ID setup](https://learn.microsoft.com/en-us/entra/verified-id/verifiable-credentials-configure-tenant) - [Rules and display definition reference](https://learn.microsoft.com/en-us/entra/verified-id/rules-and-display-definitions-model) - [Call the Request Service REST API](https://learn.microsoft.com/en-us/entra/verified-id/get-started-request-api) - [Microsoft Authenticator app](https://www.microsoft.com/en-us/security/mobile-authenticator-app) - Contact your account team for enterprise setup assistance ## Plans Explained ### Microsoft Entra Integration by plan | | Startup Program | Essential Plan | Growth Plan | Enterprise Plan | | --------------------------- | --------------- | -------------- | ----------- | --------------- | | Microsoft Entra Integration | Not Available | Not Available | Limited | Available | [Learn more about pricing and plans](https://withpersona.com/pricing?utm_source=product&utm_medium=referral&utm_audience=a&utm_campaign=cm_gen_ds_hc-plan-table).