Skip to content
Help Center
withpersona.comDashboard

Configure Persona with Microsoft Entra Verified ID

View MarkdownContact support15 min read
On this page

Persona supports Microsoft Entra Verified ID 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 PartnerYour own Microsoft Entra tenant
Entra tenant usedPersona’sYours
Setup required in EntraNoneVerified ID onboarding, a credential definition, and an app registration
Issuing authority (DID)Persona’s — did:web:withpersona.comYour tenant’s DID
BrandingPersona brand and logoYour logo, colors, and per-credential design
Credential lifespanSet by PersonaSet by you, in your credential’s rules definition
Claims in the credentialPersona’s standard claim setAny subset of Persona’s claim set that your rules definition declares
Credential typePersona’sAny 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 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 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:

ClaimDescription
firstNameVerified first name from the identity document
lastNameVerified last name from the identity document
dateOfBirthDate of birth
addressStreet1Street address, line 1
addressStreet2Street address, line 2
addressCityCity
addressSubdivisionState, province, or subdivision
addressPostalCodePostal code
addressCountryCodeCountry code
documentNumberDocument ID number
documentTypeDocument class (for example, driver’s license or passport)
documentIssuanceDateDate the document was issued
documentExpirationDateDate the document expires
documentIssuingCountryCodeCountry that issued the document
photoThe user’s selfie, if a selfie was captured
inquiryIdThe Persona inquiry the credential was issued from
referenceIdYour own identifier for the user, if set on the inquiry
organizationIdYour Persona organization
organizationNameYour Persona organization name
environmentIdThe Persona environment (for example, production or sandbox)
inquiryTemplateIdThe 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).
  • 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 — 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 — 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, 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 above, so reference them as $.<claimName>:

    {
  "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 and credential design guide. 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/<tenant-id>/verifiableCredentials/contracts/<contract-id>/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:

  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).

  2. Select Add Credential, then choose Microsoft Entra Verified ID Issuer.

  3. Fill in the form with the values you collected above:

    FieldValue
    Nickname for CredentialA label for this connection, e.g. “Production Entra tenant”
    Tenant IDYour Entra tenant ID (Entra admin center → Overview)
    Client IDThe Application (client) ID from Step 3
    Client SecretThe client secret Value from Step 3
    Verified ID Authority (DID)The authority value from Step 2, e.g. did:web:yourdomain.com
    Credential Manifest URLThe manifest value from Step 2
    Credential TypeThe 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 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.

Plans Explained

Microsoft Entra Integration by plan

Startup ProgramEssential PlanGrowth PlanEnterprise Plan
Microsoft Entra IntegrationNot AvailableNot AvailableLimitedAvailable

Learn more about pricing and plans.

Was this page helpful?If something is missing, let us know and we will take a look.
Thanks for the feedback. It helps us improve these docs.

Related articles

Configure the Microsoft Entra ID integration in Persona
Marketplace and 3rd-Party Integrations · Authentication
Microsoft Entra integration overview
Marketplace and 3rd-Party Integrations · Authentication