Skip to content

France Identité Partenaires — ISO/IEC 18013-7 Annex A

← Back to the Partenaires app overview

Android support

ISO/IEC 18013-7 Annex A presentation is supported on Android in Partenaires version 1.3.5016. This page documents the website-retrieval flow invoked with the mdoc URI scheme.

ISO 18013 reference

For live access to the latest published versions of the ISO/IEC 18013 documents, use the OpenWallet Foundation's mdoc.online.

ISO/IEC 18013-7 Annex A defines device retrieval to a website. The verifier creates an mdoc reader engagement, exposes it through an mdoc URI, and retrieves the wallet's response over the internet. The credential remains an ISO/IEC 18013-5 mdoc.

Test Annex A with Multipaz

Use the OWF Multipaz verifier as the reference verifier for this flow. Its protocol selector includes URI scheme (18013-7 Annex A).

  1. Open the Multipaz verifier in a browser.
  2. Select URI scheme (18013-7 Annex A), not an OpenID4VP or DC API option.
  3. Configure the mdoc request and the namespaces and elements to request.
  4. Start the verification flow and display the generated QR code or URI.
  5. On the Android device, scan or open the generated mdoc URI so that France Identité Partenaires receives the request.
  6. Review and approve the requested attributes in Partenaires.
  7. Confirm that Multipaz retrieves, decrypts, and validates the returned mdoc.

The verifier generates the reader engagement and the URI payload. Do not hand-edit the encoded value or replace it with an openid4vp:// request, a request_uri, or a Digital Credentials API call.

Annex A message flow

At a high level, the flow is:

  1. The website creates a reader engagement and a request for the target mdoc.
  2. The website publishes the engagement through the mdoc URI scheme.
  3. Partenaires receives the URI and establishes the Annex A device-retrieval session.
  4. Partenaires obtains user approval and creates the mdoc response with device authentication.
  5. The website retrieves the response, validates the session transcript and cryptographic protections, and parses the returned DeviceResponse.

The mdoc URI is an invocation carrier, not the credential itself. Its encoded payload must be treated as opaque and must be generated for the current verification transaction.

What the verifier must validate

After retrieval, the verifier must validate the complete mdoc exchange:

  • the DeviceResponse and Document CBOR structures;
  • the requested docType, namespaces, and elements;
  • issuer authentication and the correct issuer certificate chain;
  • MSO value digests and validity information;
  • device authentication and holder binding against the Annex A session transcript;
  • session freshness, response integrity, and any status checks required by the test environment.

Use the test data and trust material page to select the correct Partenaires trust chain. Do not use production trust anchors for credentials issued in the playground environment.

Troubleshooting

Symptom Check
The URI does not open Partenaires Confirm that the URI uses the mdoc scheme and that the Partenaires app is installed and initialized on the Android device.
The request opens the wrong wallet flow Select URI scheme (18013-7 Annex A) in Multipaz; do not select OID4VP or DC API.
Multipaz cannot retrieve the response Keep the verifier page and the wallet transaction active, and create a new URI for a new attempt.
The returned document is empty or unparseable Decode the response as CBOR and confirm a complete mdoc Document, non-empty issuer-signed namespaces, a valid issuerAuth, and matching MSO digests.
Issuer authentication fails Use the Partenaires/pre-production trust anchor and verify the complete certificate chain.
Device authentication fails Verify the Annex A session transcript and the device signature against the holder key in the MSO.

For application and environment issues, see Troubleshooting.

References