OID4VCI feature support
A feature-by-feature reference for how MATTR VII supports the OpenID for Verifiable Credential Issuance (OID4VCI) v1.0 specification as a credential issuer and authorization server.
Overview
This page is a feature-by-feature reference for how MATTR VII supports the OpenID for Verifiable Credential Issuance (OID4VCI) v1.0 specification when acting as a credential issuer and authorization server.
It complements the OID4VCI overview, which explains what the standard is and how the flows work. Use this page when you need to know whether a specific OID4VCI feature is available on the issuer side before you design an integration.
If you are building a wallet or an app that claims credentials from an OID4VCI issuer, see the OID4VCI feature support (Holder SDK) 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 issuer role.
- Limited availability: Available behind a tenant configuration or as a closed beta. Contact us to enable it.
The Spec column cites the relevant clause of the OID4VCI v1.0 specification. A dash means the feature is a MATTR extension that is not defined by OID4VCI.
Support statuses reflect the current MATTR VII platform. If you need clarification on any feature, or want to discuss your issuance design, contact us.
Issuance flows
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Authorization Code flow | § 3.4, § 6 | Supported | Interactive flow where the holder authenticates with an authentication provider before the credential is issued. See the Authorization Code flow. |
| Pre-authorized Code flow | § 3.5, § 6 | Supported | Issuer prepares issuance in advance and hands the wallet a pre-authorized code. See the Pre-authorized Code flow. |
Credential offer
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Credential offer object | § 4.1 | Supported | MATTR VII builds a structured credential offer that tells the wallet which issuer to contact and which credentials are on offer. |
| Credential offer by value | § 4.1.2 | Supported | The offer is embedded directly in the offer URI delivered as a QR code, deep link, or wallet notification. |
Credential offer by reference (credential_offer_uri) | § 4.1.3 | Not supported | MATTR VII always returns an offer by value. It does not host the offer at a separate credential_offer_uri. |
| Multiple credentials in one offer | § 4.1 | Partial | An Authorization Code flow offer can reference multiple credential configurations. A Pre-authorized Code flow offer that uses a credential bundle is restricted to a single credential. |
Issuer and authorization server metadata
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Credential issuer metadata endpoint | § 12.2 | Supported | Published at GET /.well-known/openid-credential-issuer. |
| Authorization server metadata endpoint | § 12.3 | Supported | Published at GET /.well-known/oauth-authorization-server as a dedicated endpoint. |
credential_configurations_supported advertisement | § 12.2.4 | Supported | The v1.0 field advertising each credential the issuer can issue. The deprecated credentials_supported field is also still returned for backward compatibility. |
| Credential issuer display metadata (issuer branding) | § 12.2.4 | Not supported | MATTR VII does not publish top-level issuer branding (name, logo, locale) in its metadata. Per-credential display metadata is supported. See Display and localization. |
| Notification endpoint advertisement | § 12.2.4 | Not supported | MATTR VII does not advertise an OID4VCI notification endpoint. |
Authorization and tokens
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Access token requirement | § 8 | Supported | Every credential request must carry a valid OAuth 2.0 access token. Requests without a valid token are rejected before issuance. |
| Combined authorization server | § 3, § 12.3 | Supported | MATTR VII acts as both the credential issuer and the authorization server. It issues its own access tokens. |
| Separate authorization server | § 3, § 12.3 | Not supported | MATTR VII does not delegate token issuance to an external, standalone authorization server. |
| Transaction code (PIN) for the Pre-authorized Code flow | § 4.1.1, § 6.1 | Supported | The issuer can require the holder to enter a numeric transaction code before the pre-authorized code can be redeemed. |
| Pushed Authorization Requests (PAR) | § 5.1.4 | Not supported | The wallet cannot push its authorization request to a dedicated endpoint. |
Rich Authorization Requests (RAR) via authorization_details | § 5.1.1 | Not supported | Credentials are requested by scope, not through the authorization_details parameter. |
| Scope-based credential request | § 5.1.2 | Supported | The wallet requests a credential using an OAuth scope that maps to a credential configuration. |
| Client authentication (OAuth clients) | Appendix E | Limited availability | OAuth client management is available behind tenant configuration. Supported token endpoint authentication methods are none and attestation-based client authentication. |
Credential endpoint, request, and proofs
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Credential endpoint | § 8 | Supported | The wallet posts an access token here to request a credential. |
| Credential request identifier | § 8.2 | Supported | The v1.0 request identifies the credential to issue with credential_configuration_id, which corresponds to the credential offer and issuer metadata. The legacy format parameter is also still accepted. |
RAR credential identifier (credential_identifier) | § 8.2 | Not supported | The RAR-style credential_identifier from an authorization_details token response is not used. This is distinct from credential_configuration_id, which is supported. |
| Proof of possession (key binding proof) | § 8.2, Appendix F | Supported | Required for mDocs. The wallet proves control of the key that is bound into the credential. |
Proof type jwt | Appendix F.1 | Supported | Key ownership is proven with a signed JWT. |
Proof type di_vp | Appendix F.2 | Not supported | Only jwt proofs are accepted. |
Multiple proof submission (proofs) | § 8.2 | Partial | MATTR VII accepts the v1.0 proofs object, but currently uses a single proof and issues a single credential per request. Batch issuance is planned for a future release. |
Credential response and deferred issuance
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Synchronous credential response | § 8.3 | Supported | The signed credential is returned immediately in the credential response. |
| Deferred issuance (deferred credential endpoint) | § 9 | Not supported | MATTR VII does not return a transaction ID for a wallet to poll a deferred endpoint. |
| Notification endpoint (wallet to issuer events) | § 11 | Not supported | MATTR VII does not accept OID4VCI lifecycle notifications from wallets. |
Holder binding and nonce
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Cryptographic holder binding | § 8.1 | Supported | For mDocs, the credential is bound to a device key held by the wallet. |
c_nonce for proof freshness | § 7.2 | Supported | Needs to be enabled per tenant. When enabled, the wallet must include a fresh nonce in its key proof. |
| Nonce endpoint | § 7 | Supported | Needs to be enabled per tenant. When nonce enforcement is enabled, MATTR VII exposes and advertises a dedicated nonce endpoint so the wallet can fetch a fresh nonce. |
Batch and multiple issuance
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Batch credential issuance | § 3.3.2 | Not supported | OID4VCI v1.0 has no separate batch credential endpoint. MATTR VII issues a single credential per request. |
Wallet and client attestation
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Wallet attestation (OAuth client attestation) | Appendix E | Supported | Needs to be enabled per tenant. An issuer tenant can require a DPoP-based client attestation before issuing credentials. See Wallet Attestation. |
Display and localization
| Feature | Spec | Status | Notes |
|---|---|---|---|
| Credential display metadata | § 12.2.4 | Supported | The issuer can publish display hints for a credential, such as name, background color, text color, and logo. |
| Claims display metadata | § 12.2.4 | Partial | Per-claim display labels are emitted for mDocs credential configurations. |
| Locale and language support | § 12.2.4 | Partial | Display metadata carries a locale field. Localized display selection is limited in practice. |
Security and transport
| Feature | Spec | Status | Notes |
|---|---|---|---|
| TLS / HTTPS for all endpoints | § 13 | Supported | All issuer and authorization server endpoints require HTTPS. |
| PKCE for the Authorization Code flow | § 5.1, § 13 | Supported | The S256 code challenge method is advertised and enforced. |
| Access token binding to the credential endpoint | § 8, § 13 | Supported | Access tokens are audience-scoped to the tenant resource and re-checked at the credential endpoint. |
| DPoP (proof of possession for tokens) | § 13 | Supported | DPoP is supported with the ES256 algorithm. Access tokens can be bound to the wallet's key. |
Credential formats MATTR VII issues
MATTR's primary issuance format is mDocs (mso_mdoc), the ISO/IEC 18013-5 mobile document
format. MATTR VII also issues its own compact formats through the Authorization Code flow.
| Format | Spec | Supported | Notes |
|---|---|---|---|
ISO mdoc / mDL (mso_mdoc) | Appendix A.2 | Supported | The primary issuance format. Available through both the Authorization Code and Pre-authorized Code flows. |
| CWT | — | Supported | A MATTR compact credential format, issued through the Authorization Code flow. See CWT. |
| Semantic CWT | — | Supported | A W3C-VC-shaped MATTR compact format, issued through the Authorization Code flow. See CWT. |
SD-JWT VC (vc+sd-jwt) | Appendix A.3 | Limited availability | Implemented in pre-prod environments, where MATTR VII has participated in interoperability events issuing this credential format. If you are interested in enabling it, contact us. |
W3C VC JWT (jwt_vc_json) | Appendix A.1.1 | Not supported | Not currently issued by MATTR VII. |
Format availability by flow:
- Authorization Code flow: mDocs, CWT, and Semantic CWT.
- Pre-authorized Code flow: mDocs only.
Not currently supported
At a glance, the following OID4VCI features are not currently supported by MATTR VII as an issuer:
- Credential offer by reference (
credential_offer_uri) (§ 4.1.3) - Separate (external) authorization server (§ 3, § 12.3)
- Pushed Authorization Requests (PAR) (§ 5.1.4)
- Rich Authorization Requests (RAR) via
authorization_details(§ 5.1.1) - Deferred issuance and the deferred credential endpoint (§ 9)
- Notification endpoint (issuer advertisement and wallet-to-issuer events) (§ 11, § 12.2.4)
- Batch credential issuance (§ 3.3.2)
di_vpproof type (Appendix F.2)- W3C VC JWT credential format (Appendix A.1.1)
Related
How would you rate this page?
Last updated on