OID4VCI feature support
A feature-by-feature reference for how the MATTR Pi Holder SDKs support the OpenID for Verifiable Credential Issuance (OID4VCI) v1.0 specification when claiming credentials from an issuer.
Overview
This page is a feature-by-feature reference for how the MATTR Pi Holder SDKs support the OpenID for Verifiable Credential Issuance (OID4VCI) v1.0 specification when acting as a holder that claims credentials from an OID4VCI issuer.
It complements the credential claiming overview, which explains how claiming works. Use this page when you need to know whether a specific OID4VCI feature is available in the Holder SDK before you design a wallet integration.
If you are building an issuance solution, see the OID4VCI feature support (Issuer) 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.
- Not applicable: Not relevant to the holder role.
The Spec column cites the relevant clause of the OID4VCI v1.0 specification. A dash means the feature is a MATTR SDK convenience that is not defined by OID4VCI.
Support statuses reflect the latest versions of the SDKs. If you need clarification on any feature, contact us.
Claiming flows
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Authorization Code flow | § 3.4, § 6 | Supported | The SDK runs the interactive, PKCE-protected flow, redirecting the holder to authenticate before the credential is claimed. |
| Pre-authorized Code flow | § 3.5, § 6 | Supported | The SDK redeems a pre-authorized code, with optional transaction code entry. |
| Manual redirect support | — | Supported | The SDK can return the authorization URL and code verifier so your app can control the redirect in an embedded web view. |
Credential offer
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Credential offer object handling | § 4.1 | Supported | The SDK parses a credential offer and drives the claiming flow from it. |
| Credential offer by value | § 4.1.2 | Supported | The offer is read directly from the offer URI. |
Credential offer by reference (credential_offer_uri) | § 4.1.3 | Not supported | An offer that references credential_offer_uri is rejected. Offers must be provided by value. |
| Claiming multiple credentials from one offer | § 4.1 | Partial | The SDK handles offers that reference multiple credential configurations by requesting each one, but each request yields a single credential. Batch issuance is not supported. |
Issuer and authorization server metadata
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Read credential issuer metadata | § 12.2 | Supported | The SDK reads /.well-known/openid-credential-issuer to discover endpoints and supported credentials. |
Read credential_configurations_supported | § 12.2.4 | Supported | The SDK reads and filters supported credentials to mDocs during discovery. |
| Authorization server discovery (separate AS) | § 3, § 12.3 | Supported | The SDK reads authorization_servers and discovers the authorization server metadata. A single authorization server is used. |
| Use credential issuer display metadata | § 12.2.4 | Partial | The SDK reads credential display metadata during discovery. iOS parses the full display set. Android currently surfaces the credential name. |
Authorization and tokens
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Access token acquisition and usage | § 6, § 8 | Supported | The SDK requests and uses an access token to call the credential endpoint. Both Bearer and DPoP token types are accepted. |
| Transaction code (PIN) for the Pre-authorized Code flow | § 4.1.1, § 6.1 | Supported | Your app collects the transaction code, and the SDK passes it during claiming. |
| Pushed Authorization Requests (PAR) | § 5.1.4 | Not supported | The SDK does not push authorization requests. Metadata fields are parsed but not acted on. |
Rich Authorization Requests (RAR) via authorization_details | § 5.1.1 | Not supported | The SDK requests credentials by scope, not through authorization_details. |
| Scope-based credential request | § 5.1.2 | Supported | The SDK derives the request scope from the offered credentials during the Authorization Code flow. |
| Client authentication (OAuth clients) | Appendix E | Partial | The SDK supports the none and attestation-based DPoP token endpoint authentication methods. Standard attest_jwt_client_auth (without DPoP) is not yet supported. |
Credential endpoint, request, and proofs
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Credential endpoint request | § 8 | Supported | The SDK posts the access token and proof to the credential endpoint. |
| Credential request identifier | § 8.2 | Supported | The SDK identifies the requested credential with credential_configuration_id. |
RAR credential identifier (credential_identifier) | § 8.2 | Not supported | The SDK always uses credential_configuration_id. |
| Proof of possession (key binding proof) | § 8.2, Appendix F | Supported | The SDK generates a device key proof of possession for each credential request. |
Proof type jwt | Appendix F.1 | Supported | The SDK builds a signed JWT proof. |
Proof type di_vp | Appendix F.2 | Not supported | Only jwt proofs are generated. |
Multiple proof submission (proofs) | § 8.2 | Partial | The SDK uses the v1.0 proofs object shape, but always submits a single proof. |
Credential response and deferred issuance
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Synchronous credential response | § 8.3 | Supported | The SDK handles the immediate credential response and stores the credential. |
| Deferred issuance | § 9 | Not supported | The SDK does not poll a deferred credential endpoint. Deferred response fields are parsed but not acted on. |
| Notification endpoint (holder to issuer events) | § 11 | Not supported | The SDK does not send OID4VCI lifecycle notifications to the issuer. |
Holder binding and nonce
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Cryptographic holder binding | § 8.1 | Supported | The SDK binds the credential to a device key it manages. |
c_nonce handling in the proof | § 7.2 | Supported | The SDK embeds a fresh nonce in its proof of possession. |
| Nonce endpoint | § 7 | Supported | When the issuer advertises a nonce endpoint, the SDK fetches a fresh nonce from it. |
Batch issuance
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Batch credential issuance | § 3.3.2 | Not supported | OID4VCI v1.0 has no separate batch credential endpoint. The SDK requests a single credential per credential endpoint call. Only the first credential in a credential response is consumed. |
Wallet attestation
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Wallet attestation (client attestation) | Appendix E | Supported | The SDK proves your app's authenticity to the issuer when required. It handles attestation proofs automatically once an SDK Backend is configured. See Wallet Attestation. |
Display and localization
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Use display metadata (credential and claims) | § 12.2.4 | Partial | iOS parses the full credential display set, including name, logo, description, and colors. Android currently surfaces the credential name. |
| Locale and language support | § 12.2.4 | Partial | Locale information is read where present. App-configurable locale selection is limited. |
Security and transport
| Feature | Spec | Status | Notes |
|---|---|---|---|
| TLS / HTTPS | § 13 | Supported | All requests use HTTPS. |
| PKCE | § 5.1, § 13 | Supported | PKCE with S256 is used in the Authorization Code flow. |
| DPoP (token binding, holder side) | § 13 | Partial | DPoP is used within the wallet attestation combined mode. The SDK does not perform standalone DPoP outside attestation, but it accepts DPoP-typed tokens. |
Credential formats
The MATTR Pi Holder SDKs are mDocs Holder SDKs. Only the ISO mdoc format (mso_mdoc) is
handled end to end. During discovery, the SDK filters the issuer's supported credentials to
mDocs, so an offer that contains only non-mDoc credentials fails discovery.
| Format | Spec | Status | Notes |
|---|---|---|---|
ISO mdoc / mDL (mso_mdoc) | Appendix A.2 | Supported | The only format claimed by the Holder SDK. |
SD-JWT VC (vc+sd-jwt) | Appendix A.3 | Not supported | Filtered out at discovery. |
W3C VC JWT (jwt_vc_json) | Appendix A.1.1 | Not supported | Filtered out at discovery. |
W3C VC JSON-LD (ldp_vc) | Appendix A.1.2 | Not supported | Filtered out at discovery. |
The SDK also rejects discovery when the issuer requires credential request or response encryption.
Not currently supported
At a glance, the following OID4VCI features are not currently supported by the Holder SDK:
- Credential offer by reference (
credential_offer_uri) (§ 4.1.3) - Pushed Authorization Requests (PAR) (§ 5.1.4)
- Rich Authorization Requests (RAR) via
authorization_details(§ 5.1.1) - RAR credential identifier (
credential_identifier) (§ 8.2) - Deferred issuance (§ 9)
- Notification endpoint (holder-to-issuer events) (§ 11)
- Batch credential issuance (§ 3.3.2)
di_vpproof type (Appendix F.2)- Credential formats other than mDocs (
mso_mdoc) (Appendix A)
Related
How would you rate this page?
Last updated on