A fully managed end-to-end service for digitally signing code, documents, and applications. (formerly Trusted Signing)
The supported checks and recovery steps are:
- Verify the presentation flow is using the credential in Microsoft Authenticator, not the device camera alone. For Verified ID, scanning the QR code is intended to be done with Microsoft Authenticator. On Android, camera-app scanning can fail or open the wrong Authenticator instance if the phone has separate work and personal profiles.
- Confirm the credential actually matches the presentation request. If the presentation request doesn’t match any verifiable credential in Authenticator, Authenticator shows that the requested credential isn’t available. If the matching credential is expired, it also can’t be shared.
- The expected Artifact Signing flow for Individual identity validation is:
- complete the trusted ID-verifier steps,
- select Open Authenticator,
- scan the browser QR code again,
- select Add to add the verified ID to Microsoft Authenticator,
- when the browser shows Present your Verified ID, scan that QR code,
- select Verifiable Credential,
- select Share,
- wait for the browser to update to Verification Successful,
- then allow a few minutes for Azure portal status to change to Completed.
- For technical errors during identity validation with Authenticator and Verified ID, use these supported troubleshooting steps:
- Close all open instances of Microsoft Authenticator on the phone, then relaunch it.
- Make sure the latest version of Microsoft Authenticator is installed.
- Clear the web browser cache, or retry in a different browser.
- Avoid weak internet connections and avoid VPN or proxy services.
- Try a different mobile device, because device-specific settings or security policies can interfere.
- For the specific Artifact Signing identity-validation errors
address does not match,first name last name not matched, orFaceCheck fail, the documented recovery is to delete the existing identity validation request, remove the associated Verified ID from Microsoft Authenticator, then submit a new identity validation request and create a new Verified ID. The guidance also says to ensure the information is accurate and the verification environment has adequate lighting. - If the current request remains in Action Required and the credential still isn’t accepted, the documented path is to initiate a new identity validation request. A similar accepted resolution for a disabled delete/cancel scenario also states that a new identity validation request must be started.
- A Public Trust signing profile cannot be created until there is at least one completed identity validation request matching the certificate profile type.
The context does not provide a supported way to inspect the backend presentation request for accepted issuer, credential type, revocation, expiry, or Face Check policy details for an existing request. The supported guidance in the available documentation is limited to the matching/expiry checks, the standard troubleshooting steps above, and recreating the identity validation request and Verified ID when FaceCheck or identity-match validation fails.
References: