APTITUDE RFC-02 Presentation Profile¶

Status: Draft
Type: Cross-pilot baseline RFC
Scope: Credential Presentation / Verification
Target protocols: OpenID4VP v1.0
Related profiles: HAIP (where applicable)
Companion RFC: RFC-01 Issuance Profile

Authors¶

Nikos Triantafyllou, University of the Aegean

Reviewers¶

Degani Giancarlo, Infocert
Andreea Prian, IDAKTO
Leonardo Pio Palumbo, ipzs
Leone Riello, Infocert
George Fourtounis, GRNET

1. Introduction¶

This document defines the APTITUDE Presentation Profile for interoperable credential verification across APTITUDE pilots.

It specifies a baseline, cross-pilot profile for presentation and verification of verifiable credentials, aligned with the Architecture and Reference Framework (ARF), and based on OpenID for Verifiable Presentations (OpenID4VP) v1.0. Where applicable, the profile incorporates relevant choices from the OpenID4VC High Assurance Interoperability Profile (HAIP).

The purpose of this RFC is to establish a stable starting point for interoperability across APTITUDE pilots by defining:

common presentation and verification requirements
roles and interfaces between wallets and verifiers
baseline security and privacy expectations
support for same-device and cross-device presentation patterns
a requirements baseline that can be mapped into corresponding ITB+ conformance test cases

This RFC is intended to support interoperability first. Pilot-specific or sector-specific extensions may be added later, but they should not weaken the baseline requirements defined here.

2. Scope¶

This RFC defines the conformance profile for credential presentation and verification in APTITUDE.

It covers requirements for:

Wallet Units / Wallets acting on behalf of the Holder
Verifiers / Relying Parties initiating presentation requests and validating responses

This profile defines a baseline for presentation interoperability using OpenID4VP v1.0.

This RFC profiles presentation under two normative tracks:

SD-JWT VC track — profiled under the generic APTITUDE OpenID4VP presentation mode, including selective-disclosure presentation patterns supported by the selected credential profile
ISO/IEC 18013-7 remote mdoc track — profiled separately under an ISO/IEC TS 18013-7-aligned mode for remote presentation of mso_mdoc credentials; remote presentation of mso_mdoc credentials SHALL conform to ISO/IEC TS 18013-7 Annex B and the corresponding OpenID4VP mdoc processing rules used to carry the ISO DeviceResponse

This RFC includes baseline requirements for:

construction and processing of presentation requests
Wallet invocation for same-device and cross-device presentation flows
presentation response submission and verifier-side validation
holder consent and release of requested data
baseline privacy and security requirements for request/response handling

For the ETSI-aligned presentation flows in scope for this RFC, the following stricter requirements apply:

signed Request Objects
structured Verifier identification
request integrity and audience binding
support for ETSI-aligned authorization-endpoint invocation using the eu-eaap:// scheme where that invocation method is applied by the deployment profile
encrypted presentation responses
profile-specific request metadata and proof-binding requirements

For the ISO/IEC 18013-7 remote mdoc track, the following additional requirements apply:

format-specific wallet invocation using the mdoc-openid4vp:// scheme
mso_mdoc request construction with document type, namespace, and element identifiers
vp_token carrying the base64url-encoded ISO DeviceResponse CBOR structure
SessionTranscript and handover construction binding the response to the originating request
verifier-side validation of the returned mdoc presentation object against the reconstructed session context

This RFC does not define:

sector-specific credential semantics
trust framework governance rules or verifier registration schemes at baseline RFC level
mandatory verifier trust anchors or trusted-list processing rules at baseline RFC level
full protocol profiling of ISO/IEC 18013-5 proximity device retrieval and reader authentication requirements
JSON-LD W3C VC presentation requirements
pilot-specific UI requirements
detailed test assertions; these are derived into the ITB+ test suite from the requirements matrix in this document

Where this RFC defines structural elements that may also be used by a trust framework or verifier registration ecosystem, those definitions are included only to support interoperability of the protocol exchange and do not by themselves establish trust, registration, or legal reliance.

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 RFC uses the following roles:

4.1 Holder¶

The Holder, as defined in the APTITUDE glossary and aligned with the ARF notion of (Wallet) User, is the natural person or legal representative controlling the Wallet and authorising the presentation of credentials.

4.2 Wallet Unit / Wallet¶

The Wallet Unit is the Wallet Unit as defined in the ARF and APTITUDE glossary, including one or more Wallet Instances on the Holder’s device or environment. In this RFC, the term Wallet refers to the Wallet Unit (and its Wallet Instances) when the distinction is not material, acting on behalf of the Holder to manage credentials and respond to presentation requests.

4.3 Verifier¶

The Verifier, as defined in the APTITUDE glossary and aligned with the ARF notion of (Wallet-) Relying Party, is the entity requesting verifiable presentations, validating the response, and making an authorisation or business decision based on the outcome.

4.4 Verifier Backend¶

The Verifier Backend, as defined in the APTITUDE glossary, is the server-side component that creates presentation requests, receives presentation responses, validates them, and returns the result to the relying application.

4.5 Relying Application¶

The Relying Application, as defined in the APTITUDE glossary, is the user-facing application, service, or workflow in which credential verification is performed.

5. Protocol Overview¶

The APTITUDE Presentation Profile is based on OpenID4VP v1.0 as the baseline presentation protocol for requesting and submitting credential presentations.

This RFC profiles two credential presentation tracks:

SD-JWT VC track — presentation using the generic APTITUDE OpenID4VP mode with ETSI-aligned request and response constraints
ISO/IEC 18013-7 remote mdoc track — presentation of mso_mdoc credentials using an ISO/IEC TS 18013-7-aligned OpenID4VP mdoc mode with dedicated request construction, session binding, response structure, and verifier validation rules

This RFC defines a baseline APTITUDE presentation mode for the non-API-mediated presentation flows in scope for APTITUDE and applies the relevant ETSI TS 119 472-2 / OpenID4VC-HAIP-aligned request and response constraints as mandatory requirements for the SD-JWT VC track. For the mdoc track, the RFC defines a separate ISO/IEC TS 18013-7-aligned presentation mode with format-specific normative requirements.

5.1 Baseline APTITUDE presentation mode¶

In the baseline mode:

the Verifier creates a Presentation Request using OpenID4VP-compatible request parameters
the Wallet is invoked using an interoperable same-device or cross-device mechanism supported by the deployment context
the Wallet validates the request before showing it to the Holder
the Holder reviews the request and explicitly approves release
the Wallet generates a presentation response using the selected credential format
the Wallet submits the response using the response mechanism defined by the request
the Verifier validates the response and returns the outcome to the relying application

The baseline mode requires interoperability at protocol level, but does not require a specific verifier trust framework, verifier registration system, or mandatory trusted-list processing model at RFC level. Structural request elements may still be used where supported, but their presence alone does not establish trust, legal reliance, or registration status.

5.2 ETSI-aligned mandatory requirements¶

For the presentation flows in scope for this RFC, the presentation exchange SHALL apply stricter ETSI-aligned constraints for request integrity, verifier identification, response protection, and proof binding.

The following ETSI-aligned constraints are mandatory:

use signed Request Objects
use client_id with the Client Identifier Prefix x509_hash
include structured verifier identification
include client_metadata and related verifier key material
include verifier_info with RP-registrar/registry-related verifier information
apply audience restriction using aud and enforce nonce correlation
use encrypted authorization or presentation responses
apply profile-specific proof-binding requirements for the selected credential format

In this RFC, these ETSI-aligned structures are included to support interoperability of the protocol exchange. However, the RFC does not define the governance, issuance, validation, or legal effect of verifier registration certificates, trust anchors, or trusted status lists.

5.3 Supported presentation patterns¶

This RFC supports non-API-mediated presentation patterns:

same-device presentation, where the Wallet is invoked on the same device as the relying application; and
cross-device presentation, where the request is transferred across devices, typically using QR-based or link-based handoff

For the SD-JWT VC track, APTITUDE requires support for interoperable invocation methods suitable for same-device and cross-device non-API-mediated use.

For the ISO/IEC 18013-7 remote mdoc track, same-device remote presentation is the ISO-aligned mode. Cross-device mdoc presentation is not defined under the ISO/IEC 18013-7-aligned profile in this RFC. If APTITUDE requires cross-device mdoc presentation in future, it SHALL be described as a separate profile claim and SHALL NOT be presented as ISO/IEC 18013-7 alignment.

API-mediated presentation flows are currently out of scope for this RFC. Future revisions may include API-mediated flows (for example, DC API) where required by agreed use cases.

5.4 High-level presentation sequence¶

At a high level, the presentation process is:

The Verifier creates a Presentation Request.
The Wallet is invoked through a supported method.
The Wallet validates the request.
The Holder reviews the request and provides consent.
The Wallet generates a presentation response.
The Wallet submits the presentation response to the Verifier.
The Verifier validates the response and returns the outcome.

5.5 Relation to ETSI-aligned presentation profiling¶

ETSI TS 119 472-2 separates:

an ISO/IEC-mdoc profile (clause 5) for proximity-based non-API-mediated device retrieval built on ISO/IEC 18013-5, and
an OpenID4VC-HAIP-based profile (clause 6) for API-mediated and non-API-mediated transmission.

Within the ETSI OpenID4VC-HAIP profile, non-API-mediated transmission is profiled primarily for SD-JWT VC. ISO mdoc presentation over the HAIP profile is profiled by ETSI only via the API-mediated (DC API) mechanism. Non-API-mediated remote mdoc presentation using redirect-based OpenID4VP is defined by ISO/IEC TS 18013-7, not by ETSI TS 119 472-2 or OpenID4VC-HAIP.

This RFC addresses this gap by defining two tracks:

SD-JWT VC track: applies the ETSI-aligned OpenID4VC-HAIP request and response constraints for non-API-mediated presentation as defined by this RFC.
ISO/IEC 18013-7 remote mdoc track: defines a dedicated ISO/IEC TS 18013-7-aligned presentation mode for remote mso_mdoc presentation with format-specific invocation, request, session binding, response, and validation rules. ETSI-aligned request-object and response-protection requirements are additionally applied to the extent compatible with the ISO/IEC 18013-7-aligned flow.

This RFC does not reproduce the ETSI clause 5 ISO/IEC-mdoc proximity profile, since full ISO/IEC 18013-5 proximity device retrieval profiling is out of scope here. This RFC also currently specifies only non-API-mediated presentation mechanisms. API-mediated mechanisms are not specified in this version and may be added in future revisions if required by use cases. For clarity, ETSI clause 5 proximity presentation uses the RequestInfo parameter to transport verifier registration certificate material or registrar information to the Wallet. This RFC acknowledges that ETSI mechanism, but does not normatively profile RequestInfo processing in this version because the full ISO/IEC 18013-5 proximity flow is out of scope.

5.6 ISO/IEC 18013-7 remote mdoc profile¶

This RFC defines an ISO/IEC TS 18013-7-aligned profile for remote presentation of mso_mdoc credentials over OpenID4VP.

Accuracy note on protocol lineage. This RFC uses OpenID4VP v1.0 as the baseline presentation protocol. For remote mso_mdoc presentation, however, ISO/IEC TS 18013-7 Annex B was defined against an earlier OpenID4VP draft lineage. Accordingly, the ISO/IEC 18013-7 remote mdoc track in this RFC SHALL be understood as an ISO-aligned compatibility profile implemented using the mdoc-specific OpenID4VP processing rules preserved in later drafts and OpenID4VP v1.0, rather than as a claim that ISO/IEC TS 18013-7 itself was authored against the final OpenID4VP v1.0 specification.

Under this profile:

the Wallet is invoked using the mdoc-openid4vp:// scheme for same-device remote presentation
the Presentation Request uses format = mso_mdoc and identifies the requested document type, namespaces, and data elements compatible with ISO mdoc processing
the Presentation Request is obtained using request_uri
the Presentation Request includes the nonce and verifier identity inputs needed to construct the ISO-linked SessionTranscript
the Wallet constructs the SessionTranscript using the OpenID4VP-to-ISO handover mapping defined for remote mdoc presentation
the vp_token carries the base64url-encoded ISO DeviceResponse CBOR structure
the Wallet binds the returned DeviceResponse to the originating request through the SessionTranscript
the Verifier reconstructs and validates the same SessionTranscript inputs when validating the returned mdoc presentation
the Verifier performs ISO-bound validation of the DeviceResponse, including document type match, namespace and element consistency, nonce and handover consistency, and cryptographic validation against the reconstructed session context
encrypted response protection is applied using an encrypted response mode supported by the selected OpenID4VP mdoc profile

This profile is distinct from the generic APTITUDE OpenID4VP baseline used for SD-JWT VC. Implementations claiming ISO/IEC 18013-7 alignment for remote mdoc presentation SHALL conform to the requirements defined under this track.

6. High-Level Flows¶

6.1 Same-Device Presentation Flow¶

6.1.1 Presentation Request Creation¶

The Verifier prepares a Presentation Request containing the information needed by the Wallet to determine what credentials and claims are requested, along with the parameters needed to produce a valid response.

The request SHOULD include, as applicable:

verifier identifier
nonce
audience or equivalent recipient binding
requested credential types or claims
disclosure constraints
response endpoint information
validity and expiry parameters

Where the selected profile requires signed requests, the Presentation Request SHALL be integrity protected.

6.1.2 Wallet Invocation¶

For the SD-JWT VC track, the Wallet is invoked using a supported same-device method, such as:

an app-to-app link
a deep link
a platform-supported wallet invocation mechanism
another interoperable wallet invocation approach supported by the ecosystem

Where an ETSI-aligned same-device authorization endpoint is used by the applying profile, Wallets and Verifiers SHOULD support invocation through the eu-eaap:// scheme.

For the ISO/IEC 18013-7 remote mdoc track, same-device wallet invocation SHALL use the mdoc-openid4vp:// scheme as required by the ISO-aligned profile defined in Section 5.6.

6.1.3 Wallet Validation¶

The Wallet SHALL validate the received Presentation Request before presenting it to the Holder.

Validation SHOULD include, as applicable:

request syntax and completeness
signature or integrity protection, where present or required
nonce presence and freshness
audience or recipient binding
expiry validity
supported credential query semantics
compatibility with the Wallet’s supported credential formats

Invalid or malformed requests SHALL be rejected.

The Wallet SHALL present the request information to the Holder in a transparent way.

The Wallet SHOULD display, where applicable:

the Verifier identity
the purpose or context of the request
the requested credential(s)
the requested claims or attributes
selective disclosure details, where supported

The Holder SHALL explicitly approve the release before a presentation is generated.

6.1.5 Presentation Generation¶

After consent, the Wallet generates the presentation response in accordance with OpenID4VP and the credential format in use.

For the SD-JWT VC track, this MAY include:

a vp_token
one or more verifiable presentations or credential-derived proofs
disclosures, where selective disclosure is supported
holder-binding or proof-of-possession material, where required
nonce and audience binding data

For the ISO/IEC 18013-7 remote mdoc track, the Wallet SHALL:

construct the SessionTranscript using the OpenID4VP-to-ISO handover mapping defined for remote mdoc presentation
generate an ISO DeviceResponse CBOR structure bound to the originating request through the SessionTranscript
encode the DeviceResponse as a base64url string and place it in the vp_token

6.1.6 Presentation Submission¶

The Wallet submits the presentation response to the Verifier using the response mechanism defined by the request and supported by the protocol.

Submission MAY be direct from the Wallet to the Verifier backend or may involve an intermediate browser or platform handoff, depending on the flow.

6.1.7 Result Handling¶

The Verifier validates the response and returns an outcome.

The outcome SHOULD clearly indicate:

successful verification
verification failure
user cancellation
unsupported request or unsupported credential format
expired or invalid request
other protocol or validation errors

The Wallet and/or relying application SHOULD display an understandable outcome to the Holder.

6.2 Cross-Device Presentation Flow (Non-API-mediated)¶

Cross-device presentation as defined in this section applies to the SD-JWT VC track. The ISO/IEC 18013-7 remote mdoc track does not define cross-device presentation under this RFC. If cross-device mdoc presentation is required in future, it SHALL be described as a separate profile claim.

6.2.1 Presentation Request Creation and Display¶

The Verifier creates the Presentation Request and makes it available through a non-API-mediated cross-device transfer mechanism, typically by encoding reference data or invocation data in a QR code or equivalent.

6.2.2 Wallet Invocation via QR, Link, or Equivalent¶

The Holder uses a second device to invoke the Wallet and retrieve the Presentation Request.

APTITUDE requires support for cross-device presentation through non-API-mediated interoperable means such as:

QR-based transfer
link-based transfer
other supported wallet invocation methods

This section does not define API-mediated cross-device presentation. API-mediated approaches (for example, DC API-based flows) may be specified in future RFC revisions where required by agreed use cases.

6.2.3 Wallet Validation¶

The same validation rules as in Section 6.1.3 apply.

The same holder consent requirements as in Section 6.1.4 apply.

6.2.5 Presentation Generation¶

The same presentation generation requirements as in Section 6.1.5 apply.

6.2.6 Presentation Submission¶

The Wallet submits the presentation response to the Verifier using the mechanism defined by the request and supported by the verifier.

6.2.7 Result Handling¶

The Verifier validates the presentation and returns the outcome to the relying application and/or Wallet, as appropriate for the flow.

7. Normative Requirements¶

7.1 Wallet Requirements¶

A Wallet conforming to this RFC SHALL:

APT-PRES-WALLET-01
Support OpenID4VP v1.0 for credential presentation.

APT-PRES-WALLET-02
Support same-device presentation flows for the non-API-mediated mechanisms specified by this RFC.

APT-PRES-WALLET-03
Support cross-device presentation flows for the non-API-mediated mechanisms specified by this RFC.

APT-PRES-WALLET-04
Support invocation through interoperable methods suitable for the deployment context, including QR and/or link-based invocation where applicable.

For ETSI-aligned same-device presentation flows that use authorization-endpoint based invocation, a Wallet SHOULD support the eu-eaap:// scheme.

APT-PRES-WALLET-05
Validate the Presentation Request before presenting it to the Holder.

APT-PRES-WALLET-06
Reject malformed, expired, or otherwise invalid Presentation Requests.

APT-PRES-WALLET-07
Present the requested credential and claim release information to the Holder in a transparent way.

APT-PRES-WALLET-08
Require explicit Holder consent before releasing data.

APT-PRES-WALLET-09
Generate a presentation response conforming to OpenID4VP and the relevant credential format in use.

APT-PRES-WALLET-10
Bind the response to the request parameters, including nonce and audience or equivalent recipient binding, where required by the selected profile or format.

APT-PRES-WALLET-11
Submit the presentation response to the Verifier endpoint indicated by the request or profile.

APT-PRES-WALLET-12
Support selective disclosure where the credential format in use supports it.

A Wallet conforming to this RFC SHALL NOT:

APT-PRES-WALLET-13
Accept invalid or unsupported requests without clear error handling.

APT-PRES-WALLET-14
Release claims not requested by the Verifier, unless explicitly authorised by the Holder and permitted by the applicable profile.

APT-PRES-WALLET-15
Perform silent or automatic consent for requests that require user approval.

A Wallet claiming conformance to the ISO/IEC 18013-7 remote mdoc track SHALL additionally:

APT-PRES-WALLET-MDOC-01
Support wallet invocation using the mdoc-openid4vp:// scheme for same-device remote mdoc presentation.

APT-PRES-WALLET-MDOC-02
Support retrieval of the Presentation Request using the request_uri parameter for the ISO-aligned remote mdoc flow.

APT-PRES-WALLET-MDOC-03
Construct the SessionTranscript using the OpenID4VP-to-ISO handover mapping defined for remote mdoc presentation.

APT-PRES-WALLET-MDOC-04
Generate an ISO DeviceResponse CBOR structure in response to a valid mso_mdoc Presentation Request.

APT-PRES-WALLET-MDOC-05
Bind the returned DeviceResponse to the originating request through the SessionTranscript.

APT-PRES-WALLET-MDOC-06
Encode the DeviceResponse as a base64url string and place it in the vp_token.

APT-PRES-WALLET-MDOC-07
Encrypt the presentation response using an encrypted response mode supported by the selected OpenID4VP mdoc profile.

7.2 Verifier Requirements¶

A Verifier conforming to this RFC SHALL:

APT-PRES-VER-01
Support OpenID4VP v1.0 for credential presentation requests and responses.

APT-PRES-VER-02
Support same-device presentation flows for the non-API-mediated mechanisms specified by this RFC.

APT-PRES-VER-03
Support cross-device presentation flows for the non-API-mediated mechanisms specified by this RFC.

APT-PRES-VER-04
Create a Presentation Request containing the parameters necessary for the Wallet to process the request.

APT-PRES-VER-05
Use a nonce or equivalent anti-replay mechanism.

APT-PRES-VER-06
Use audience or recipient binding where required by the selected profile.

APT-PRES-VER-07
Provide a response endpoint or equivalent response handling mechanism.

APT-PRES-VER-08
Validate all received presentation responses before relying on them.

APT-PRES-VER-09
Validate, as applicable:

request-response correlation
nonce binding
audience binding
proof integrity
credential or presentation authenticity
disclosure integrity
holder binding, where required
satisfaction of the requested constraints

APT-PRES-VER-10
Return a clear outcome indicating success or failure.

APT-PRES-VER-11
Request only data necessary for the intended purpose.

APT-PRES-VER-12
Support interoperable invocation methods for both same-device and cross-device non-API-mediated presentation.

For ETSI-aligned same-device presentation flows that use authorization-endpoint based invocation, a Verifier SHOULD support the eu-eaap:// scheme.

A Verifier conforming to this RFC SHALL additionally apply the ETSI-aligned request requirements for the flows in scope:

APT-PRES-VER-13
Use signed request objects.

APT-PRES-VER-14
Include and publish structured verifier metadata required by the applying profile, including verifier_info, RP-registrar/registry-related data, and client_metadata verifier key material.

A Verifier claiming conformance to the ISO/IEC 18013-7 remote mdoc track SHALL additionally:

APT-PRES-VER-MDOC-01
Construct the Presentation Request using format = mso_mdoc and identify the requested document type.

APT-PRES-VER-MDOC-02
Identify requested data elements using namespace and element identifiers compatible with ISO mdoc processing.

APT-PRES-VER-MDOC-03
Make the Presentation Request available using the request_uri parameter for the ISO-aligned remote mdoc flow.

APT-PRES-VER-MDOC-04
Include in the request the nonce and verifier identity inputs needed to construct the ISO-linked SessionTranscript.

APT-PRES-VER-MDOC-05
Provide the parameters needed for the Wallet to encrypt the response under the selected OpenID4VP mdoc profile.

APT-PRES-VER-MDOC-06
Validate the received DeviceResponse presence and format.

APT-PRES-VER-MDOC-07
Validate document type match between the request and the returned DeviceResponse.

APT-PRES-VER-MDOC-08
Validate namespace and requested element consistency between the request and the returned data.

APT-PRES-VER-MDOC-09
Validate request-response correlation, including nonce and handover consistency.

APT-PRES-VER-MDOC-10
Reconstruct the SessionTranscript and validate the cryptographic binding of the returned mdoc presentation object against the reconstructed session context.

A Verifier conforming to this RFC SHALL NOT:

APT-PRES-VER-15
Disable nonce validation where nonce usage is required.

APT-PRES-VER-16
Request unnecessary personal data beyond the needs of the use case.

8. Interface Definitions¶

8.1 Wallet Invocation Interface¶

Direction: Verifier → Wallet
Purpose: Invoke a Wallet for presentation

For the SD-JWT VC track, APTITUDE does not mandate a single invocation mechanism across all pilots. Implementations SHALL support interoperable invocation methods appropriate to the use case and deployment context.

Supported invocation methods for the SD-JWT VC track MAY include:

QR codes
HTTPS links
deep links
custom URI schemes
platform wallet invocation methods

Where a custom URI scheme is used, it SHOULD be documented by the implementation profile applying this RFC. For ETSI-aligned authorization-endpoint invocation, implementations SHOULD support the eu-eaap:// scheme where that scheme is used by the applying profile.

For the ISO/IEC 18013-7 remote mdoc track, wallet invocation SHALL use the mdoc-openid4vp:// scheme when the requested credential format is mso_mdoc under the ISO-aligned profile. The generic invocation methods listed above are not sufficient as the sole rule for ISO remote mdoc presentation.

8.2 Presentation Request Interface¶

The Presentation Request SHALL contain sufficient information for the Wallet to:

identify the Verifier
understand what credential(s) or claim(s) are being requested
determine where and how to submit the response
bind the response to the request
determine whether the request is still valid

At baseline RFC level, the Presentation Request SHALL include, as applicable to the selected OpenID4VP flow and credential format:

client_id or equivalent verifier identifier
nonce
aud, where audience restriction is required by the selected profile
response endpoint information or equivalent response handling information
credential query parameters
proof or proof-binding requirements, where required by the selected profile or format
expiry or equivalent request validity constraints
integrity protection, where required by the selected profile

Where a signed Request Object is used, the Request Object SHOULD contain all parameters necessary for the Wallet to process the request in a self-contained and integrity-protected manner.

Within the ETSI-aligned scope of this RFC, client_id SHALL use the Client Identifier Prefix x509_hash.

For the non-API-mediated ETSI-aligned presentation flows in scope for this RFC, the Authorization Request SHALL contain the request_uri parameter and therefore SHALL NOT carry the Request Object by value.

8.2.1 Baseline structural requirements¶

A Presentation Request conforming to this RFC SHOULD be structured so that the Wallet can obtain, either directly from the request or from referenced metadata:

a verifier identifier
a user-displayable verifier name or service description
the purpose of the request
the privacy-policy reference applicable to the request
the set of requested credential types, claims, or constraints
the response destination or response mode
replay-protection inputs such as nonce and request validity period

At baseline RFC level, these structural elements are included to support interoperability, request processing, and user transparency. Their presence does not by itself establish verifier registration status, legal reliance, or trustworthiness.

8.2.2 ETSI-aligned request-object requirements¶

The Presentation Request SHALL use a signed Request Object with structured verifier data.

The Request Object SHALL include:

client_id (using the Client Identifier Prefix x509_hash)
aud
nonce
client_metadata, including verifier key material
verifier_info
the credential request/query parameters
response-mode and response-destination parameters as required by the selected flow

verifier_info SHALL carry structured verifier information sufficient for the Wallet to present meaningful request context to the Holder. Such information SHALL include, where available:

verifier identifier
service description
RP-registrar registry or information-service URI
verifier registration certificate or equivalent registrar-issued verifier evidence
intended-use identifier
purpose information
privacy-policy URI
optionally, credential- or claim-related request context

For remote ETSI-aligned presentation flows, verifier_info SHALL be the container used to transport verifier registration certificate material or registrar information when such information is required by the applying profile.

If an ecosystem profile defines verifier registration certificates or equivalent verifier evidence, such evidence MAY be carried as an additional structured verifier-information element.

If client_metadata contains jwks, each key intended for request-object verification SHALL include kid and use values sufficient for the Wallet to identify the intended verifier signing key unambiguously.

This RFC does not define, at baseline level:

verifier registration governance
mandatory registrar APIs
registration-certificate validation rules
trusted-list processing rules
trust-anchor distribution mechanisms
legal meaning of verifier registration status

Those aspects MAY be defined by a future APTITUDE trust framework, by a sectoral deployment profile, or by an ecosystem profile applied together with this RFC.

8.2.3 Credential-format considerations¶

For SD-JWT VC requests, the Presentation Request SHOULD identify the requested credential type and requested disclosures or constraints in a way consistent with the selected OpenID4VP query mechanism and profile.

8.2.3.1 ISO/IEC 18013-7 remote mdoc request requirements¶

For the ISO/IEC 18013-7 remote mdoc track, the Presentation Request SHALL:

use format = mso_mdoc
identify the requested document type
identify requested data elements using namespace and element identifiers compatible with ISO mdoc processing
be obtained using request_uri for the ISO-aligned remote flow
include the nonce and verifier identity inputs needed to construct the ISO-linked SessionTranscript
include in verifier_info, where required by the applying profile, verifier registration certificate material or registrar information needed by the Wallet

The Presentation Request for remote mdoc presentation SHALL use the DCQL query mechanism with the ISO mdoc credential format specific parameters as defined by OpenID4VP.

8.2.4 Request validation expectations¶

The Wallet SHALL reject a Presentation Request that is malformed, expired, missing required anti-replay inputs, or otherwise inconsistent with the selected profile.

Where signed Request Objects are used, the Wallet SHALL validate the integrity of the Request Object before relying on its contents.

The Wallet SHALL validate the structured verifier information and verifier signing material according to the ETSI-aligned rules applied by this RFC.

8.2.5 ISO/IEC 18013-7 session binding¶

For the ISO/IEC 18013-7 remote mdoc track, this RFC defines the following normative session-binding requirements:

the Wallet SHALL construct the SessionTranscript using the OpenID4VP-to-ISO handover mapping defined for remote mdoc presentation
the Wallet SHALL bind the returned DeviceResponse to the originating request through the SessionTranscript
the Verifier SHALL reconstruct and validate the same SessionTranscript inputs when validating the returned mdoc presentation

The SessionTranscript provides the core ISO security binding for remote mdoc presentation. Without correct construction and validation of the SessionTranscript, the presentation cannot be considered bound to the originating request and the Verifier session context.

8.3 Presentation Response Interface¶

Direction: Wallet → Verifier
Method: As defined by the selected OpenID4VP flow and profile

The Presentation Response SHALL contain the payload, proof material, and correlation inputs required for the Verifier to:

associate the response with the originating request
determine which requested credential(s) or claim(s) are being returned
validate the authenticity and integrity of the presentation
validate replay-protection and recipient-binding inputs, where required
determine whether the response satisfies the request constraints

At baseline RFC level, the Presentation Response SHALL include the elements required by the selected OpenID4VP flow, response mode, and credential format.

Typical response elements MAY include:

vp_token
presentation_submission, where used by the selected profile
disclosures, where selective disclosure is supported by the selected credential format
proof-binding or holder-binding material, where required
state or equivalent transaction-correlation data
format-specific presentation payloads or derived proof structures

Where the selected flow or profile requires response correlation, the Wallet SHALL return the correlation values required for the Verifier to bind the response to the correct transaction context.

8.3.1 Baseline response requirements¶

At baseline RFC level, the Presentation Response SHOULD:

contain only the credential-derived data, disclosures, and proof material necessary to satisfy the request
preserve request-response correlation inputs such as nonce, state, audience binding, or equivalent recipient-binding data, where required by the selected profile
avoid returning additional claims or credentials beyond those approved by the Holder and required by the request
be transmitted using a secure response mechanism appropriate to the selected flow

If the selected credential format supports selective disclosure, the Wallet SHOULD include only the disclosures necessary to satisfy the approved request.

If the selected flow supports multiple response modes, the Wallet SHALL construct the response in the format required by the response mode indicated by the request.

8.3.2 ETSI-aligned response protection¶

The Presentation Response SHALL additionally apply stricter response-protection rules.

The following response-protection rules are mandatory:

encrypted authorization or presentation responses
strict audience restriction
strong transaction correlation
mandatory proof-binding requirements
profile-specific response serialization and submission rules

The Wallet SHALL encrypt the response.

For the ISO/IEC 18013-7 remote mdoc track, the following additional response-protection rules apply:

the ISO-aligned mdoc profile SHALL use an encrypted response mode supported by the selected OpenID4VP mdoc profile
the Verifier SHALL provide the parameters needed for the Wallet to protect the response accordingly
the encrypted response SHALL carry the DeviceResponse as defined in Section 8.3.3.1

This RFC does not define, at baseline level:

the mandatory response-encryption algorithms
mandatory response-encryption key-distribution rules
mandatory verifier certificate processing for response encryption
trust-framework-specific legal or supervisory effects of successful verifier authentication

Those aspects MAY be defined by a future APTITUDE trust framework, by a sectoral deployment profile, or by an ecosystem profile applied together with this RFC.

8.3.3 Credential-format considerations¶

For SD-JWT VC presentation, the response SHOULD contain the credential-derived presentation material and only the disclosures necessary to satisfy the approved request, together with any proof-binding material required by the selected profile.

8.3.3.1 ISO/IEC 18013-7 remote mdoc response requirements¶

For the ISO/IEC 18013-7 remote mdoc track, the vp_token SHALL carry the base64url-encoded ISO DeviceResponse CBOR structure.

The Verifier is not receiving arbitrary document-derived claims. It is receiving a signed or MACed ISO presentation object that SHALL be validated against the originating request context and the reconstructed SessionTranscript.

The Verifier SHALL validate:

DeviceResponse presence and format
document type match between the request and the returned DeviceResponse
namespace and requested element consistency
request-response correlation
nonce and handover consistency
cryptographic binding of the returned mdoc presentation object against the reconstructed session context

8.3.4 Error responses¶

Where the presentation fails or cannot be completed, the Wallet or response-handling component SHOULD return an error in a machine-readable form and, where appropriate, a human-readable description.

Error conditions MAY include:

invalid presentation
malformed response
user cancellation
expired request
unsupported credential format
missing required proof material
failed request-response correlation
failed verifier-side validation

Example (non-normative) conceptual success response:

{
  "vp_token": "<presentation-response>",
  "presentation_submission": "<submission-object>",
  "state": "<transaction-state>"
}

Example (non-normative) conceptual error response:

{
  "error": "invalid_presentation",
  "error_description": "Presentation validation failed"
}

8.4 Verifier Metadata Interface¶

The Verifier SHOULD publish metadata describing its capabilities and requirements where such metadata is used by the ETSI-aligned flow or by the selected deployment profile.

This MAY include:

supported presentation formats
supported credential query methods
supported proof mechanisms
verifier signing keys or trust anchors
supported response modes
endpoint information

9. Privacy and Security Considerations¶

Implementations conforming to this RFC SHOULD follow strong privacy and security practices consistent with OpenID4VP-based presentation flows and with the assurance requirements of the applying deployment profile.

This RFC defines a baseline interoperability profile. It includes structural requirements that support secure processing of presentation requests and responses, but it does not by itself define a complete verifier trust framework, verifier registration regime, or trusted-list governance model.

9.1 Data minimisation and disclosure control¶

Verifiers SHOULD request only the minimum data necessary for the stated purpose of the transaction.

Wallets SHOULD support selective disclosure where supported by the selected credential format and SHOULD release only the claims, attributes, or credential-derived data necessary to satisfy the approved request.

Implementations SHOULD avoid requesting, presenting, transmitting, or retaining data beyond what is necessary for the use case.

9.2 Request authenticity and integrity¶

Presentation Requests SHOULD be protected against tampering.

Where the selected profile or deployment mode uses signed Request Objects, the Wallet SHALL validate request integrity before relying on the request contents.

Wallets SHALL reject malformed, expired, or otherwise invalid requests and SHOULD reject requests that lack the anti-replay or correlation inputs required by the selected profile.

At baseline RFC level, structured verifier information and verifier metadata support request processing and user transparency, but do not by themselves establish verifier trustworthiness or legal registration status.

9.3 Replay protection and transaction binding¶

Nonces, expiry values, state parameters, audience restriction, and equivalent transaction-binding inputs SHOULD be used where required by the selected flow or credential format in order to reduce replay risk and response misbinding.

Wallets and Verifiers SHALL preserve the request-response correlation inputs required by the selected response mode and credential format.

Implementations SHOULD ensure that a presentation response cannot be successfully replayed in a different verifier session or redirected to an unintended relying context.

9.4 Response confidentiality and secure transport¶

Implementers SHALL ensure secure transport for presentation requests, metadata retrieval, response submission, and related endpoint communication.

Response endpoints SHOULD be protected against leakage, downgrade, redirection, and unauthorised access.

Encrypted presentation or authorization responses SHALL be used for the ETSI-aligned presentation flows in scope for this RFC.

This RFC does not define, at baseline level, mandatory response-encryption algorithms, key-distribution methods, or verifier-certificate processing rules for encrypted responses.

9.5 Verifier impersonation and phishing resistance¶

Wallets SHOULD present meaningful verifier information to the Holder wherever such information is available.

Cross-device invocation methods and same-device deep-link flows SHOULD minimise phishing, request substitution, and verifier impersonation risks.

Implementations SHOULD ensure that the Holder can distinguish the intended Verifier or service context before approving release.

Where verifier metadata, structured verifier information, or signed Request Objects are available, Wallets SHOULD use them to improve request authenticity checks and user transparency.

9.6 Credential-format considerations¶

For SD-JWT VC presentation, implementations SHOULD preserve the privacy properties of selective disclosure and SHOULD validate any required proof-binding or recipient-binding inputs defined by the selected profile.

For the ISO/IEC 18013-7 remote mdoc track, implementations SHALL:

protect the confidentiality and integrity of the returned DeviceResponse using the encrypted response mode defined by the ISO-aligned profile
construct and validate the SessionTranscript correctly, since the SessionTranscript provides the binding between the OpenID4VP request context and the ISO mdoc presentation object
validate the cryptographic integrity of the returned mdoc presentation object against the reconstructed SessionTranscript before relying on the returned data
ensure that the DeviceResponse cannot be replayed in a different verifier session or bound to a different request context

Implementations claiming ISO/IEC 18013-7 alignment SHALL NOT treat mdoc presentation as a loosely profiled OpenID4VP format. The ISO session-binding, DeviceResponse structure, and cryptographic validation requirements are normative and distinct from the generic SD-JWT VC response processing model.

9.7 Logging, retention, and local protection¶

Implementations SHOULD avoid logging sensitive presentation contents except where operationally necessary.

Where logs are required for security or troubleshooting purposes, implementations SHOULD minimise retained personal data and protect logs against unauthorised access.

Wallets, Verifiers, and related backend components SHOULD protect locally stored request, response, session, and metadata artefacts against unauthorised disclosure or modification.

9.8 Baseline RFC boundary¶

This RFC defines protocol-level privacy and security expectations for interoperable presentation processing.

It does not by itself define:

verifier trust framework governance
mandatory verifier registration procedures
trusted-list supervision rules
sector-specific legal reliance rules
mandatory incident-handling obligations
full deployment-security controls beyond the protocol boundary

Those aspects MAY be defined by a future APTITUDE trust framework, by a sectoral deployment profile, or by an ecosystem profile applied together with this RFC.

10. Conformance¶

This RFC defines conformance for interoperable credential presentation and verification in APTITUDE using OpenID4VP v1.0 across two normative tracks:

SD-JWT VC track conformance — baseline APTITUDE OpenID4VP presentation with ETSI-aligned request, verifier-identification, and response-protection requirements
ISO/IEC 18013-7 remote mdoc track conformance — ISO/IEC TS 18013-7-aligned presentation of mso_mdoc credentials with dedicated invocation, request, session binding, response, and validation requirements

An implementation MAY conform to one or both tracks. Conformance claims SHALL specify which track(s) the implementation supports.

This RFC does not require conformance to:

JSON-LD W3C VC presentation
a specific verifier trust framework
verifier registration governance
trusted-list supervision or trust-anchor governance
full ISO/IEC 18013-5 proximity device retrieval profiling
sector-specific legal or supervisory rules

Conformance to the SD-JWT VC track includes the ETSI-aligned request, verifier-identification, and response-protection requirements defined for the non-API-mediated presentation flows in scope. Conformance to the ISO/IEC 18013-7 remote mdoc track includes the ISO-specific invocation, request construction, session binding, DeviceResponse response structure, and verifier validation requirements defined by this RFC.

10.1 Wallet conformance¶

10.1.1 SD-JWT VC track wallet conformance¶

An implementation conforms to this RFC as a Wallet under the SD-JWT VC track if it:

satisfies all applicable Wallet requirements in Section 7.1 (APT-PRES-WALLET-01 through APT-PRES-WALLET-15)
implements the relevant interfaces in Section 8
supports OpenID4VP v1.0 presentation processing
supports the same-device and cross-device presentation flows required by this RFC
supports SD-JWT VC presentation
validates Presentation Requests before acting on them
binds presentation responses to the request context where required by the selected profile
submits presentation responses using the response mechanism defined by the request or applying profile

A Wallet conforming to the SD-JWT VC track SHALL conform to the stricter ETSI-aligned request, metadata, and response-protection rules defined by this document for the flows in scope.

10.1.2 ISO/IEC 18013-7 remote mdoc track wallet conformance¶

An implementation conforms to this RFC as a Wallet under the ISO/IEC 18013-7 remote mdoc track if it:

satisfies all applicable Wallet requirements in Section 7.1 (APT-PRES-WALLET-01 through APT-PRES-WALLET-15) as applicable to the mdoc flow
satisfies all ISO mdoc wallet requirements (APT-PRES-WALLET-MDOC-01 through APT-PRES-WALLET-MDOC-07)
implements the ISO-aligned interfaces in Section 8, including Section 8.2.3.1, Section 8.2.5, and Section 8.3.3.1
supports same-device remote mdoc presentation using the mdoc-openid4vp:// scheme
constructs the SessionTranscript correctly and binds the DeviceResponse to the originating request
generates a valid ISO DeviceResponse CBOR structure and encodes it as base64url in the vp_token
encrypts the response using the encrypted response mode defined by the ISO-aligned profile

10.2 Verifier conformance¶

10.2.1 SD-JWT VC track verifier conformance¶

An implementation conforms to this RFC as a Verifier under the SD-JWT VC track if it:

satisfies all applicable Verifier requirements in Section 7.2 (APT-PRES-VER-01 through APT-PRES-VER-16)
implements the relevant interfaces in Section 8
supports OpenID4VP v1.0 presentation requests and response handling
supports the same-device and cross-device presentation flows required by this RFC
supports SD-JWT VC presentation
creates Presentation Requests containing the information necessary for Wallet processing
validates received presentation responses before relying on them
enforces request-response correlation, anti-replay, and proof-validation requirements

A Verifier conforming to the SD-JWT VC track SHALL conform to the stricter ETSI-aligned request-object, verifier-information, metadata, and response-protection rules defined by this document for the flows in scope.

10.2.2 ISO/IEC 18013-7 remote mdoc track verifier conformance¶

An implementation conforms to this RFC as a Verifier under the ISO/IEC 18013-7 remote mdoc track if it:

satisfies all applicable Verifier requirements in Section 7.2 as applicable to the mdoc flow
satisfies all ISO mdoc verifier requirements (APT-PRES-VER-MDOC-01 through APT-PRES-VER-MDOC-10)
implements the ISO-aligned interfaces in Section 8, including Section 8.2.3.1, Section 8.2.5, and Section 8.3.3.1
constructs the Presentation Request using format = mso_mdoc with document type, namespace, and element identifiers
makes the request available using request_uri
reconstructs the SessionTranscript and validates the cryptographic binding of the returned DeviceResponse
validates DeviceResponse presence, format, document type match, namespace and element consistency, nonce and handover consistency, and cryptographic integrity

10.3 Conformance boundaries¶

Conformance to this RFC demonstrates protocol-level interoperability for presentation request processing, Wallet invocation, presentation submission, and verifier-side validation within the scope of the claimed track(s).

Conformance to this RFC does not by itself demonstrate:

compliance with a complete verifier trust framework
compliance with ARF/CIR obligations beyond the protocol interoperability scope exercised here
compliance with sector-specific supervisory or legal requirements
compliance with the full ISO/IEC 18013-5 proximity device retrieval profile (ETSI TS 119 472-2 clause 5)
compliance with ETSI requirements that are out of scope for this RFC, including API-mediated flows
compliance with ISO/IEC TS 18013-7 requirements beyond the remote presentation scope defined by this RFC

10.4 Scope of the conformance matrix¶

The conformance matrix defined by this RFC verifies baseline protocol interoperability between the implementation under test and the reference endpoints or reference request/response patterns defined by this APTITUDE Presentation Profile.

It is intended to confirm correct support for representative OpenID4VP v1.0 presentation flows covered by this RFC, including the credential presentation formats and response behaviors in scope for the selected test scenarios.

The matrix is a protocol interoperability matrix, not a complete ARF/CIR compliance assessment.

It focuses on:

presentation request processing
Wallet invocation
presentation generation and submission
request-response correlation
verifier-side response validation
format-specific interoperability checks for the credential formats in scope

It does not exhaustively test broader trust, governance, privacy, supervisory, legal, or deployment-specific obligations.

For avoidance of doubt, the matrix in this version does not exercise ETSI clause 5 proximity RequestInfo transport. That ETSI mechanism remains outside the conformance scope of this RFC version.

Where ARF or CIR references are included, they provide traceability and alignment for the interoperability capability being exercised, rather than full normative coverage of the broader requirement domain.

10.5 Additional profile-specific conformance claims¶

If an implementation claims support for an additional ecosystem profile layered on top of this RFC, that claim SHOULD be stated separately from RFC conformance.

Such additional claims MAY cover:

signed Request Objects
structured verifier information
verifier metadata requirements
encrypted presentation responses
stronger proof-binding requirements
ecosystem-specific verifier identification rules
ecosystem-specific trust or registration processing rules

Those additional claims are outside RFC conformance unless explicitly incorporated into the applying profile and corresponding conformance tests.

11. Wallet-Under-Test Conformance Catalogue and Deployed Test Matrix¶

11.1 Conformance Check Catalogue¶

This catalogue defines the baseline conformance checks that support RFC interoperability claims under Section 10.

11.1.1 Baseline conformance checks¶

Check ID	Conformance Check	What Is Verified At Runtime	ARF / CIR Linkage
`VP-CHECK-01`	Request resolution and processing	The Wallet resolves the request reference and processes the Presentation Request without transport, parsing, or structural failure.	CIR presentation interface support; ARF interoperability baseline
`VP-CHECK-02`	ETSI-aligned verifier identification	The Request Object uses `client_id` with the `x509_hash` Client Identifier Prefix and presents the verifier identifier required by the ETSI-aligned flow.	ARF verifier interoperability; CIR secure presentation interface
`VP-CHECK-03`	Signed Request Object validation	The Wallet validates the signed Request Object and rejects missing, malformed, or unverifiable request-object protection.	ARF request integrity; CIR secure presentation interface
`VP-CHECK-04`	Structured verifier-information processing	The Wallet correctly processes mandatory ETSI-aligned verifier information, including `verifier_info` and required `client_metadata` verifier key material.	ARF verifier transparency and request processing; CIR secure presentation interface
`VP-CHECK-05`	DCQL request satisfaction	The Wallet returns a response matching the requested DCQL credential and claim constraints for the selected credential format and request profile.	ARF controlled attribute presentation; CIR presentation request processing
`VP-CHECK-06`	Response correlation	The Verifier can correlate the response to the stored session using response-mode-specific state and transaction context.	CIR secure presentation interface; ARF transaction integrity baseline
`VP-CHECK-07`	Nonce binding	A recoverable `nonce` is present where expected and is preserved consistently across request processing and response validation.	ARF replay protection baseline; CIR secure presentation interface
`VP-CHECK-08`	SD-JWT proof-binding validation	Where SD-JWT proof binding is present, the Verifier checks the required recipient-binding and integrity inputs, including `aud` and `sd_hash`, as applicable to the selected profile.	ARF proof binding and recipient restriction; CIR secure presentation interface
`VP-CHECK-09`	Encrypted response handling	The Wallet and Verifier apply the mandatory ETSI-aligned response-protection behavior and successfully exchange an encrypted presentation or authorization response.	ARF protected response handling; CIR secure presentation interface
`VP-CHECK-10`	Transaction-data binding	Where transaction data is included, it is preserved and evaluated in the same Verifier session context as the credential request.	ARF transaction-aware presentation patterns; CIR secure presentation interface
`VP-CHECK-11`	mdoc `DeviceResponse` validation	For ISO/IEC 18013-7 remote mdoc presentation, the Verifier validates `DeviceResponse` presence and format, document type match, namespace and element consistency, request-response correlation, nonce and handover consistency, and cryptographic validation of the returned mdoc presentation object against the reconstructed `SessionTranscript`.	ARF credential-format interoperability; CIR presentation interface support; ISO/IEC TS 18013-7 alignment
`VP-CHECK-12`	Request-URI retrieval	The Wallet successfully retrieves and processes the Presentation Request using the `request_uri` parameter, as required by the ETSI-aligned non-API-mediated flow and the ISO/IEC 18013-7-aligned remote mdoc flow.	ARF request transfer/interoperability; CIR presentation interface support
`VP-CHECK-17`	ETSI authorization-endpoint invocation	Where the deployed ETSI-aligned same-device flow uses authorization-endpoint invocation, the Wallet and Verifier correctly invoke and process the request using the `eu-eaap://` scheme.	ETSI-aligned invocation interoperability; CIR presentation interface support
`VP-CHECK-18`	Remote verifier registration information transport	For ETSI-aligned remote presentation flows that require verifier registration material, the Request Object carries that material in `verifier_info` and the Wallet processes it as verifier context.	ETSI verifier transparency; CIR secure presentation interface
`VP-CHECK-13`	ISO mdoc invocation method	The Wallet is invoked using the `mdoc-openid4vp://` scheme for same-device remote mdoc presentation under the ISO/IEC 18013-7-aligned profile.	ISO/IEC TS 18013-7 alignment; ARF wallet invocation interoperability
`VP-CHECK-14`	ISO mdoc request structure	The Presentation Request uses `format = mso_mdoc`, identifies the requested document type, and specifies namespace and element identifiers compatible with ISO mdoc processing.	ISO/IEC TS 18013-7 alignment; ARF request interoperability
`VP-CHECK-15`	ISO `SessionTranscript` binding	The Wallet constructs the `SessionTranscript` using the OpenID4VP-to-ISO handover mapping, and the Verifier reconstructs and validates the same `SessionTranscript` inputs. The `DeviceResponse` is cryptographically bound to the originating request through the `SessionTranscript`.	ISO/IEC TS 18013-7 alignment; ARF session integrity
`VP-CHECK-16`	ISO mdoc encrypted response	The Wallet encrypts the mdoc presentation response using an encrypted response mode supported by the selected OpenID4VP mdoc profile. The Verifier successfully decrypts and processes the response.	ISO/IEC TS 18013-7 alignment; ARF protected response handling

11.2 Deployed Test Case Matrix¶

Test Case ID	Deployed Scenario	Request Profile / Variant	Checks Covered	Expected Outcome
`VP-001`	DCQL-based Verifiable Presentation request for `urn:eu.europa.ec.eudi:pid:1` with `family_name` claim, `x509_hash` `client_id`, signed Request Object, mandatory verifier information, and encrypted response	PID / SD-JWT ETSI-aligned selective-claim request	`VP-CHECK-01`, `VP-CHECK-02`, `VP-CHECK-03`, `VP-CHECK-04`, `VP-CHECK-05`, `VP-CHECK-06`, `VP-CHECK-07`, `VP-CHECK-08`, `VP-CHECK-09`	Successful completion of the ETSI-aligned PID / `family_name` presentation session
`VP-002`	DCQL-based Verifiable Presentation request for `urn:eu.europa.ec.eudi:pid:1` with `family_name` claim using a second ETSI-aligned request variant	Second deployed PID / SD-JWT ETSI-aligned selective-claim variant	`VP-CHECK-01`, `VP-CHECK-02`, `VP-CHECK-03`, `VP-CHECK-04`, `VP-CHECK-05`, `VP-CHECK-06`, `VP-CHECK-07`, `VP-CHECK-08`, `VP-CHECK-09`	Successful completion of the ETSI-aligned PID / `family_name` presentation session
`VP-003`	DCQL-based Verifiable Presentation request for `urn:eu.europa.ec.eudi:pid:1` with `family_name` claim using a third ETSI-aligned request variant	Third deployed PID / SD-JWT ETSI-aligned selective-claim variant	`VP-CHECK-01`, `VP-CHECK-02`, `VP-CHECK-03`, `VP-CHECK-04`, `VP-CHECK-05`, `VP-CHECK-06`, `VP-CHECK-07`, `VP-CHECK-08`, `VP-CHECK-09`	Successful completion of the ETSI-aligned PID / `family_name` presentation session
`VP-004`	DCQL-based Verifiable Presentation request for `urn:eu.europa.ec.eudi:pid:1` with `family_name` claim and transaction data, using ETSI-aligned verifier identification, signed Request Object, and encrypted response	PID / SD-JWT ETSI-aligned request with transaction data	`VP-CHECK-01`, `VP-CHECK-02`, `VP-CHECK-03`, `VP-CHECK-04`, `VP-CHECK-05`, `VP-CHECK-06`, `VP-CHECK-07`, `VP-CHECK-08`, `VP-CHECK-09`, `VP-CHECK-10`	Successful completion of the ETSI-aligned transaction-data PID presentation session
`VP-005`	DCQL-based VP request for `urn:eu.europa.ec.eudi:pid:1`, `x509_hash` `client_id`, signed Request Object, structured verifier information, and encrypted response	PID / SD-JWT ETSI-aligned request and response	`VP-CHECK-01`, `VP-CHECK-02`, `VP-CHECK-03`, `VP-CHECK-04`, `VP-CHECK-05`, `VP-CHECK-06`, `VP-CHECK-07`, `VP-CHECK-08`, `VP-CHECK-09`	Successful completion of the ETSI-aligned PID presentation session
`VP-006`	DCQL-based Verifiable Presentation request for `urn:eu.europa.ec.eudi:pid:1`, `x509_hash` `client_id`, signed Request Object, structured verifier information, encrypted response, and `request_uri`-based request retrieval	PID / SD-JWT ETSI-aligned request retrieval variant	`VP-CHECK-01`, `VP-CHECK-02`, `VP-CHECK-03`, `VP-CHECK-04`, `VP-CHECK-05`, `VP-CHECK-06`, `VP-CHECK-07`, `VP-CHECK-08`, `VP-CHECK-09`, `VP-CHECK-12`	Successful completion of the ETSI-aligned PID presentation session using `request_uri` retrieval
`VP-006A`	ETSI-aligned same-device Presentation Request using authorization-endpoint invocation with the `eu-eaap://` scheme	PID / SD-JWT ETSI-aligned same-device authorization-endpoint invocation variant	`VP-CHECK-01`, `VP-CHECK-02`, `VP-CHECK-03`, `VP-CHECK-04`, `VP-CHECK-09`, `VP-CHECK-17`	Successful completion of the ETSI-aligned PID presentation session using `eu-eaap://` invocation
`VP-007`	ISO/IEC 18013-7-aligned remote mdoc Presentation Request for `urn:eu.europa.ec.eudi:pid:1:mso_mdoc`, using `mdoc-openid4vp://` invocation, `format = mso_mdoc`, `request_uri`-based request retrieval, `verifier_info`-carried verifier registration material where required, `SessionTranscript` binding, base64url-encoded `DeviceResponse` in `vp_token`, encrypted response, and ISO-bound verifier validation	ISO/IEC 18013-7-aligned remote mdoc presentation with `DeviceResponse` validation, `SessionTranscript` binding, verifier registration-information transport, and encrypted response protection	`VP-CHECK-01`, `VP-CHECK-06`, `VP-CHECK-07`, `VP-CHECK-11`, `VP-CHECK-12`, `VP-CHECK-13`, `VP-CHECK-14`, `VP-CHECK-15`, `VP-CHECK-16`, `VP-CHECK-18`	Successful completion of the ISO/IEC 18013-7-aligned remote mdoc presentation session

12. References¶

OpenID Foundation, OpenID for Verifiable Presentations 1.0
OpenID Foundation, OpenID4VC High Assurance Interoperability Profile (HAIP) 1.0
Architecture and Reference Framework (ARF)
APTITUDE interoperability and conformance testing materials
WE BUILD Credential Presentation conformance specification used as structural reference for this RFC draft
ETSI TS 119 472-2 V1.2.1 (2026-03), Electronic Signatures and Trust Infrastructures (ESI); Profiles for Electronic Attestation of Attributes; Part 2: Profiles for EAA/PID Presentations to Relying Party
ISO/IEC TS 18013-7:2025, Personal identification — ISO-compliant driving licence — Part 7: Mobile driving licence (mDL) add-on functions
ISO/IEC 18013-5:2021, Personal identification — ISO-compliant driving licence — Part 5: Mobile driving licence (mDL) application

APTITUDE RFC-02 Presentation Profile¶

Authors¶

Reviewers¶

1. Introduction¶

2. Scope¶

3. Normative Language¶

4. Roles and Components¶

4.1 Holder¶

4.2 Wallet Unit / Wallet¶

4.3 Verifier¶

4.4 Verifier Backend¶

4.5 Relying Application¶

5. Protocol Overview¶

5.1 Baseline APTITUDE presentation mode¶

5.2 ETSI-aligned mandatory requirements¶

5.3 Supported presentation patterns¶

5.4 High-level presentation sequence¶

5.5 Relation to ETSI-aligned presentation profiling¶

5.6 ISO/IEC 18013-7 remote mdoc profile¶

6. High-Level Flows¶

6.1 Same-Device Presentation Flow¶

6.1.1 Presentation Request Creation¶

6.1.2 Wallet Invocation¶

6.1.3 Wallet Validation¶

6.1.4 Holder Consent¶

6.1.5 Presentation Generation¶

6.1.6 Presentation Submission¶

6.1.7 Result Handling¶

6.2 Cross-Device Presentation Flow (Non-API-mediated)¶

6.2.1 Presentation Request Creation and Display¶

6.2.2 Wallet Invocation via QR, Link, or Equivalent¶

6.2.3 Wallet Validation¶

6.2.4 Holder Consent¶

6.2.5 Presentation Generation¶

6.2.6 Presentation Submission¶

6.2.7 Result Handling¶

7. Normative Requirements¶

7.1 Wallet Requirements¶

7.2 Verifier Requirements¶

8. Interface Definitions¶

8.1 Wallet Invocation Interface¶

8.2 Presentation Request Interface¶

8.2.1 Baseline structural requirements¶

8.2.2 ETSI-aligned request-object requirements¶

8.2.3 Credential-format considerations¶

8.2.3.1 ISO/IEC 18013-7 remote mdoc request requirements¶

8.2.4 Request validation expectations¶

8.2.5 ISO/IEC 18013-7 session binding¶

8.3 Presentation Response Interface¶

8.3.1 Baseline response requirements¶

8.3.2 ETSI-aligned response protection¶

8.3.3 Credential-format considerations¶

8.3.3.1 ISO/IEC 18013-7 remote mdoc response requirements¶

8.3.4 Error responses¶

8.4 Verifier Metadata Interface¶

9. Privacy and Security Considerations¶

9.1 Data minimisation and disclosure control¶

9.2 Request authenticity and integrity¶

9.3 Replay protection and transaction binding¶

9.4 Response confidentiality and secure transport¶

9.5 Verifier impersonation and phishing resistance¶

9.6 Credential-format considerations¶

9.7 Logging, retention, and local protection¶

9.8 Baseline RFC boundary¶

10. Conformance¶

10.1 Wallet conformance¶

10.1.1 SD-JWT VC track wallet conformance¶

10.1.2 ISO/IEC 18013-7 remote mdoc track wallet conformance¶

10.2 Verifier conformance¶

10.2.1 SD-JWT VC track verifier conformance¶

10.2.2 ISO/IEC 18013-7 remote mdoc track verifier conformance¶

10.3 Conformance boundaries¶

10.4 Scope of the conformance matrix¶

10.5 Additional profile-specific conformance claims¶

11. Wallet-Under-Test Conformance Catalogue and Deployed Test Matrix¶

11.1 Conformance Check Catalogue¶

11.1.1 Baseline conformance checks¶

11.2 Deployed Test Case Matrix¶

12. References¶