OID4VP feature support
A feature-by-feature reference for how MATTR VII, the Verifier Web SDK and the Verifier Mobile SDKs support OpenID for Verifiable Presentations (OID4VP) as profiled by ISO/IEC 18013-7 Annex B when requesting mDocs from a wallet.
Overview
This page is a feature-by-feature reference for how MATTR supports OpenID for Verifiable Presentations (OID4VP) when acting as a verifier that requests mDocs from a wallet.
It covers the whole verifier surface, because the roles are split:
- MATTR VII builds and signs every authorization request, publishes verifier metadata, and decrypts and verifies every response. Nearly everything on this page is MATTR VII behavior.
- The Verifier Web SDK starts sessions from a browser and renders the QR code or deep link.
- The Verifier Mobile SDKs for iOS, Android and React Native start and poll sessions on your MATTR VII tenant. They do not build or parse OID4VP messages themselves, so their OID4VP support is whatever MATTR VII provides.
MATTR's remote verification implementation follows the OID4VP profile defined by ISO/IEC 18013-7:2025 Annex B, not the OID4VP 1.0 specification directly. Annex B profiles an earlier OID4VP draft, so several parameter names on this page differ from OID4VP 1.0. See Relationship to OID4VP 1.0 for a translation.
It complements the OID4VP overview, which explains how the interaction works. If you are building a wallet, see the OID4VP feature support (Holder) page instead.
How to read this page
Each feature is given one of the following support statuses:
- Supported: Implemented and available for use.
- Partial: Implemented with a specific limitation, described in the notes.
- Not supported: Not currently implemented. Some fields may be parsed for specification compliance without any behavior attached.
- Limited availability: Available behind a tenant configuration or feature flag.
- Not applicable: Not relevant to the verifier role.
The Spec column cites the relevant clause of
ISO/IEC 18013-7:2025 Annex B unless the citation names
another specification. n/a means the feature is either a MATTR convenience or a parameter that
Annex B does not define at all.
If you need clarification on any feature, contact us.
What you can configure
MATTR VII builds one shape of authorization request and does not negotiate with the wallet. Most OID4VP parameters are therefore fixed, which matters if you are documenting your integration for a wallet provider or answering a conformance question.
| You control | Fixed by MATTR VII |
|---|---|
The credential query: doctype, namespaces, data elements and intentToRetain per claim | client_id and client_id_scheme |
| The challenge, or let the SDK generate one | Request signing, and the signing algorithm |
A state correlation reference | request_uri delivery and its single-use lifetime |
| Which wallet provider to invoke, and therefore the URI scheme | response_type, response_mode and response_uri |
| Same-device, cross-device, or automatic detection | The nonce |
| The redirect URI the user returns to on same-device flows | Presentation Exchange as the query language on the redirect path |
| Trusted issuers for the tenant | Response encryption algorithms and the ephemeral key |
| Which Digital Credentials API protocol is used | |
| The credential format |
Wallet invocation and request delivery
| Feature | Spec | Status | Notes |
|---|---|---|---|
Invocation via the ISO 18013-7 scheme (mdoc-openid4vp://) | B.2, B.3.2.3.3 | Supported | The default when no wallet provider is specified. |
| Invocation via a private-use URI scheme | n/a | Supported | Configure the wallet provider's scheme as its authorization endpoint. See Handling URI schemes. |
| Invocation via a claimed HTTPS scheme | n/a | Supported | Any valid URI is accepted as an authorization endpoint except plaintext http://. |
Authorization request by reference (request_uri) | B.4.2.3 | Supported | The only delivery method. The request URI carries client_id, client_id_scheme, request_uri and optionally state. |
| Authorization request by value | B.4.2.3 | Not supported | The request object is never inlined. |
| Single-use request retrieval | n/a | Supported | The request object can be retrieved once. A second retrieval of the same request is rejected. |
request_uri_method (get or post) | n/a | Not supported | Wallets must retrieve the request object with a GET. This parameter is defined by OID4VP 1.0 § 5.10 and is not part of Annex B. |
| Signed request object | B.4.2.3 | Supported | Always signed. MATTR VII also publishes require_signed_request_object in its verifier metadata. |
| Request object signing algorithm | B.5.2 | Partial | ES256 only. |
| Request object certificate chain | B.4.2.3 | Supported | The signing certificate is carried in the x5c header. See Signing verification requests. |
aud claim | B.4.2.3 | Supported | Set to the wallet's authorization endpoint when that endpoint is an HTTPS URL, otherwise to https://self-issued.me/v2. |
| Reading wallet metadata | B.3.2.2, B.3.2.3 | Not supported | MATTR VII does not read static or dynamic wallet metadata and does not adapt the request per wallet. A wallet provider record holds only an authorization endpoint. |
Client identifier and verifier authentication
| Feature | Spec | Status | Notes |
|---|---|---|---|
client_id_scheme request parameter | B.4.2.3 | Supported | Always emitted as a separate parameter. |
x509_san_dns | B.4.2.3 | Supported | The only scheme used. client_id is your tenant domain, and the signing certificate carries a matching dNSName Subject Alternative Name. |
x509_san_uri | n/a | Not supported | |
x509_hash | n/a | Not supported | Introduced by OID4VP 1.0 § 5.9.3. |
redirect_uri | n/a | Not supported | |
verifier_attestation | n/a | Not supported | |
openid_federation | n/a | Not supported | |
decentralized_identifier (did in earlier drafts) | n/a | Not supported | |
| Pre-registered client | n/a | Not supported | |
| Publishing verifier metadata | B.3.3.1 | Supported | Served from the tenant's well-known OAuth client endpoint so a wallet can validate by domain when it has no pre-provisioned certificate. |
vp_formats in verifier metadata | B.3.3.1 | Supported | Advertises mso_mdoc with ES256, ES384, ES512 and EdDSA. |
Credential query
| Feature | Spec | Status | Notes |
|---|---|---|---|
presentation_definition by value | B.4.2.3.3 | Supported | Presentation Exchange is the query language on the redirect path. One input descriptor is generated per requested doctype. |
presentation_definition_uri | n/a | Not supported | |
| Multiple credentials in one request | B.4.2.3.3 | Supported | Pass multiple credential queries and each becomes its own input descriptor. |
limit_disclosure | B.4.2.3.3 | Supported | Always set to required, so wallets disclose only the requested data elements. |
intent_to_retain | B.4.2.3.3 | Supported | Set per claim from your credential query, defaulting to false. |
presentation_submission validation | B.4.3.3 | Supported | Required on the response. The definition_id must match the request, and every descriptor map entry must correspond to a requested doctype. |
DCQL (dcql_query) | n/a | Not supported | Not available on the redirect path. DCQL is used on the Android Digital Credentials API path, covered below. |
scope-based presentation request | n/a | Not supported | |
transaction_data | n/a | Not supported | Introduced by OID4VP 1.0 § 5.1. |
verifier_info | n/a | Not supported | Introduced by OID4VP 1.0 § 5.11. |
trusted_authorities | n/a | Not supported | Issuer trust is enforced after verification against your tenant's trusted issuers rather than signaled in the request. |
Response
| Feature | Spec | Status | Notes |
|---|---|---|---|
response_type value vp_token | B.4.3.2 | Supported | |
Response mode direct_post.jwt | B.4.2.3 | Supported | The only response mode used. |
Response mode direct_post | n/a | Not supported | Encryption is mandatory, so an unencrypted direct post is never requested or accepted. |
Response mode fragment or query | n/a | Not supported | |
response_uri | B.4.2.3 | Supported | A tenant endpoint that accepts application/x-www-form-urlencoded with a single response field. The endpoint differs for Android verifier applications. |
vp_token | B.4.3.2 | Supported | Read as a single base64url-encoded ISO DeviceResponse. |
nonce | B.4.2.3 | Supported | A fresh 32 byte value generated when the request object is retrieved. |
state | B.4.3.2 | Supported | Your own correlation reference if you supply one, otherwise the session identifier. Validated on the response. See Correlating verification sessions. |
| Redirect after the response, same-device | B.4.3.2 | Supported | The response endpoint returns a redirect URI carrying session_id and state as query parameters and response_code in the URL fragment. |
| Redirect after the response, cross-device | n/a | Not applicable | The holder stays on their own device and the verifier device polls for the result. |
| Single-use response code | n/a | Supported | A response code is issued once per session. A second response for the same session is rejected. |
| Wallet error responses | B.4.3.2 | Partial | An error response is accepted in place of a presentation. wallet_unavailable is the only error code given specific handling. |
Response encryption
Response encryption is mandatory on every path. There is no configuration that disables it.
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Encrypted authorization response | B.3.3.1, B.4.2.3 | Supported | |
authorization_encrypted_response_alg value ECDH-ES | B.3.3.1 | Supported | The only key agreement algorithm requested. |
authorization_encrypted_response_enc value A256GCM | B.3.3.1 | Supported | The value requested on the redirect path. |
authorization_encrypted_response_enc value A128GCM | B.3.3.1 | Supported | Accepted, and used on the Digital Credentials API path. |
| AES-CBC content encryption | n/a | Not supported | |
| Ephemeral encryption key per request | B.3.3.1 | Supported | A P-256 key is generated per session request, published in client_metadata.jwks with encryption use, and deleted after verification. |
apu and apv JWE headers | B.4.4 | Supported | Both are required. apv carries the request nonce and is how the response is matched to its session, and apu carries the wallet's mdoc-generated nonce. A response missing either is rejected. |
Session transcript
| Feature | Spec | Status | Notes |
|---|---|---|---|
ISO 18013-7 OID4VPHandover | B.4.4 | Supported | Built as [clientIdHash, responseUriHash, nonce]. Each hash covers the value together with the wallet's mdoc-generated nonce, taken from the JWE apu header. |
OID4VP 1.0 OpenID4VPHandover | OID4VP 1.0 B.2.6.1 | Not supported | A different structure under a very similar name. See Relationship to OID4VP 1.0. |
Credential formats
MATTR's remote verification implementation is mDocs only.
| Format | Spec | Status | Notes |
|---|---|---|---|
ISO mdoc / mDL (mso_mdoc) | B.4.2.3.3 | Supported | The only requestable format. |
IETF SD-JWT VC (dc+sd-jwt) | n/a | Not supported | |
W3C VC JWT (jwt_vc_json) | n/a | Not supported | |
W3C VC JSON-LD (ldp_vc) | n/a | Not supported |
Digital Credentials API
The Digital Credentials API is a separate path from the mdoc-openid4vp:// redirect flow, and
MATTR VII selects the protocol from the holder's platform rather than exposing it as an option.
See the Digital Credentials API overview.
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Availability | n/a | Limited availability | Requires a dcApiConfiguration on your verifier application. Without it, sessions use the redirect flow. Also skipped when you name a wallet provider. |
| Protocol selection | n/a | Supported | Chosen from the holder's user agent. iOS and macOS browsers get the ISO mdoc protocol, Android and other platforms get OID4VP. |
Protocol openid4vp-v1-unsigned | OID4VP 1.0 A.1 | Supported | The default for Android and other platforms. Uses DCQL. |
Protocol openid4vp-v1-signed | OID4VP 1.0 A.1 | Not supported | MATTR VII does not sign Digital Credentials API requests. |
Protocol openid4vp-v1-multisigned | OID4VP 1.0 A.1 | Not supported | |
Protocol org-iso-mdoc | 18013-7 C.1 to C.5 | Supported | Used for iOS and macOS. A CBOR DeviceRequest with HPKE encryption, not an OID4VP request. |
| DCQL query | OID4VP 1.0 § 6 | Partial | Only credentials with format, meta.doctype_value and claims carrying path and intent_to_retain. credential_sets is not supported. |
Response mode dc_api.jwt | OID4VP 1.0 A.2 | Supported | Encryption is applied on this path too. |
expected_origins | OID4VP 1.0 A.2 | Not supported | Not required, because MATTR VII does not send signed Digital Credentials API requests. The origin is validated server side against the stored session instead. |
| OID4VP handover | OID4VP 1.0 B.2.6.2 | Supported | OpenID4VPDCAPIHandover, computed over the origin, nonce and verifier key thumbprint. Android application origins are expressed as an APK key hash. |
| ISO mdoc handover | 18013-7 C.5 | Supported | The dcapi handover, computed over the encryption info and origin. |
| HPKE response encryption | 18013-7 C.4 | Supported | On the org-iso-mdoc protocol only. DHKEM P-256 with HKDF-SHA256 and AES-128-GCM. |
| Reader authentication over the ISO mdoc protocol | 18013-7 C.2 | Limited availability | A signed readerAuth is included only when an Apple verifier signer certificate is configured for the origin. See Verify with Apple Wallet. |
Relationship to OID4VP 1.0
If you are working from the OID4VP 1.0 specification rather than ISO 18013-7, the redirect path described on this page will not match what you read. Annex B profiles an earlier OID4VP draft. This table maps the differences that affect a wallet or verifier implementer.
| Concept | ISO 18013-7 Annex B, used by the redirect path | OID4VP 1.0 |
|---|---|---|
| Client identifier scheme | A separate client_id_scheme request parameter, with client_id carrying the bare DNS name | The scheme is a prefix inside client_id itself, for example x509_san_dns:verifier.example.com |
| Scheme discovery | Wallet advertises client_id_schemes_supported | Wallet advertises client_id_prefixes_supported, defaulting to pre-registered |
| Scheme names | x509_san_dns, x509_san_uri, did | x509_san_uri removed, x509_hash added, did renamed to decentralized_identifier, origin reserved |
| Query language | Presentation Exchange, using presentation_definition and presentation_submission | DCQL, using dcql_query. Presentation Exchange is removed entirely |
| Response encryption metadata | authorization_encrypted_response_alg and authorization_encrypted_response_enc | A single encrypted_response_enc_values_supported list, with the key agreement algorithm taken from the JWK |
| mdoc session transcript | OID4VPHandover, a three element array of [clientIdHash, responseUriHash, nonce] using an mdoc-generated nonce | OpenID4VPHandover, a labeled two element array whose hash covers [clientId, nonce, jwkThumbprint, responseUri] |
| Wallet invocation scheme | mdoc-openid4vp://, registered by Annex B | openid4vp://. mdoc-openid4vp:// does not appear in OID4VP 1.0 |
The two handover structures are not interchangeable
ISO 18013-7 Annex B and OID4VP 1.0 both define an mdoc handover under nearly the same name, but
the structures differ. A wallet that builds the OID4VP 1.0 OpenID4VPHandover for a redirect
flow will produce a session transcript MATTR VII cannot reproduce, and device authentication
will fail. Match the profile your wallet and verifier have agreed on.
The Digital Credentials API path does use OID4VP 1.0 vocabulary, including DCQL and the
OpenID4VPDCAPIHandover. The two baselines coexist on different paths.
Not currently supported
At a glance, the following features are not currently supported on the mdoc-openid4vp://
redirect path:
- Authorization request by value (B.4.2.3)
request_uri_method, including thepostmethod (OID4VP 1.0 § 5.10)- Request object signing algorithms other than
ES256(B.5.2) - Every client identifier scheme other than
x509_san_dns(B.4.2.3) - Reading wallet metadata, static or dynamic, and adapting the request per wallet (B.3.2.2, B.3.2.3)
presentation_definition_uri(B.4.2.3.3)- DCQL on the redirect path (OID4VP 1.0 § 6)
- Unencrypted responses, including response mode
direct_post(B.4.2.3) - AES-CBC content encryption algorithms (B.3.3.1)
transaction_data(OID4VP 1.0 § 5.1)verifier_info(OID4VP 1.0 § 5.11)trusted_authorities(OID4VP 1.0 § 6.1.1)- Signed Digital Credentials API requests, and therefore
expected_origins(OID4VP 1.0 A.2, A.3.2) - Credential formats other than mDocs (
mso_mdoc)
Related
How would you rate this page?
Last updated on