Skip to content

APTITUDE RFC-01 Credential Issuance Profile

Version 0.1 (Draft)

Authors

  • Nikos Triantafyllou, University of the Aegean

Reviewers

  1. Degani Giancarlo, Infocert
  2. Andreea Prian, IDAKTO
  3. Leonardo Pio Palumbo, ipzs
  4. Leone Riello, Infocert
  5. George Fourtounis, GRNET

Table of Contents

1 Introduction

This document is part of APTITUDE horizontal interoperability RFC for credential issuance.

It establishes the baseline, cross-pilot profile to be used by APTITUDE pilots and technical implementations for the issuance of Verifiable Credentials in a consistent and testable manner.

This RFC profiles issuance based on:

  • OpenID for Verifiable Credential Issuance (OpenID4VCI) 1.0
  • OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0
  • ETSI TS 119 472-3

The purpose of this document is to provide:

  • a stable starting point for interoperability across APTITUDE pilots;
  • a common baseline for Wallets, Issuers, and Authorisation Servers;
  • a requirements set that can be translated into ITB+ conformance test suites;
  • a basis for pilot-specific issuance profiles that need stricter domain or credential-format constraints.

This specification focuses only on issuance. It covers wallet-initiated and issuer-initiated issuance, including both Authorisation Code Flow and Pre-Authorised Code Flow, together with the metadata, security bindings, and proof mechanisms needed to support interoperable issuance.

This document does not define presentation or verifier behavior as such. However, where issuance-side metadata is required so that a Wallet can later enforce issuer-defined disclosure or reuse constraints, this document includes those issuance-side requirements.

2 Scope

This specification defines:

  • a baseline profile of OpenID4VCI for issuing Verifiable Credentials;
  • requirements for Wallets that request, receive, validate, and store credentials;
  • requirements for Credential Issuers and their Authorisation Servers;
  • support for wallet-initiated issuance and issuer-initiated issuance via Credential Offer;
  • support for both Authorisation Code Flow and Pre-Authorised Code Flow;
  • the minimum endpoints, metadata, and request-processing rules necessary to enable interoperable issuance;
  • issuance-side requirements for wallet attestation, proof-of-possession, device binding, and deferred issuance;
  • conditional notification handling where the selected deployment supports issuance notifications;
  • issuance-side metadata elements needed by the Wallet for later lifecycle or disclosure handling, where such elements are delivered as part of issuance.

This document is intentionally horizontal and cross-pilot. It does not define credential-specific claim sets, domain schemas, or sector-specific assurance rules, except where a specific issuance profile requires explicit protocol-level constraints.

This document describes:

  • issuance protocol flows;
  • baseline security and privacy requirements;
  • interfaces and endpoints, including Wallet invocation, Credential Offer, PAR, Token, Credential, Deferred Credential, Nonce, Notification, and metadata endpoints where applicable;
  • conformance requirements that can be mapped to ITB+ test cases.

2.1 Out of Scope

The following are out of scope for this RFC:

  • presentation and verification flows;
  • verifier requirements;
  • trust framework governance, federation policy, and trust-list operations, except where issuance processing requires validation against such trust material;
  • credential-specific semantic profiles and domain-specific claim definitions;
  • pilot-specific UX constraints;
  • business, legal, or organisational policy beyond the protocol-visible issuance requirements captured in metadata.

3 Normative Language

The key words SHALL, SHALL NOT, SHOULD, SHOULD NOT, MAY, and OPTIONAL in this document are to be interpreted as described in RFC 2119 and RFC 8174.

4 Roles and Components

This specification uses the following roles:

  • Wallet Unit / Wallet: The Wallet Unit, as defined in the ARF and APTITUDE glossary, including its Wallet Instances, acting on behalf of the Holder to request, receive, validate, store, and manage Verifiable Credentials and associated cryptographic material. Where the distinction between Wallet Unit and Wallet Instance is not material, this RFC uses the short term Wallet.
  • Holder: As defined in the APTITUDE glossary (aligned with the ARF notion of (Wallet) User): the natural person or legal representative controlling the Wallet and authorising credential issuance or presentation.
  • Credential Issuer (Issuer): As defined in the APTITUDE glossary and aligned with the ARF: the entity that decides to issue Verifiable Credentials and operates, or is associated with, the issuance service.
  • Authorisation Server (AS): As defined in the APTITUDE glossary and aligned with the ARF: the OAuth 2.0 / OpenID component responsible for authenticating the Holder and issuing tokens authorising access to the Credential and related endpoints.

The Authorisation Server MAY be co-located with the Credential Issuer or MAY be operated separately.

5 Protocol Overview

The APTITUDE issuance baseline is based on OpenID4VCI 1.0 and constrained by HAIP 1.0 choices relevant to issuance interoperability. Where required for EUDI Wallet ecosystem alignment, this profile also incorporates issuance-side requirements drawn from ETSI TS 119 472-3.

The profile adopts the following baseline choices:

  • support for Authorisation Code Flow for issuance interactions requiring Holder authentication and authorisation;
  • support for Pre-Authorised Code Flow for issuer-initiated issuance scenarios where issuance is initiated through a Credential Offer and the applicable grant is pre-authorised;
  • support for issuer-initiated issuance via Credential Offer;
  • support for wallet-initiated issuance, where the Wallet selects a credential type or credential configuration and derives the corresponding request parameters from Issuer metadata;
  • use of Pushed Authorisation Requests (PAR) for Authorisation Code Flow requests under this profile;
  • use of PKCE with S256 for Authorisation Code Flow;
  • use of sender-constrained access tokens, for example with DPoP or an equivalent supported mechanism;
  • use of Wallet Instance Attestation (WIA) as client attestation material at the PAR and Token endpoints where Authorisation Code Flow is used;
  • support for proof-of-possession / key binding during credential issuance;
  • support for Wallet Unit Attestation (WUA) and proofs structures at the Credential Endpoint for device-bound issuance;
  • support for deferred issuance where immediate issuance is not possible;
  • support for issuance-side metadata needed to communicate issuer-defined reuse and disclosure constraints to the Wallet.

Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, Wallets and Issuers SHALL additionally support the A128GCM and A256GCM algorithms, in addition to the cryptographic suites required by OpenID4VC-HAIP.

Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, the following additional issuance requirements also apply:

  • same-device Wallet invocation SHALL support the custom URL scheme eu-eaa-offer://;
  • Issuer Metadata SHALL be signed metadata as defined by OpenID4VCI, and the JWS protected header SHALL carry the Issuer access certificate in x5c as profiled by ETSI;
  • Issuer Metadata SHALL support the issuer_info metadata parameter to transport issuer registration material, including the registration certificate and registrar-provided registration information, as profiled by ETSI.

Under ETSI TS 119 472-3, providers shall support at least one of authorization_code or urn:ietf:params:oauth:grant-type:pre-authorized_code in the Credential Offer. This RFC profiles both, and treats them as first-class issuance paths. PAR requirements apply only to the Authorisation Code Flow path.

For Authorisation Code Flow, this profile assumes the Wallet interacts with the Authorisation Server using PAR, receives an authorisation code, exchanges it at the Token Endpoint, and then calls the Credential Endpoint. Under ETSI, WIA is carried at both the PAR and Token endpoints, together with proof-of-possession of the key referenced in the WIA cnf claim.

For device-bound issuance, ETSI requires the Credential Request to carry a proofs parameter containing either jwt or attestation. In the jwt mechanism, the Wallet proves possession of a key to be bound to the credential and carries the WUA in the key_attestation protected header parameter. In the attestation mechanism, the Wallet carries the WUA directly without separate proof-of-possession of each attested key. The issuer's processing rules differ accordingly and will be profiled in the normative sections below.

5.1 Credential Format Baseline

This RFC defines the interoperability baseline at protocol level and is format-aware but not format-exclusive.

For APTITUDE pilots, credential formats MAY include:

  • SD-JWT VC;
  • ISO mdoc, where adopted by a pilot-specific profile.

Where an implementation or pilot-specific profile supports ETSI-defined credential formats with additional Issuer Metadata requirements, those additional metadata rules SHALL also apply. In particular:

  • support for X509-AC EAA issuance SHALL be reflected using the x509_attr format identifier;
  • support for JSON-LD W3C VC EAA secured with JOSE SHALL be reflected using the vc+jwt format identifier;
  • support for JSON-LD W3C VC EAA secured with SD-JWT SHALL be reflected using the vc+sd-jwt format identifier.

To preserve a stable horizontal baseline, pilot-specific RFCs SHALL specify any additional constraints for a concrete credential format and SHALL NOT relax the mandatory requirements in this document.

5.2 Pilot-specific extensions

Pilot-specific issuance RFCs MAY extend this profile with:

  • concrete credential configuration identifiers;
  • claim set and schema rules;
  • assurance-level requirements;
  • format-specific proof rules;
  • issuance policy constraints.

Such extensions SHALL remain compatible with this baseline.

6 High-level Flows

This section describes the high-level issuance interactions supported by this RFC.

This profile supports:

  • wallet-initiated issuance;
  • issuer-initiated issuance via Credential Offer;
  • Authorisation Code Flow;
  • Pre-Authorised Code Flow;
  • immediate issuance and deferred issuance.

For issuance interactions using the Authorisation Code Flow, the Wallet uses PAR before user authorisation. For this path, ETSI TS 119 472-3 requires the Wallet to send Wallet Instance Attestation (WIA) to the PAR Endpoint and again to the Token Endpoint, together with proof-of-possession of the key referenced by the WIA cnf claim.

For issuance interactions using the Pre-Authorised Code Flow, no PAR or authorisation redirect is required. The Wallet processes the Credential Offer, redeems the pre-authorised grant at the Token Endpoint, and proceeds to the Credential Endpoint.

For device-bound issuance, the Wallet sends a Credential Request containing a proofs structure as profiled by this RFC. ETSI TS 119 472-3 requires use of Wallet Unit Attestation (WUA) at the Credential Endpoint, either carried in the protected header of proofs.jwt[*] or directly in proofs.attestation[*], depending on the mechanism used.

Because this RFC is issuance-only, presentation and verifier behavior are not described here except where issuer-provided issuance metadata is needed by the Wallet for later use.

6.1 Wallet-initiated Issuance Flow

Actors: Holder, Wallet, Issuer (AS and Credential Issuer).

6.1.1 Configuration and discovery

  1. The Wallet retrieves Issuer metadata, including at minimum:
    • OAuth / OpenID configuration;
    • Credential Issuer metadata;
    • supported credential configurations;
    • the mapping between offered credential configurations and the request parameters needed to initiate issuance;
    • supported grant types;
    • supported proof methods and related nonce requirements;
    • issuance-side policy metadata required by the applicable profile.
  2. Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, the Wallet additionally retrieves and processes signed Issuer Metadata carrying: - the Issuer access certificate in the JWS x5c protected header; and - the issuer_info metadata parameter for issuer registration material.
  3. The Wallet determines whether the selected issuance interaction is supported through:
    • Authorisation Code Flow;
    • Pre-Authorised Code Flow; or
    • both.

6.1.2 User selects credential

  1. The Holder chooses a credential type or credential configuration.
  2. The Wallet identifies the corresponding credential configuration and the applicable issuance path.
  3. Where the selected issuance path is wallet-initiated Authorisation Code Flow, the Wallet prepares an authorisation request as defined below.

6.1.3 Pushed Authorisation Request (PAR)

  1. For wallet-initiated Authorisation Code Flow, the Wallet constructs an authorisation request containing at minimum: - client_id; - the relevant scope, authorization_details, or other profiled authorisation parameters; - code_challenge using PKCE S256; - redirect_uri; - response_type=code; - state;
    - nonce, where required.
  2. The Wallet sends the request to the Issuer's PAR Endpoint.
  3. Where this profile requires Wallet Instance Attestation (WIA) for the Authorisation Code Flow path, the Wallet includes: - the WIA at the PAR request; and - proof-of-possession of the key referenced in the WIA cnf claim, according to the profiled mechanism.
  4. The PAR Endpoint validates the request and returns a request_uri and validity information.

6.1.4 User authorisation

  1. The Wallet directs the Holder to the Authorisation Endpoint using the request_uri obtained from PAR.
  2. The Holder authenticates according to the Issuer's policy.
  3. The Holder authorises the issuance transaction.
  4. The Authorisation Server redirects back to the Wallet with an authorisation code and state.

6.1.5 Token request

  1. The Wallet sends a token request to the Token Endpoint, including: - grant_type=authorization_code; - code; - redirect_uri; - code_verifier; - client authentication using wallet attestation or the profiled mechanism.
  2. Where this profile requires Wallet Instance Attestation (WIA) for the Authorisation Code Flow path, the Wallet includes: - the WIA at the Token Endpoint; and - proof-of-possession of the key referenced in the WIA cnf claim.
  3. The Token Endpoint validates the request and returns: - a sender-constrained access_token; - optional additional values such as c_nonce, refresh_token, or related token metadata, according to the applicable profile.

6.1.6 Credential request

  1. Before calling the Credential Endpoint, the Wallet obtains a fresh nonce from the Issuer's Nonce Endpoint where required by the selected proof method or issuance profile.
  2. The Wallet sends a request to the Credential Endpoint containing: - Authorization: Bearer {access_token}; - the requested credential configuration or other format-specific request parameters; - a proofs structure or equivalent proof material, according to the selected proof mechanism.
  3. For device-bound issuance, the request SHALL include issuance proof material that binds the issued credential to Wallet-controlled key material.
  4. Where the selected proof method is based on proofs.jwt: - the Wallet proves possession of the private key to be bound to the credential; and - the Wallet carries the Wallet Unit Attestation (WUA) in the protected header parameter profiled for key attestation.
  5. Where the selected proof method is based on proofs.attestation: - the Wallet carries the Wallet Unit Attestation (WUA) directly in the attestation structure; and - the Issuer processes the request according to the rules applicable to attested keys under the selected profile.
  6. The Credential Issuer validates: - the access token and its sender-constraining mechanism; - the credential request syntax; - the nonce and proof material; - the applicable wallet attestation material; - issuance policy; - any credential-specific prerequisites.
  7. The Issuer returns the credential immediately, or signals deferred issuance.

6.1.7 Storage

  1. The Wallet validates the returned credential and associated metadata.
  2. The Wallet stores the credential under Holder control.
  3. The Wallet stores any issuer-provided metadata or policy information that is required for later lifecycle or disclosure handling.

6.2 Issuer-initiated Issuance via Credential Offer

In the issuer-initiated flow, the Issuer first decides to issue and then provides a Credential Offer that the Wallet uses to continue the issuance process.

Actors: Holder, Wallet, Issuer, optionally Authorisation Server.

6.2.1 Issuance decision

  1. The Holder interacts with the Issuer in a business process such as onboarding, enrolment, registration, or completion of an eligibility step.
  2. Following successful checks, the Issuer decides to issue one or more credentials.

6.2.2 Credential Offer creation

  1. The Issuer constructs a Credential Offer that includes at minimum: - the credential_issuer identifier; - one or more offered credential identifiers or credential configurations; - grant information for one or more supported issuance paths; - the authorisation parameters or pre-authorised grant information needed by the Wallet to continue the flow.
  2. The Credential Offer MAY support either: - Authorisation Code Flow; - Pre-Authorised Code Flow; or - both.

6.2.3 Credential Offer delivery and Wallet invocation

  1. The Issuer delivers the offer to the Holder by one of: - displaying a QR code;
    - providing a link;
    - invoking a same-device Wallet using a supported Wallet invocation mechanism.
  2. Issuers and Wallets SHALL support both same-device and cross-device delivery of Credential Offers.
  3. For same-device, implementations SHALL support at least the custom URL scheme openid-credential-offer://.
  4. Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, implementations SHALL additionally support the custom URL scheme eu-eaa-offer://.
  5. For cross-device, implementations SHALL support delivery through a QR code carrying a valid Credential Offer URI
  6. Additional wallet invocation mechanisms remain optional.

6.2.4 Wallet processes the offer

  1. The Wallet receives the Credential Offer.
  2. The Wallet parses the offer and determines: - the Issuer base URL;
    - offered credential configurations;
    - applicable grant information;
    - required authorisation parameters.
  3. The Wallet displays the offer to the Holder and asks for confirmation to proceed.

6.2.5 Authorisation Code Flow variant

  1. Where the Credential Offer uses Authorisation Code Flow, the Wallet initiates the authorisation process using PAR.
  2. The Wallet follows the same Authorisation Code Flow defined in Section 6.1 for: - PAR; - user authorisation; - token acquisition; - credential request; - storage.
  3. Where this profile requires WIA for this path, the Wallet sends WIA at the PAR and Token endpoints as described in Section 6.1.

6.2.6 Pre-Authorised Code Flow variant

  1. Where the Credential Offer uses Pre-Authorised Code Flow, the Wallet does not perform a PAR request or browser-based authorisation redirect.
  2. The Wallet sends a token request to the Token Endpoint including: - grant_type=urn:ietf:params:oauth:grant-type:pre-authorized_code; - the pre-authorized_code; - a transaction code or user code where required by the offer or by the applicable profile; - client authentication and sender-constraining material where required by the profiled mechanism.
  3. The Token Endpoint validates the pre-authorised grant and returns: - a sender-constrained access_token; - optional additional values such as c_nonce, refresh_token, or related token metadata, according to the applicable profile.
  4. The Wallet then proceeds to the Credential Endpoint as defined in Section 6.1.6.

6.2.7 Credential request

  1. The Wallet sends a Credential Request or Batch Credential Request to the Credential Endpoint.
  2. The request includes: - the access token; - the requested credential configuration information; - the applicable proof material; - Wallet Unit Attestation where required by the selected proof method or profile.
  3. The Issuer validates the request and either returns the credential or initiates deferred issuance.

6.2.8 Deferred issuance continuation

  1. If issuance cannot be completed immediately, the Issuer returns the information required for deferred retrieval.
  2. The Wallet stores the transaction state and continues as defined in Section 6.3.

6.3 Deferred Credential Request

Deferred issuance allows the Issuer to complete credential production asynchronously while preserving the issuance transaction state.

  1. Where the Credential Endpoint cannot immediately return the credential, the Issuer returns the information needed for later retrieval, such as a transaction identifier and any endpoint or polling details required by the profile.
  2. The Wallet stores the deferred issuance state.
  3. The Wallet later calls the Deferred Credential Endpoint using the required access token and deferred issuance reference.
  4. The Issuer either: - returns the issued credential; - indicates that issuance is still pending; or - returns an error if the deferred issuance transaction cannot be completed.
  5. The Wallet repeats the retrieval only in accordance with the Issuer's indicated retry or polling guidance.
  6. Once the credential is returned, the Wallet validates and stores it as in Section 6.1.7.

7 Normative Requirements

This section defines the baseline normative requirements for APTITUDE implementations of the issuance profile.

Unless otherwise stated, the requirements in this section apply to issuance interactions only.

7.1 Common requirements (Wallet and Issuer)

Both Wallet and Issuer SHALL:

  1. Support OpenID4VCI 1.0 for credential issuance.
  2. Support metadata-based discovery.
  3. Support wallet-initiated issuance.
  4. Support issuer-initiated issuance via Credential Offer.
  5. Support at least one of the following issuance grant types: - Authorisation Code Flow; - Pre-Authorised Code Flow.
  6. Support Authorisation Code Flow where the deployment requires Holder authentication and interactive authorisation.
  7. Support Pre-Authorised Code Flow where the deployment profile or issuance scenario permits issuer-initiated issuance without an interactive authorisation redirect.
  8. Support sender-constrained access tokens.
  9. Support proof-of-possession / holder-binding during issuance, as required by the selected credential format and binding model.
  10. Support issuance-time metadata required to construct and process issuance requests.
  11. Support deferred issuance where the selected deployment profile or issuance process cannot always return the credential synchronously.
  12. Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, support the A128GCM and A256GCM algorithms in addition to the cryptographic suites required by OpenID4VC-HAIP.
  13. Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, support same-device Wallet invocation using the eu-eaa-offer:// custom URL scheme.

Both Wallet and Issuer SHOULD:

  1. Support both immediate and deferred issuance responses.
  2. Support Batch Credential Requests where required by a more specific pilot or credential profile.
  3. If the Wallet supports issuance notifications and receives a notification_id from the Issuer, support one or more Notification Requests for that notification_id in accordance with the applicable notification mechanism.

For issuance interactions using Authorisation Code Flow, both Wallet and Issuer SHALL additionally:

  1. Support Pushed Authorisation Requests (PAR).
  2. Support PKCE with the S256 code challenge method.
  3. Support Wallet Instance Attestation handling at the PAR and Token endpoints where required by this profile.

7.2 Credential Offer

Issuers SHALL:

  1. Support Credential Offers for issuer-initiated issuance.
  2. Include the credential_issuer identifier in the Credential Offer.
  3. Include one or more offered credential identifiers or credential configuration identifiers sufficient for the Wallet to determine what is being offered.
  4. Include the grant information required by the Wallet to continue issuance.
  5. Support at least one of the following grant types in Credential Offers: - authorization_code; - urn:ietf:params:oauth:grant-type:pre-authorized_code.
  6. Include all grant-specific parameters needed by the Wallet to continue the flow.
  7. Ensure that the Credential Offer can be resolved consistently against Issuer metadata.
  8. Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile and the offer is used for same-device invocation, support delivery using the eu-eaa-offer:// custom URL scheme.

Issuers SHOULD:

  1. Support both same-device and cross-device offer delivery.
  2. Support QR-code-based delivery and URI-based invocation.
  3. Support Credential Offers containing multiple offered credential configurations where the issuance scenario requires this.

Wallets SHALL:

  1. Be able to parse Credential Offers compliant with the applicable OpenID4VCI profile.
  2. Extract the Issuer identifier, offered credential configurations, and grant information.
  3. Determine from the offer whether the issuance path uses: - Authorisation Code Flow; - Pre-Authorised Code Flow; or - both.
  4. Use the Credential Offer information consistently in later token and credential requests.
  5. Support same-device receipt via a supported Wallet invocation method.
  6. Support cross-device receipt via a QR code carrying a valid Credential Offer URI.
  7. Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, support same-device receipt via the eu-eaa-offer:// custom URL scheme.

Wallets SHOULD:

  1. Validate that the offered credential identifiers or configurations are supported by the Issuer metadata before proceeding.
  2. Present the Credential Offer to the Holder in a way that makes the offered credentials and issuing party clear.

7.3 Authorisation Endpoint and PAR

This section applies only to issuance transactions using Authorisation Code Flow.

Issuers SHALL:

  1. Expose a PAR endpoint for issuance transactions using Authorisation Code Flow.
  2. Require PAR for all authorisation requests under this profile.
  3. Reject direct front-channel authorisation requests not preceded by PAR where this profile requires PAR.
  4. Require the Wallet to include the credential-related authorisation parameters needed for the selected credential configuration and issuance path.
  5. Require PKCE with S256.
  6. Require consistent use of client_id across PAR and Token requests.
  7. Require Wallet Instance Attestation (WIA) at the PAR endpoint where this profile applies ETSI-aligned wallet attestation.
  8. Require proof-of-possession of the public key referenced in the WIA cnf claim.
  9. Verify that the WIA signature validates under the Wallet Provider public key from the applicable trusted list.
  10. Verify that the WIA is not expired.
  11. Verify that the proof-of-possession validates under the public key referenced in the WIA cnf claim.

Wallets SHALL:

  1. Use PAR for all Authorisation Code Flow requests under this profile.
  2. Include the required credential-related authorisation parameters.
  3. Include client_id, response_type=code, redirect_uri, state, and PKCE parameters.
  4. Include nonce where required by the selected profile or issuer policy.
  5. Include WIA at the PAR endpoint where this profile requires it.
  6. Include proof-of-possession of the public key referenced in the WIA cnf claim.
  7. Ensure that client_id is used consistently across PAR and Token requests.

Wallets SHOULD:

  1. Check metadata in advance to determine whether additional authorisation parameters or authorization_details are required.
  2. Treat expired or rejected WIA material as a recoverable client-authentication failure and obtain fresh attestation material before retrying.

7.4 Token Endpoint and Wallet Attestation

This section applies to:

  • Authorisation Code Flow, and
  • Pre-Authorised Code Flow where the selected deployment requires wallet client authentication or equivalent sender-constraining material at the Token Endpoint.

For Authorisation Code Flow, Wallets SHALL:

  1. Send a Token Request containing: - grant_type=authorization_code; - code; - redirect_uri; - code_verifier.
  2. Include WIA at the Token Endpoint where this profile applies ETSI-aligned wallet attestation.
  3. Include proof-of-possession of the public key referenced in the WIA cnf claim.
  4. Ensure consistency between the authenticated Wallet identity and the client_id used earlier in the transaction.

For Pre-Authorised Code Flow, Wallets SHALL:

  1. Send a Token Request containing: - grant_type=urn:ietf:params:oauth:grant-type:pre-authorized_code; - the pre-authorized_code; - any transaction code or user code required by the offer or deployment profile.
  2. Include any client-authentication or sender-constraining material required by the selected deployment profile.
  3. Use the returned access token consistently in subsequent credential requests.

Issuers SHALL:

  1. Expose a Token Endpoint.
  2. Validate the Token Request according to the applicable grant type.
  3. For Authorisation Code Flow, validate PKCE inputs and authorisation-code state as required by OAuth/OpenID4VCI.
  4. Where WIA is required, validate: - the WIA signature under the Wallet Provider public key from the applicable trusted list; - the WIA expiry; - the proof-of-possession under the public key referenced in the WIA cnf claim.
  5. Issue sender-constrained access tokens.
  6. Bind token usage to the Wallet according to the selected sender-constraining mechanism.
  7. Return any c_nonce or related token metadata needed by the selected proof mechanism.

Issuers SHOULD:

  1. Support refresh tokens where long-lived issuance processes, renewal, or deferred issuance need them.
  2. Consider the sensitivity of the credential type before issuing long-lived refresh tokens.

Wallets SHALL:

  1. Support sender-constrained token usage in subsequent calls to the Credential Endpoint.
  2. Process returned c_nonce or equivalent issuance-related token metadata where needed by the selected proof mechanism.

7.5 Credential Endpoint

Issuers SHALL:

  1. Expose a Credential Endpoint.
  2. Support issuance requests for the credential configurations published in Issuer metadata.
  3. Validate the access token and sender constraint.
  4. Validate the credential request syntax and requested credential configuration.
  5. For device-bound issuance, require the proofs parameter.
  6. Require that proofs contain either: - the jwt child member; or - the attestation child member.
  7. Validate the nonce and proof material according to the selected proof method.
  8. Validate Wallet Unit Attestation (WUA) according to the selected proof method.
  9. Return either: - the issued credential; or - a deferred issuance response.

Wallets SHALL:

  1. Send a Credential Request containing the requested credential configuration or other format-specific request parameters.
  2. For device-bound issuance, include the proofs parameter.
  3. Populate proofs using either: - proofs.jwt; or - proofs.attestation; according to the selected binding model and issuer requirements.
  4. Obtain and use a fresh nonce from the Issuer's Nonce Endpoint where required by the selected proof method.
  5. Validate the returned credential, including issuer binding and format-specific integrity checks.
  6. Store only credentials that have successfully passed Wallet validation.

7.5.1 Credential Request using proofs.jwt

Wallets SHALL:

  1. Include exactly one element in the jwt array.
  2. Include a valid nonce claim in the JWT body, obtained from the Issuer's Nonce Endpoint.
  3. Include the key_attestation protected header parameter.
  4. Carry the Wallet Unit Attestation (WUA) in that key_attestation parameter.
  5. Ensure that the WUA contains one or more attested public keys owned by the Wallet Unit.
  6. Sign the JWT using the private key corresponding to the first public key in the attested_keys claim of the WUA.

Issuers SHALL:

  1. Verify that the WUA signature in key_attestation validates under the Wallet Provider public key from the applicable trusted list.
  2. Verify that the JWT signature validates under the first public key in the attested_keys array of the WUA.
  3. Verify that the JWT contains a valid nonce from the Issuer's Nonce Endpoint.
  4. Generate as many credentials as there are attested public keys in the WUA, where the applicable profile requires multi-key issuance.
  5. Bind each issued credential to one of the attested public keys.
  6. Ensure that no two issued credentials in the transaction are bound to the same public key.

7.5.2 Credential Request using proofs.attestation

Wallets SHALL:

  1. Include exactly one element in the attestation array.
  2. Include a valid nonce claim in the JWT body, obtained from the Issuer's Nonce Endpoint.
  3. Carry the Wallet Unit Attestation (WUA) directly as the single attestation element.

Issuers SHALL:

  1. Verify that the WUA signature validates under the Wallet Provider public key from the applicable trusted list.
  2. Generate as many credentials as there are attested public keys in the WUA, where the applicable profile requires multi-key issuance.
  3. Bind each issued credential to one of the attested public keys.
  4. Ensure that no two issued credentials in the transaction are bound to the same public key.

Issuers SHOULD:

  1. Reject malformed or semantically inconsistent proofs structures with explicit error information where possible.
  2. Distinguish clearly between nonce failure, attestation failure, proof failure, and policy failure.

7.6 Deferred Credential Endpoint

Issuers SHALL:

  1. Expose a Deferred Credential Endpoint where the deployment supports deferred issuance.
  2. Return the information needed by the Wallet to retrieve deferred credentials.
  3. Validate deferred retrieval tokens, references, or transaction identifiers.
  4. Publish the Deferred Credential Endpoint in metadata where supported.
  5. Return explicit terminal errors for expired, denied, or otherwise failed deferred issuance transactions.

Issuers SHOULD:

  1. Provide retry guidance or polling hints.
  2. Preserve transaction state for a duration appropriate to the issuance process.

Wallets SHALL:

  1. Recognise deferred issuance responses.
  2. Persist the transaction state needed to continue deferred retrieval.
  3. Poll or retry according to the Issuer's guidance until completion or terminal failure.
  4. Distinguish pending and failed issuance states in Wallet behaviour.

Wallets SHOULD:

  1. Apply retry intervals and back-off.
  2. Allow the Holder to stop retrying or resume later.

7.7 Server Metadata

Issuers SHALL publish metadata that includes:

  1. OAuth 2.0 / OpenID configuration, including Authorisation, Token, and PAR endpoints.
  2. Credential Issuer metadata describing supported credential configurations.
  3. The Credential Endpoint location.
  4. The Deferred Credential Endpoint location, where supported.
  5. Any relevant proof types, credential format support, and associated configuration data required by Wallets.
  6. The format identifiers x509_attr, vc+jwt, and/or vc+sd-jwt, where the Issuer supports the corresponding ETSI-defined credential formats.
  7. Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, signed Issuer Metadata whose JWS protected header carries the Issuer access certificate in x5c.
  8. Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, the issuer_info metadata parameter carrying issuer registration material, including the registration certificate and registrar dataset, as profiled by ETSI.

Wallets SHALL:

  1. Retrieve and process Issuer metadata.
  2. Use metadata to construct authorisation and credential requests.
  3. Use metadata to interpret Credential Offers and supported credential configurations.
  4. Where notification support is implemented and the Issuer provides a notification_id, use Issuer metadata or the applicable profile to determine how Notification Requests are sent.
  5. Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, process signed Issuer Metadata x5c and issuer_info content as part of issuer validation and registration-material handling.

8 Interface Definitions

This section defines the logical interfaces for conformance testing. Exact URL paths are deployment-specific and discovered through metadata.

8.1 Wallet Invocation Interface

  • Direction: Issuer to Wallet
  • Transport: custom URI, QR code, or equivalent Wallet invocation mechanism

Wallets and Issuers SHOULD support at least one interoperable Wallet invocation method suitable for both same-device and cross-device use.

Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, the same-device invocation method SHALL include the eu-eaa-offer:// custom URL scheme.

8.2 Credential Offer Interface

  • Direction: Issuer to Wallet

The Credential Offer SHALL contain at least:

  • credential_issuer;
  • grant information;
  • credential identifiers or credential configuration identifiers;
  • the information the Wallet needs to continue the issuance flow.

The exact JSON structure SHALL comply with OpenID4VCI.

8.3 PAR Endpoint

  • Direction: Wallet to Issuer (AS)
  • Method: POST

Request (logical fields)

  • client_id
  • credential-related authorisation parameters
  • code_challenge
  • code_challenge_method=S256
  • redirect_uri
  • response_type=code
  • state
  • optional nonce

Response

  • request_uri
  • expires_in

8.4 Token Endpoint

  • Direction: Wallet to Issuer (AS)
  • Method: POST

Request (logical fields)

  • grant_type=authorization_code
  • code
  • redirect_uri
  • code_verifier
  • client authentication material

Response

  • access_token
  • token_type
  • expires_in
  • optional c_nonce
  • optional refresh_token

8.5 Credential Endpoint

  • Direction: Wallet to Issuer
  • Method: POST

Request (logical fields)

  • Authorization: Bearer {access_token}
  • requested credential configuration or identifier
  • format-specific request information
  • proof material

Response

  • issued credential(s), or
  • deferred issuance response

8.6 Nonce Endpoint

  • Direction: Wallet to Issuer
  • Method: POST or as defined by metadata/profile

If the Issuer requires a fresh nonce for proof generation, the Issuer SHALL expose and document the relevant mechanism in metadata.

8.7 Notification Interface

  • Direction: Wallet to Issuer
  • Method: POST or as defined by metadata/profile

If the deployment supports issuance notifications and the Issuer provides a notification_id, the Wallet SHOULD send one or more Notification Requests for that notification_id using the mechanism defined by the applicable profile or Issuer metadata.

8.8 Deferred Credential Endpoint

  • Direction: Wallet to Issuer
  • Method: POST

Request (logical fields)

  • authorisation information or deferred token
  • transaction identifier, where applicable

Response

  • issued credential(s), or
  • pending status with retry guidance, or
  • terminal failure

8.9 Metadata Endpoints

Issuers SHALL publish:

Metadata SHALL provide enough information for a conforming Wallet to discover and use:

  • authorisation endpoint;
  • token endpoint;
  • PAR endpoint;
  • credential endpoint;
  • deferred credential endpoint, where applicable;
  • supported credential configurations;
  • supported proof types and formats.

Where this RFC is used as an ETSI TS 119 472-3 aligned issuance profile, the metadata set SHALL additionally provide:

  • signed Issuer Metadata with the Issuer access certificate transported in the JWS protected header x5c; and
  • the issuer_info metadata parameter carrying issuer registration material, including the registration certificate and registrar dataset, as profiled by ETSI.

9 Conformance

An implementation conforms to this specification as a Wallet if it:

  1. Implements the Wallet requirements in Sections 6 and 7
  2. Supports the Wallet-side interfaces and behaviours defined in Section 8
  3. Uses OpenID4VCI 1.0 and the APTITUDE issuance profile constraints defined in this RFC.

An implementation conforms to this specification as an Issuer if it:

  1. Implements the Issuer requirements in Sections 6 and 7
  2. Publishes the required metadata.
  3. Provides the issuance interfaces defined in Section 8
  4. Applies the APTITUDE issuance baseline consistently across supported credential configurations.

Pilot-specific profiles MAY define additional constraints for specific credential types or domains. Such profiles SHALL NOT relax the mandatory requirements in this document.

9.1 Scope of the Conformance Matrix

This conformance matrix verifies baseline protocol interoperability between an Issuer or Wallet Unit under test and the reference issuance endpoints defined by this APTITUDE Issuance Profile. It is intended to confirm correct support for representative OpenID4VCI v1.0 issuance flows covered by this RFC, including wallet-initiated and issuer-initiated issuance.

The matrix is a protocol interoperability matrix, not a complete ARF/CIR compliance assessment. It focuses on issuance flow processing, Credential Offer handling, PAR-based authorisation, token acquisition, proof-bound credential requests, deferred issuance handling, and metadata-driven endpoint use within the scope of this profile.

It does not exhaustively test broader trust, governance, semantic, privacy, supervisory, or deployment-specific obligations. Where ARF or CIR references are included, they provide traceability and alignment for the issuance interoperability capability being exercised, rather than full normative coverage of the broader requirement domain. This is consistent with the RFC’s explicitly horizontal, cross-pilot scope and its stated out-of-scope exclusions.

10 Conformance Check Catalogue and Deployed Test Matrix

10.1 Conformance Check Catalogue

Check ID Conformance Check What Is Verified At Runtime ARF / CIR Linkage
VCI-CHECK-01 Credential offer resolution and processing The wallet resolves the credential offer or offer URI and processes the issuance entrypoint without transport or parsing failure. CIR credential offer interface; ARF issuer-initiated and wallet-initiated issuance baseline
VCI-CHECK-02 Authorization-code flow handling The wallet completes the authorization-code flow through authorization, code reception, and token redemption. ARF wallet-initiated issuance flow; CIR authorization-code issuance
VCI-CHECK-03 PKCE enforcement Token redemption requires the correct PKCE verifier for authorization-code issuance. CIR token endpoint security; ARF authorization security baseline
VCI-CHECK-03A Wallet Instance Attestation handling For authorization-code issuance where the profile requires wallet attestation, the wallet sends WIA at the PAR and Token endpoints, proves possession of the key referenced in the WIA cnf claim, and the issuer validates those inputs. ETSI-aligned PAR and token endpoint attestation handling; ARF wallet attestation baseline
VCI-CHECK-04 Pre-authorized code validation Token exchange rejects unknown or expired pre-authorized codes and correctly handles pre-authorized issuance state. CIR token endpoint behavior; ARF issuer-initiated issuance baseline
VCI-CHECK-05 Proof container and selector validation Credential requests use the correct selector model, reject legacy proof, require proofs, and enforce exactly one proof type. CIR credential endpoint and proof request shape; ARF proof-of-possession baseline
VCI-CHECK-06 Holder proof validation The issuer validates proof signature, proof key resolution, aud, freshness, nonce, and where applicable iss. CIR proof validation requirements; ARF proof binding and replay protection
VCI-CHECK-06A Wallet Unit Attestation handling The credential request carries WUA in the correct location for the selected proof method, the issuer validates the WUA, and the issued credential is bound according to the attested key material. ETSI-aligned credential endpoint attestation handling; ARF key-attestation and holder-binding baseline
VCI-CHECK-07 Signature-profile interoperability The issuance flow interoperates with the issuer signature reference/profile variant configured for the deployed case. ARF interoperability across supported signing models; CIR credential format and metadata support
VCI-CHECK-08 mdoc-specific proof handling mdoc issuance requires the mdoc-appropriate proof path and rejects JWT proof for mso_mdoc requests. ARF credential-format interoperability; CIR credential format support
VCI-CHECK-09 tx-code offer-step handling The wallet can process issuance flows that advertise a tx-code step, even where server-side tx-code enforcement is partial. CIR credential offer and token interaction behavior; ARF issuer-initiated issuance support
VCI-CHECK-10 A128GCM algorithm support A deployed issuance flow succeeds when the relevant encrypted object in the profiled exchange is produced and consumed using enc=A128GCM. ETSI TS 119 472-3 aligned cryptographic algorithm support; HAIP-compatible encrypted exchange handling
VCI-CHECK-11 A256GCM algorithm support A deployed issuance flow succeeds when the relevant encrypted object in the profiled exchange is produced and consumed using enc=A256GCM. ETSI TS 119 472-3 aligned cryptographic algorithm support; HAIP-compatible encrypted exchange handling

10.2 Deployed Test Case Matrix

Test Case ID Deployed Scenario Request Profile / Variant Checks Covered Expected Outcome
VCI-001 Authorization-code flow, SD-JWT, JWK signature PID SD-JWT issuance with JWK-based issuer signature selection VCI-CHECK-01, VCI-CHECK-02, VCI-CHECK-03, VCI-CHECK-03A, VCI-CHECK-05, VCI-CHECK-06, VCI-CHECK-06A, VCI-CHECK-07 Successful end-to-end authorization-code issuance for the JWK-signature SD-JWT case
VCI-002 Authorization-code flow, SD-JWT, KID-JWK signature PID SD-JWT issuance with KID-JWK issuer signature selection VCI-CHECK-01, VCI-CHECK-02, VCI-CHECK-03, VCI-CHECK-03A, VCI-CHECK-05, VCI-CHECK-06, VCI-CHECK-06A, VCI-CHECK-07 Successful end-to-end authorization-code issuance for the KID-JWK-signature SD-JWT case
VCI-004 Authorization-code flow, SD-JWT, DID:web signature PID SD-JWT issuance with DID:web issuer signature selection VCI-CHECK-01, VCI-CHECK-02, VCI-CHECK-03, VCI-CHECK-03A, VCI-CHECK-05, VCI-CHECK-06, VCI-CHECK-06A, VCI-CHECK-07 Successful end-to-end authorization-code issuance for the DID:web-signature SD-JWT case
VCI-005 Authorization-code flow, mdoc, X.509 mdoc issuance with X.509 signature profile VCI-CHECK-01, VCI-CHECK-02, VCI-CHECK-03, VCI-CHECK-03A, VCI-CHECK-05, VCI-CHECK-06, VCI-CHECK-06A, VCI-CHECK-07, VCI-CHECK-08 Successful end-to-end authorization-code issuance for the mdoc X.509 case, or explicit rejection of the wrong proof type
VCI-006 Pre-authorized code flow, SD-JWT, X.509 PID SD-JWT issuance with X.509 signature profile and no tx-code step VCI-CHECK-01, VCI-CHECK-04, VCI-CHECK-05, VCI-CHECK-06, VCI-CHECK-06A, VCI-CHECK-07 Successful pre-authorized issuance for the SD-JWT X.509 case
VCI-007 Pre-authorized code flow with tx-code metadata, SD-JWT, X.509 PID SD-JWT issuance with X.509 signature profile and tx-code metadata VCI-CHECK-01, VCI-CHECK-04, VCI-CHECK-05, VCI-CHECK-06, VCI-CHECK-06A, VCI-CHECK-07, VCI-CHECK-09 Successful pre-authorized issuance for the tx-code SD-JWT X.509 case
VCI-008 Pre-authorized code flow, mdoc, X.509 mdoc issuance with X.509 signature profile and no tx-code step VCI-CHECK-01, VCI-CHECK-04, VCI-CHECK-05, VCI-CHECK-06, VCI-CHECK-06A, VCI-CHECK-07, VCI-CHECK-08 Successful pre-authorized issuance for the mdoc X.509 case, or explicit rejection of the wrong proof type
VCI-009 Authorization-code flow, SD-JWT, A128GCM PID SD-JWT issuance where the relevant encrypted exchange uses enc=A128GCM VCI-CHECK-01, VCI-CHECK-02, VCI-CHECK-03, VCI-CHECK-03A, VCI-CHECK-05, VCI-CHECK-06, VCI-CHECK-06A, VCI-CHECK-07, VCI-CHECK-10 Successful end-to-end authorization-code issuance when the profiled encrypted exchange uses A128GCM
VCI-010 Authorization-code flow, SD-JWT, A256GCM PID SD-JWT issuance where the relevant encrypted exchange uses enc=A256GCM VCI-CHECK-01, VCI-CHECK-02, VCI-CHECK-03, VCI-CHECK-03A, VCI-CHECK-05, VCI-CHECK-06, VCI-CHECK-06A, VCI-CHECK-07, VCI-CHECK-11 Successful end-to-end authorization-code issuance when the profiled encrypted exchange uses A256GCM

References

  1. OpenID Foundation. OpenID for Verifiable Credential Issuance 1.0.
  2. OpenID Foundation. OpenID4VC High Assurance Interoperability Profile 1.0.
  3. OpenID Foundation. OpenID for Verifiable Presentations 1.0.
  4. APTITUDE project architecture, interoperability, and ITB+ artefacts (to be referenced by the project).
  5. ETSI TS 119 472-3 V1.1.1 (2026-03), Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 3: Profiles for issuance of EAA or PID, https://www.etsi.org/deliver/etsi_ts/119400_119499/11947203/01.01.01_60/ts_11947203v010101p.pdf