11.2.2. Proximity Flow¶

This section describes how a Relying Party Instance requests a Wallet Instance to present an mdoc-CBOR Credential.

The presentation uses the ISO/IEC-mdoc EAAP realization and presentation profile in clauses 4.2 and 5 of V1.2.1 of [ETSI TS 119 472-2], as required by [CIR2024/2982]. ETSI TS 119 472-2 V1.2.1 prevails where it modifies [ISO18013-5].

The applicable Trust Framework is selected as specified in Selection at Presentation.

The high-level presentation phase is structured into three broad sub-phases as depicted in the following figure:

The figure illustrates the High-Level Presentation Flow in proximity. — Fig. 11.14 High-Level Presentation Flow in proximity.¶

The sub-phases are described below:

1. Device Engagement: This subphase begins when the User is prompted to disclose specific attributes from the mdoc(s). The objective of this subphase is to establish a secure communication channel between the Wallet Instance and the Relying Party Instance, so that the mdoc requests and responses can be exchanged during the communication subphase. The messages exchanged in this subphase are transmitted through short-range technologies to limit the possibility of interception and eavesdropping. Device Engagement data may be transferred using either QR code or NFC technologies.

2. Session Establishment: During the session establishment phase, the Relying Party Instance sets up a secure connection. All data transmitted over this connection is encrypted using a session key, which is known to both the Wallet Instance and the Relying Party Instance at this stage. The conditions for ending the session are specified in [ISO18013-5 #12.2.4].

3. Communication - Device Retrieval: The Relying Party Instance encrypts the mdoc request with the appropriate session key and sends it to the Wallet Instance together with its public key in a session establishment message. The Wallet Instance uses the data from the session establishment message to derive the session key and then to decrypt the mdoc request. During the communication subphase, the Relying Party Instance has the option to request information from the Wallet Instance using mdoc requests and responses. The primary mode of communication is the secure channel established during the session setup. The Wallet Instance encrypts the mdoc response using the session key and transmits it to the mobile Relying Party Instance via a session data message.

Relying Party and Wallet Instances registered in the IT-Wallet ecosystem MUST support at least the following flows.

The supported flows include the Supervised Device Retrieval flow, where a human Relying Party oversees the verification process in person, or the unsupervised flow. In the unsupervised flow, verification might happen through automated systems without human oversight (WP_095).
Relying Party Instance Authentication following the mechanisms defined in the ISO18013-5 for the reader authentication (WP_098).
Domestic Document Type and Namespaces defined in this technical specification in addition to those already defined in the ISO18013-5 for the mDL (see mdoc-CBOR Credential Format for more details) (WP_099).

The following table shows the supported Device Engagement technologies (WP_097), specifying which are mandatory.

Transmission technology	ISO 18013-5	ISO 18013-5	IT Wallet	IT Wallet
	Wallet Instance	RP Instance	Wallet Instance	RP Instance
QR code	C^a	M	MUST	C – MUST if the device is equipped with a camera or QR code reader and BLE.
NFC	C^a	M	RECOMMENDED	C – MUST if the device is equipped with an NFC reader.

Key: C = Conditional | M = Mandatory | ^aSupport for at least one of these methods is mandatory (WP_097a).

The following table shows the supported Device Retrieval technologies, specifying which are mandatory.

Transmission technology	ISO 18013-5	ISO 18013-5	IT Wallet	IT Wallet
	Wallet Instance	RP Instance	Wallet Instance	RP Instance
BLE	C^a	M	MUST	C – MUST if the device is equipped with a camera or QR code reader and BLE.
NFC	C^a	M	RECOMMENDED	C – MUST if the device is equipped with an NFC reader.

Key: C = Conditional | M = Mandatory | ^aSupport for at least one of these methods is mandatory (WP_096b).

Note

From the second edition, version 3, ISO18013-5 does not define or support Server Retrieval as a transport option. ETSI requirement ISO/IEC 18013-SUPPORT-01 in [ETSI TS 119 472-2] prohibits Server Retrieval in this profile. Only proximity retrieval methods (NFC, BLE, and optionally Wi-Fi Aware) are specified (WP_096 and WP_096a).

The following figure illustrates the low-level flow compliant with ISO 18013-5 for proximity flow.

The figure illustrates the Low-Level Presentation Flow in proximity. — Fig. 11.15 Low-Level Presentation Flow in proximity.¶

Step 1: The User opens the Wallet Instance initiating the process.

Step 2: The User authenticates itself to the Wallet Instance. This can be done by the Wallet Instance or a Wallet Secure Cryptographic Application (WSCA). It is a prerequisite for accessing sensitive data and presenting attributes (WP_100).

Step 3: The User selects the proximity presentation functionality.

Step 4: [Optional] If the initial authentication in Step 2 was not done through WSCA, a separate authentication via WSCA MAY be required (WP_100).

Step 5: The Wallet Instance generates a new ephemeral Elliptic Curve key pair for the session (WP_101). The public key (EDeviceKey.Pub) is exchanged with the Relying Party Instance as Device Engagement data and is used with EReaderKey.Pub to derive the session keys.

Box A

The Wallet Instance and Relying Party Instance exchange Device Engagement data via QR code or via NFC Connection Handover (WP_097).

Refer to:

Sec 8.2.2.1 for DeviceEngagement over QR code
Sec 8.2.2.2 for DeviceEngagement over NFC

Step 6: The Relying Party Instance generates its ephemeral key pair (EReaderKey.Priv, EReaderKey.Pub). The private key (EReaderKey.Priv) MUST be kept secret. The public key (EReaderKey.Pub) MUST be used in establishing the session.

Step 7: The Wallet Instance and the Relying Party Instance MUST derive the session keys independently. The derivation uses each party's private ephemeral key and the other party's public ephemeral key through a key agreement protocol. This ensures session encryption. In this particular step, the Relying Party Instance MUST compute its session key (PPR-002 and WP_104).

Step 8: The Relying Party Instance MUST prepare a SessionEstablishment message containing EReaderKey.Pub and the encrypted DeviceRequest. Every DocRequest in the DeviceRequest MUST contain its own readerAuth signed over ReaderAuthentication. The SessionEstablishment envelope MUST NOT be described as signed. The SessionEstablishment message MUST be encrypted using the session keys derived in the previous step (PPR-002). The established session MAY be later terminated based on the conditions as detailed in [ISO18013-5 #12.2.4].

Below are non-normative examples using the diagnostic notation of a CBOR-encoded EUDIW and National DeviceRequest. Each decoded request is encrypted inside SessionEstablishment.

The following non-normative example is the EUDIW DeviceRequest.

{
  "version": "1.0",
  "docRequests": [
    {
      "itemsRequest": 24(<<
        {
          "docType": "org.iso.18013.5.1.mDL",
          "nameSpaces": {
            "org.iso.18013.5.1": {
              "family_name": true,
              "document_number": true,
              "driving_privileges": true,
              "issue_date": true,
              "expiry_date": true,
              "portrait": false
            }
          },
          "requestInfo": {
            "euWrprc": h'5b73657269616c697a65642072632d7772702b6377742057525052435d',
            "euWrpRegistrarInfo": {
              "identifier": [
                {"type": "organizationIdentifier", "identifier": "VATIT-EXAMPLE-RP"}
              ],
              "srvDescription": [
                {"lang": "en", "content": "Example identity verification service"}
              ],
              "purpose": [
                {"lang": "en", "content": "Identity verification"}
              ],
              "registryURI": "https://registry.example.org/entities/example-rp",
              "intendedUseIdentifier": "identity-verification",
              "policyURI": "https://example.org/privacy",
              "credential": [
                {"format": "mso_mdoc", "meta": {"doctype_value": "org.iso.18013.5.1.mDL"}, "claim": ["org.iso.18013.5.1/family_name", "org.iso.18013.5.1/document_number"]}
              ]
            }
          }
        }
      >>),
      "readerAuth": [
        h'a10126',
        {
          33: [
            h'57525041432d656e642d656e746974792d6365727469666963617465', % WRPAC end-entity certificate placeholder
            h'57525041432d696e7465726d6564696174652d6365727469666963617465' % WRPAC intermediate certificate placeholder
          ]
        },
        null,
        h'65756469772d7265616465722d617574682d7369676e6174757265' % EUDIW reader-auth signature placeholder
      ]
    }
  ]
  % x5chain starts with the WRPAC; the Trust Anchor is intentionally omitted.
  % The serialized DeviceRequest is encrypted inside SessionEstablishment.
  % readerAuthAll, if present, is additional and cannot replace readerAuth.
}

The following non-normative example is the National Trust Framework DeviceRequest.

{
  "version": "1.0",
  "docRequests": [
    {
      "itemsRequest": 24(<<
        {
          "docType": "it.wallet.trust-registry.example.1",
          "nameSpaces": {
            "it.wallet.trust-registry.example": {
              "family_name": true,
              "document_number": true,
              "portrait": false
            }
          },
          "requestInfo": {
            % euWrprc is the UTF-8 byte string of a compact signed registration-entity Trust Mark JWT.
            "euWrprc": h'65794a68624763694f694a49557a49314e694973496e523563434936496b705856434a392e65794a7a64434936496d567a5a584a7a5a534973496d6c6b496a6f6956464a3951',
            "euWrpRegistrarInfo": {
              "identifier": [
                {"type": "organizationIdentifier", "identifier": "VATIT-EXAMPLE-NATIONAL-RP"}
              ],
              "srvDescription": [
                {"lang": "en", "content": "Example national verification service"}
              ],
              "purpose": [
                {"lang": "en", "content": "Identity verification"}
              ],
              "registryURI": "https://registry.example.org/entities/example-national-rp",
              "intendedUseIdentifier": "identity-verification",
              "policyURI": "https://example.org/national-privacy",
              "credential": [
                {"format": "mso_mdoc", "meta": {"doctype_value": "it.wallet.trust-registry.example.1"}, "claim": ["it.wallet.trust-registry.example/family_name", "it.wallet.trust-registry.example/document_number"]}
              ]
            }
          }
        }
      >>),
      "readerAuth": [
        h'a10126',
        {
          33: [
            h'4e6174696f6e616c2d61757468656e7469636174696f6e2d63657274696669636174652d656e642d656e74697479', % National authentication certificate placeholder
            h'4e6174696f6e616c2d61757468656e7469636174696f6e2d63657274696669636174652d696e7465726d656469617465' % National intermediate certificate placeholder
          ]
        },
        null,
        h'6e6174696f6e616c2d7265616465722d617574682d7369676e6174757265' % National reader-auth signature placeholder
      ]
    }
  ]
  % x5chain starts with the National authentication certificate; the Authentication Trust Anchor is omitted.
  % This example contains no EUDIW WRPAC or WRPRC evidence.
  % The serialized DeviceRequest is encrypted inside SessionEstablishment.
}

Box B

The Relying Party Instance MUST transmit the encrypted SessionEstablishment message to the Wallet Instance over an NFC or a BLE secure connection that was established using the Device Engagement information. Refer to:

Sec 8.2.2.3 for SessionEstablishment over BLE, and
Sec 8.2.2.5 for SessionEstablishment over NFC

Step 9: The Wallet Instance MUST compute the session key, as described in Step 7.

Step 10: Upon receiving the SessionEstablishment message, the Wallet Instance MUST decrypt it using the shared session key. The Wallet Instance MUST validate either every readerAuth in every DocRequest or the readerAuthAll over its ReaderAuthentication data. The unprotected COSE x5chain header (label 33) MUST contain the end-entity reader certificate first and the certificate chain up to but excluding the selected Trust Anchor.

The Wallet Instance validating the mdoc reader certificate chain MUST select exactly one trust path before authorization: EUDIW uses the WRPAC and applicable Lists of Trusted Entities according to EUDIW Authentication. National uses the Relying Party authentication certificate and Authentication Trust Anchor.

Step 11: After successful mdoc reader authentication, the Wallet Instance MUST execute authorization under the selected path before consent. Authentication and Authorization for that path are specified in Selection at Presentation.

Authentication and binding failures are terminal.

The Wallet Instance MUST display the following human-readable information. The information includes the verified Relying Party and Service identity, the intended use or purpose, and the requested Credentials and attributes. The information also includes the retention intent and the privacy-policy information from the selected path's validated authorization artifact and Registrar information.

For EUDIW intermediation, the Wallet Instance MUST display the intermediated Relying Party and Service. The Wallet Instance MUST NOT display Intermediary trade names.

For the National direct path it MUST use validated Trust Mark transparency claims (Authorization, and User Transparency).

Step 12: The User reviews the validated path-specific transparency data and requested attributes and then approves or refuses the presentation. The Wallet Instance MUST NOT require the User approval before authentication and authorization succeed, except where an expressly permitted authorization override applies.

Box C

After receiving User approval, the Wallet Instance MUST retrieve the requested mdoc Digital Credentials (PPR-006 and WP_108). It MUST place every disclosed issuer-signed attribute in issuerSigned and MAY place an attribute in deviceSigned only when the Provider explicitly authorized it. A successful Document is an ISO/mdoc EAAP only when it has no errors. An error-bearing document is not a successful EAAP. The Wallet Instance MUST sign deviceSignature over the required device-authentication data, encrypt the CBOR DeviceResponse in SessionData, and transmit it over the secure channel (WP_109–112). Refer to (WP_112a–112b):

Sec 8.2.2.4 for SessionData over BLE, and
Sec 8.2.2.5 for SessionData over NFC

Below is a non-normative example using the diagnostic notation of a CBOR-encoded DeviceResponse transported inside encrypted SessionData.

{
  "version": "1.0",
  "documents": [
    {
      "docType": "org.iso.18013.5.1.mDL",
      "issuerSigned": {
        "nameSpaces": {
          "org.iso.18013.5.1": [
            24(<< {"digestID": 0, "random": h'6973737565722d72616e646f6d', "elementIdentifier": "family_name", "elementValue": "Rossi"} >>),
            24(<< {"digestID": 3, "random": h'6973737565722d72616e646f6d2d32', "elementIdentifier": "issue_date", "elementValue": 1004(2025-03-27)} >>),
            24(<< {"digestID": 4, "random": h'6973737565722d72616e646f6d2d33', "elementIdentifier": "expiry_date", "elementValue": 1004(2030-03-27)} >>)
          ]
        },
        "issuerAuth": [
          << {1: -7} >>,
          {33: h'6973737565722d646f63756d656e742d7369676e65722d63657274696669636174652d636861696e'},
          null,
          h'6973737565722d617574682d7369676e6174757265'
        ]
      },
      "deviceSigned": {
        "nameSpaces": 24(<< {} >>),
        "deviceAuth": {
          "deviceSignature": [
            << {1: -7} >>,
            {},
            null,
            h'6465766963652d7369676e61747572652d6573333536'
          ]
        }
      }
      % No errors: this Document is a successful ISO/mdoc EAAP.
    }
  ],
  "status": 0
}

Step 13: The Relying Party Instance receives the SessionData. The Relying Party Instance MUST decrypt the SessionData. The Relying Party Instance MUST verify the Wallet Instance's signature to ensure the data's integrity and that it originates from the expected device (device binding). The Relying Party Instance MUST also check the validity of the mdoc, including its Issuer's signature. For a long-lived Digital Credential, the revocation status check is specified in Checking Credentials Statuses.

Step 14: Once the data exchange is complete, either party can terminate the session. The session can be terminated by sending the status code for session termination in a SessionData message. This can be sent together with an mdoc request or response [ISO18013-5 #12.2.4] (WP_113c). If BLE is used, this can involve sending a status code for session termination or the “End” command. In this scenario, the GATT Client (Relying Party Instance) MUST unsubscribe from characteristics and disconnect from the GATT server (Wallet Instance) (PPR-007, WP_113b, and WP_114).

Final Consideration: The presentation flow focused on the technical data exchange in proximity settings. It is crucial to recognise that supervised proximity flows involving a human verifier play a vital role in many use cases (e.g., age verification at a store, identity check by law enforcement). The human element adds a layer of identity verification through visual inspection and comparison, contributing to User Binding and overall authentication assurance aspects not fully captured in a purely technical presentation flow.

Note

During each Credential presentation transaction executed through the proximity flow, the Wallet Instance MUST create and maintain a corresponding transaction record in the transaction log (see Wallet Instance Dashboard and Transaction Logging).

The transaction record MUST be created once the Wallet Instance has successfully authenticated the reader (i.e., after decrypting the SessionEstablishment message and verifying reader authentication, Step 10). At this point, the record records only an authenticated request and MUST include the selected framework and request context available at that stage, without logging any attribute values.

The record MUST be updated as the transaction progresses to reflect authorization, the User decision, the disclosure result, and failure reason, without logging any attribute values.

The record MUST be finalized when the transaction ends, indicating the outcome (e.g., completed, failed, or session terminated. Steps 13–14 and Session Termination).

11.2.2.1. `DeviceEngagement` over QR Code¶

The following figure illustrates the low-level flow compliant with ISO 18013-5 for DeviceEngagement over QR Code corresponding to Box A in Figure Low-Level Presentation Flow in proximity..

The figure illustrates the Device Engagement over QR Code Presentation Flow in proximity. — Fig. 11.16 Device Engagement over QR Code.¶

Step 1: The Wallet Instance presents a QR Code to the Relying Party Instance. The QR code MUST contain a URI with “mdoc:” as scheme and the DeviceEngagement structure specified in Section 9.1 encoded using base64url-without-padding, according to RFC 4648, as path (WP_102a).

11.2.2.1.1. Non-Normative Example with BLE as Data Retrieval¶

Below is a non-normative example using the diagnostic notation of a CBOR-encoded DeviceEngagement that utilizes QR for Device Engagement and Bluetooth Low Energy (BLE) for data retrieval.

{
  0: "1.1", % Version (Updated to 1.1 because Capabilities and OriginInfos are present)
  1: % Security
  [
    1, % defines the cipher suite , which contains only EC curves
    24(<< % embedded CBOR data item
    {
      1: 2, % kty:EC2 (Elliptic curves with x and y coordinate pairs)
      -1: 1, % crv:p256
      -2:h'5A88D182BCE5F42EFA59943F33359D2E8A968FF289D93E5FA444B624343167FE', % x-coordinate
      -3:h'B16E8CF858DDC7690407BA61D4C338237A8CFCF3DE6AA672FC60A557AA32FC67' % y-coordinate
    }
    >>)
  ],
  2: % DeviceRetrievalMethods (Device engagement using QR code with BLE for retrieval)
  [
    [
      2, % BLE
      1, % Version
      { % BLE options
        0: false, % no support for mdoc peripheral server mode
        1: true,  % support for mdoc central client mode
        11: h'45EFEF742B2C4837A9A3B0E1D05A6917' % UUID of mdoc client central mode
      }
    ]
  ],
  5: % OriginInfos (Required because Capabilities is present)
  [],
  6: % Capabilities (Defines supported features)
  {
    2: false, % HandoverSessionEstablishmentSupport (Supports negotiated handover)
    3: true % ReaderAuthAllSupport (Supports reader authentication)
  }
}

11.2.2.1.2. Non-Normative Example with NFC as Data Retrieval¶

Below is a non-normative example using the diagnostic notation of a CBOR-encoded DeviceEngagement that utilizes QR for Device Engagement and NFC for data retrieval.

{
  0: "1.1", % Version (Updated to 1.1 because Capabilities and OriginInfos are present)
  1: % Security
  [
    1, % defines the cipher suite , which contains only EC curves
    24(<< % embedded CBOR data item
    {
      1: 2, % kty:EC2 (Elliptic curves with x and y coordinate pairs)
      -1: 1, % crv:p256
      -2:h'5A88D182BCE5F42EFA59943F33359D2E8A968FF289D93E5FA444B624343167FE', % x-coordinate
      -3:h'B16E8CF858DDC7690407BA61D4C338237A8CFCF3DE6AA672FC60A557AA32FC67' % y-coordinate
    }
    >>)
  ],
  2: % DeviceRetrievalMethods (Device engagement using QR code with BLE for retrieval)
  [
    [
      1, % NFC
      1, % Version
      { % NFC options
        0: uint, % Maximum length of command data field
        1: uint, % Maximum length of response data field
      }
    ]
  ],
  5: % OriginInfos (Required because Capabilities is present)
  [],
  6: % Capabilities (Defines supported features)
  {
    2: false, % HandoverSessionEstablishmentSupport (Supports negotiated handover)
    3: true % ReaderAuthAllSupport (Supports reader authentication)
  }
}

Step 2: The Relying Party uses its Relying Party Instance to scan the QR code and retrieve the DeviceEngagement data from the mdoc. It MUST select one of the transmission technologies from the ones provided in the DeviceEngagement structure.

11.2.2.2. `DeviceEngagement` over NFC¶

The following figure illustrates the low-level flow compliant with ISO 18013-5 for DeviceEngagement over NFC corresponding to Box A in Figure Low-Level Presentation Flow in proximity. (WP_103).

The figure illustrates the Device Engagement over NFC Presentation Flow in proximity. — Fig. 11.17 Device Engagement over NFC.¶

DeviceEngagement over NFC is based on the NFC Forum Connection Handover Technical Specification, Version 1.5. Only Reader/ Writer mode using a Type 4 Tag is supported. The Connection Handover protocol is always initiated by the Relying Party Instance, which makes the role of Handover Requester. The Wallet Instance MUST use either Static Handover or Negotiated Handover: - Static Handover: The Relying Party Instance retrieves a Handover Select message directly from the Wallet Instance's Type 4 Tag. This message contains at least one Alternative Carrier Record, each indicating a retrieval method supported by the Wallet Instance (WP_103a). The Relying Party Instance MUST select one of these transmission technologies. (see Step 1) - Negotiated Handover: The Wallet Instance includes the service urn:nfc:sn:handover in a Service Parameter Record of the initial NDEF (NFC Data Exchange Format) message (WP_103b). Upon selecting this service, the Relying Party Instance sends a Handover Request with an Alternative Carrier Record for each carrier it supports. The Wallet Instance replies with a Handover Select message containing exactly one selected carrier. (See Step 2-4)

Step 1: The Relying Party Instance reads the Wallet’s NFC Type 4 Tag to obtain a Handover Select message. The message includes the following records. - An Alternative Carrier Record is an NDEF record inside a Handover Select or Handover Request message. It points to one possible communication technology (called a “carrier”), such as NFC or BLE. It tells the reader about the supported carrier and a pointer (Auxiliary Data Reference) to more detailed information. The Alternative Carrier Record for the NFC device retrieval transmission technology MUST reference the Carrier Configuration Record with the ID reference “nfc”. - Carrier Configuration Record provides the technical parameters needed actually to use that carrier. For NFC device retrieval transmission technology, it MUST have the type “iso.org:18013:nfc” and the ID reference “nfc”. The binary content of the Carrier Configuration Record MUST be encoded according to Table 1 of [ISO18013-5 #9.2.2] (WP_103d).

For example: For NFC, this defines maximum APDU (Application Protocol Data Unit) command/response lengths. For BLE, it defines the Wallet Instance service UUID, characteristic UUIDs, MTU (Maximum Transmission Unit) size, and optional connection parameters. If early SessionEstablishment is supported, it also lists the TNEP (Tag NDEF Exchange Protocol) service name used to send the SessionEstablishment message during handover.

Note

For the NFC device retrieval transmission technology, the contents of the Alternative Carrier Record and Carrier Configuration Record(s) MUST comply with [ISO18013-5 #9.2.2]. For the BLE device retrieval transmission technology, the contents of the Alternative Carrier Record and Carrier Configuration Record(s) MUST comply with [ISO18013-5 #11.1.2].

Auxiliary Data Record MUST carry the DeviceEngagement structure from the Wallet Instance to the Relying Party Instance as part of the auxiliary NDEF record in the Handover Select message. This record has the type iso.org:18013:deviceengagement, the ID reference “mdoc”, and uses the NFC forum external type format (0x04). For each Alternative Carrier record, the Auxiliary Data Reference MUST point to the NDEF record containing the DeviceEngagement Structure (WP_103e).

Step 2: The Relying Party Instance reads the Wallet Instance's Initial NDEF (NFC Data Exchange Format) message, which contains a service parameter record for urn:nfc:sn:handover, indicating the Wallet supports Negotiated Handover.

Step 3: The Relying Party Instance sends a Handover Request to the Wallet Instance listing the supported carriers.

Step 4: The Wallet Instance returns Handover Select constructed in response to the received Handover Request message. The contents of the Handover Select message is the same as Step 1 (WP_103f).

Note

Use of Negotiated Handover for Device Engagement allows negotiation of transfer methods. For BLE, it additionally allows negotiation of keys used by the transmission layer. This provides improved user experience and enhances the security of data transmission [ISO18013-5 #9.2.1].

Note

Proceed only if the DeviceEngagement Capabilities include HandoverSessionEstablishmentSupport set to true (WP_103c). Otherwise, skip the early SessionEstablishment. The early SessionEstablishment is sent via a dedicated TNEP service. The same SessionEstablishment MUST also be sent again during data retrieval and MUST match. If it does not match, the Wallet Instance terminates (WP_103g). If the early SessionEstablishment fails to send, proceed as normal (WP_103h).

Step 5: [Optional] Relying Party Instance opens the TNEP service named [urn:placeholder] with the Wallet Instance during the negotiated handover to deliver the early SessionEstablishment message.

Step 6: Relying Party Instance sends SessionEstablishment (e.g., EReaderKey + encrypted DeviceRequest). Wallet Instance processes it. Data retrieval has not started yet.

Step 7: Relying Party Instance closes the TNEP service.

Note

If an optional SessionEstablishment message is sent during Negotiated Handover (Step 5), the Wallet Instance MUST verify that it matches the SessionEstablishment message received during Device Retrieval (using BLE or NFC secure channel). This verification is required to ensure a correct Session Binding.

11.2.2.2.1. Non-Normative Example¶

Below is a non-normative example of a DeviceEngagement structure for Data Retrieval over BLE and NFC.

{
  0: "1.1", % Version (Updated to 1.1 because Capabilities and OriginInfos are present)
  1: % Security
  [
    1, % defines the cipher suite , which contains only EC curves
    24(<< % embedded CBOR data item
    {
      1: 2, % kty:EC2 (Elliptic curves with x and y coordinate pairs)
      -1: 1, % crv:p256
      -2:h'5A88D182BCE5F42EFA59943F33359D2E8A968FF289D93E5FA444B624343167FE', % x-coordinate
      -3:h'B16E8CF858DDC7690407BA61D4C338237A8CFCF3DE6AA672FC60A557AA32FC67' % y-coordinate
    }
    >>)
  ],
  2: % DeviceRetrievalMethods (Absent when using NFC for device engagement)
  [],
  5: % OriginInfos (Required because Capabilities is present)
  [],
  6: % Capabilities (Defines supported features)
  {
    2: true, % HandoverSessionEstablishmentSupport (Supports negotiated handover)
    3: true % ReaderAuthAllSupport (Supports reader authentication)
  }
}

11.2.2.3. `SessionEstablishment` over BLE¶

The following figure illustrates the low-level flow compliant with ISO18013-5 for SessionEstablishment over BLE corresponding to Boxes B in Figure 8.10.

The figure illustrates the Session Establishment over BLE Presentation Flow in proximity. — Fig. 11.18 Session Establishment over BLE.¶

Step 1: The Wallet Instance and Relying Party Instance establish a secure BLE connection [ISO18013-5 #11.1]. The Relying Party Instance (central) connects to the Wallet Instance (peripheral) using the Wallet Instance service UUID provided by DeviceEngagement, then discovers services/characteristics, and enables notifications as needed (WP_112c).

Step 2-5: [Optional] The Wallet Instance initiates verification by preparing to check the Relying Party’s identity via the Ident characteristic. The Ident characteristic is a BLE GATT characteristic that carries an identifier value as described in [ISO18013-5 #11.1.3.2]. The Wallet Instance derives the expected Ident value and reads the Relying Party's Ident characteristic, comparing it to the expected Ident, and terminating the BLE connection if a mismatch may occur.

Note

The purpose of the Ident characteristic is only to verify whether the Wallet Instance is connected to the correct Relying Party Instance before starting data retrieval. If the Wallet Instance is connected to the wrong Relying Party Instance, session establishment will fail. Connecting and disconnecting to a Relying Party Instance takes a relatively large amount of time. Therefore, it is faster to implement methods to identify the correct Relying Party Instance [ISO18013-5 #11.1.3.1] (WP_112d).

Step 6: Relying Party Instance sends the encrypted SessionEstablishment message (includes EReaderKey and encrypted DeviceRequest) over the established BLE connection.

Step 7-8: [Optional] If the Wallet Unit receives the SessionEstablishment message during Negotiated Handover, the Wallet Unit MUST verify that it matches the data-retrieval SessionEstablishment message (Step 6). In the event of a mismatch, the Wallet Unit MUST terminate the BLE connection [ISO18013-5 #9.2.3].

11.2.2.4. `SessionData` over BLE¶

The following figure illustrates the low-level flow compliant with ISO18013-5 for SessionData over BLE corresponding to Boxes C in Figure 8.10.

The figure illustrates the Session Data over BLE Presentation Flow in proximity. — Fig. 11.19 Session Data over BLE.¶

Step 1: The Wallet Instance sends the final APDU containing either the last block DeviceResponse (with requested attributes) or a status code, after which the session may end or continue with a new request.

11.2.2.5. `SessionEstablishment` over NFC¶

Note

If Device Engagement is initiated via a QR code, the Relying Party Instance has no standardised way to signal its intent to use NFC for subsequent data transfer. This could lead to a poor user experience, as the User might not be aware that they need to use NFC. This issue is avoided when NFC is used for the Device Engagement, as it implicitly establishes the data transfer method [ISO18013-5 #8.2.5].

Note

Due to the limited data transfer rate of NFC, if a large amount of data is required for a transaction, it may be neither practical nor reasonable for a User to keep the device within the RF range of the Relying Party Instance for the duration of the transaction. Furthermore, loss of signal when a device leaves the RF field necessitates re-initiating the transaction. This can only be avoided if all necessary User interactions with the Wallet Instance are performed while the device remains in the field, or if no User interaction is required during the active transmission phase [ISO18013-5 #8.2.5].

The following figure illustrates the low-level flow compliant with ISO18013-5 for SessionEstablishment over NFC corresponding to Box B in Figure 8.10.

The figure illustrates the Session Establishment over NFC Presentation Flow in proximity. — Fig. 11.20 Session Establishment over NFC.¶

11.2.2.5.1. Definitions (Acronyms and Commands)¶

Acronym/Command	Description
PICC	Proximity Integrated Circuit Card, implemented by Wallet Units acting as a NFC tag.
PCD	Proximity Coupling Device, impletented by Relying Party instances using APDU exchanges.
AID	Application Identifier, unique ID used in SELECT APDU command to engage the Wallet Instance.
APDU	Application Protocol Data Unit, a standard message format for communication between Relying Party Instance (PCD) and Wallet (PICC) consists of Command APDUs (e.g., SELECT, ENVELOPE, GET RESPONSE) from the reader and Response APDUs from the wallet, which include data exchange and end exchange using status words (SW1/SW2).
SELECT APDU	Command that opens the Wallet Instance by AID. Response includes File Control Information (FCI) and Status Word (SW1/SW2).
ENVELOPE APDU	Command that carries session messages (e.g., `SessionEstablishment`). Response indicates processing status (OK or more data).
GET RESPONSE APDU	Command that retrieves additional response data when the Wallet signals "more data" is available (SW1=61).
SW1/SW2	SW1/SW2 (Status Words) — Two-byte status code at the end of every response. Common values: 90 00 = success, 61 XX = more data, 6A 82 = file/application not found.

Step 1: The Relying Party Instance (PCD) sends a SELECT APDU command with the Application Identifier (AID: A0 00 00 02 48 04 00) to engage the Wallet Instance.

Step 2: The Wallet Instance (PICC) responds with File Control Information (FCI) and status words (SW1/SW2), either confirming success (90 00) or indicating that more data (61 XX) (WP_112e).

Step 3: The Relying Party Instance sends an ENVELOPE APDU carrying the SessionEstablishment message, which contains the encrypted DeviceRequest and its ephemeral public key for session setup.

Step 4: The Wallet Instance processes SessionEstablishment and returns an APDU response with SW1/SW2 (OK or more data to fetch), confirming the start of secure session context (WP_112f).

Step 5-6: [Optional] If the Wallet Instance receives the SessionEstablishment message during Negotiated Handover, the Wallet Instance MUST verify that it matches the data-retrieval SessionEstablishment message (Steps 3-4). In the event of a mismatch, the Wallet Instance MUST terminate the NFC connection [ISO18013-5 #9.2.3].

11.2.2.6. `SessionData` over NFC¶

The following figure illustrates the low-level flow compliant with ISO18013-5 for SessionData over NFC corresponding to Box C in Figure 8.10.

The figure illustrates the Session Data over NFC Presentation Flow in proximity. — Fig. 11.21 Session Data over NFC.¶

Step 1-2: As long as the Wallet Instance signals that more data is available (61 XX), the Relying Party Instance issues GET RESPONSE APDUs to request the next block. The Wallet Instance returns encrypted SessionData fragments until all data is delivered.

Step 3: The Wallet Instance sends the final APDU containing either the last block DeviceResponse (with requested attributes) or a status code, after which the session may end or continue with a new request.

11.2.2.7. Device Engagement¶

The Device Engagement structure MUST be CBOR encoded and have at least the following components (PPR-001, PPR-021, PPR-022, and WP_102):

Component	Description
Version	(tstr). Version of the Device Engagement structure.
Security	(array). Contains two mandatory values: (int). Cipher suite identifier. See Table 22 of ISO18013-5. (bstr). Public ephemeral key generated by the Wallet Instance, used by the Relying Party Instance to derive the Session Key. The key MUST be of a type allowed by the selected cipher suite (PPR-022).
DeviceRetrievalMode-BLEOptions	(map). Provides options for the BLE connection, such as Peripheral Server or Central Client mode, and the device UUID. See Table 2 of ISO18013-5 for the detailed mapping. If the Wallet Instance indicates during Device Engagement that it supports both modes, the Relying Party Instance SHOULD select the mdoc central client mode [ISO18013-5 #11.1.3.1]. Only present when performing Device Engagement using the QR code. Absent when using NFC to perform Device Engagement.
DeviceRetrievalMode-NFCOptions	(map). Provides options for NFC connections, including the supported role (PICC or PCD) and maximum PDU command/response sizes. See Table 2 of ISO18013-5 for the detailed mapping. In case NFC is used for Device Retrieval, the Wallet Instance MUST support PICC mode and the Relying Party Instance MUST support PCD mode [ISO18013-5 #11.2]. Only present when performing Device Engagement using the QR code. Absent when using NFC to perform Device Engagement.
Capabilities	(map). Declares optional capabilities supported by the mdoc, that are: HandoverSessionEstablishmentSupport (bool, OPTIONAL). If present, it MUST be set to true. It indicates support for receiving the SessionEstablishment message during Negotiated Handover, as defined in [ISO18013-5 #9.2.3] (PPR-024). ReaderAuthAllSupport (bool, OPTIONAL). If present, it MUST be set to true. It indicates support for receiving the optional ReaderAuthAll structure in the mdoc request, as defined in [ISO18013-5 #10.2.6]. It does not make `readerAuthAll` required and cannot replace per-DocRequest `readerAuth` (PPR-025).
OriginInfos	(array). Describes the interface used to receive and deliver the engagement structure. OriginInfos MAY be an empty array.

11.2.2.7.1. mdoc Request¶

The messages in the mdoc Request MUST be encoded using CBOR. The resulting CBOR byte string for the mdoc Request MUST be encrypted with the Session Key obtained after the Device Engagement phase. The resulting CBOR byte string for the mdoc Request MUST be transmitted using the BLE or NFC protocol (PPR-026, PPR-027, PPR-028).

Each mdoc Request MUST be compliant with the following structure, unless otherwise specified. Each mdoc Request MUST include the following components, unless otherwise specified.

Component	Description
version	(tstr). Version of the mdoc Request structure. Enables compatibility management across different versions or implementation profiles.
docRequests	(array). Each entry is a DocRequest containing: itemsRequest. CBOR-encoded ItemsRequest structure, formatted as: docType (tstr). The type of document requested. See mdoc-CBOR Credential Format. nameSpaces (map). A map of namespace identifiers to requested DataElements. Each entry in DataElements includes: DataElementIdentifier (tstr). The identifier of the requested data element. IntentToRetain (bool). Indicates whether the Relying Party intends to retain the value of the data element. requestInfo (map, REQUIRED and non-empty). Every ItemsRequest MUST contain `euWrprc` and `euWrpRegistrarInfo` as described below. euWrprc (bstr, REQUIRED). On the EUDIW path, the byte string contains the serialized `rc-wrp+cwt` WRPRC, which is authoritative for authorization (EUDIW Authorization). On the National path, it contains the UTF-8 bytes of the compact signed `registration-entity` Trust Mark JWT, which is authoritative for authorization (Authorization). The Wallet Instance MUST decode it solely according to the authenticated reader-certificate path, MUST reject the other artifact type, and MUST NOT use the embedded artifact to select or change the path. A failed path is handled as specified in Failure Handling. Registrar data MUST NOT replace or override this artifact. euWrpRegistrarInfo (map, REQUIRED). Mandatory Registrar transparency data. Its `identifier` (array, REQUIRED, non-empty) contains objects with `type` (tstr, REQUIRED) and `identifier` (tstr, REQUIRED). Its `srvDescription` and `purpose` (arrays, REQUIRED, non-empty) contain objects with `lang` (tstr, REQUIRED) and `content` (tstr, REQUIRED). `registryURI` (tstr, REQUIRED), `intendedUseIdentifier` (tstr, REQUIRED), and `policyURI` (tstr, REQUIRED) are mandatory. `credential` (array, OPTIONAL, non-empty when present) contains ETSI `Credential`/`Claim` objects. These fields are used with the selected path's validated authorization artifact for User Transparency. readerAuth (COSE_Sign1). Used to authenticate the Relying Party Instance for this DocRequest. The signature MUST be computed over ReaderAuthentication data using the private key corresponding to the selected path's reader certificate, as defined in [ISO18013-5 #12.5]. Its unprotected COSE header MUST contain `x5chain` label `33` with the end-entity certificate first and the certificate chain up to but excluding the Trust Anchor. The end-entity certificate is a WRPAC on the EUDIW path, validated according to EUDIW Authentication, and a Relying Party certificate on the National path, validated according to Federation Entity Authentication. This component MUST be present only if readerAuthAll is not used (PPR-025).
readerAuthAll	(COSE_Sign1). Used to authenticate the Relying Party once for all DocRequest`s. The signature is computed over `ReaderAuthenticationAll data, as defined in [ISO18013-5 #12.5]. This component MUST be present only if ReaderAuthAllSupport is set to true in the DeviceEngagement structure, and individual readerAuth fields are not used (PPR-025).

Component

Description

version

(tstr). Version of the mdoc Request structure. Enables compatibility management across different versions or implementation profiles.

docRequests

(array). Each entry is a DocRequest containing:

itemsRequest. CBOR-encoded ItemsRequest structure, formatted as:

docType (tstr). The type of document requested. See mdoc-CBOR Credential Format.

nameSpaces (map). A map of namespace identifiers to requested DataElements.

Each entry in DataElements includes:

DataElementIdentifier (tstr). The identifier of the requested data element.

IntentToRetain (bool). Indicates whether the Relying Party intends to retain the value of the data element.

requestInfo (map, REQUIRED and non-empty). Every ItemsRequest MUST contain euWrprc and euWrpRegistrarInfo as described below.

euWrprc (bstr, REQUIRED). On the EUDIW path, the byte string contains the serialized rc-wrp+cwt WRPRC, which is authoritative for authorization (EUDIW Authorization). On the National path, it contains the UTF-8 bytes of the compact signed registration-entity Trust Mark JWT, which is authoritative for authorization (Authorization). The Wallet Instance MUST decode it solely according to the authenticated reader-certificate path, MUST reject the other artifact type, and MUST NOT use the embedded artifact to select or change the path. A failed path is handled as specified in Failure Handling. Registrar data MUST NOT replace or override this artifact.

euWrpRegistrarInfo (map, REQUIRED). Mandatory Registrar transparency data. Its identifier (array, REQUIRED, non-empty) contains objects with type (tstr, REQUIRED) and identifier (tstr, REQUIRED). Its srvDescription and purpose (arrays, REQUIRED, non-empty) contain objects with lang (tstr, REQUIRED) and content (tstr, REQUIRED). registryURI (tstr, REQUIRED), intendedUseIdentifier (tstr, REQUIRED), and policyURI (tstr, REQUIRED) are mandatory. credential (array, OPTIONAL, non-empty when present) contains ETSI Credential/Claim objects. These fields are used with the selected path's validated authorization artifact for User Transparency.

readerAuth (COSE_Sign1). Used to authenticate the Relying Party Instance for this DocRequest. The signature MUST be computed over ReaderAuthentication data using the private key corresponding to the selected path's reader certificate, as defined in [ISO18013-5 #12.5]. Its unprotected COSE header MUST contain x5chain label 33 with the end-entity certificate first and the certificate chain up to but excluding the Trust Anchor. The end-entity certificate is a WRPAC on the EUDIW path, validated according to EUDIW Authentication, and a Relying Party certificate on the National path, validated according to Federation Entity Authentication.

This component MUST be present only if readerAuthAll is not used (PPR-025).

readerAuthAll

(COSE_Sign1). Used to authenticate the Relying Party once for all DocRequest`s. The signature is computed over `ReaderAuthenticationAll data, as defined in [ISO18013-5 #12.5].

This component MUST be present only if ReaderAuthAllSupport is set to true in the DeviceEngagement structure, and individual readerAuth fields are not used (PPR-025).

11.2.2.7.2. mdoc Response¶

The messages in the mdoc Response MUST be encoded using CBOR. The messages in the mdoc Response MUST be encrypted with the Session Key obtained after the Device Engagement phase (PPR-029, PPR-030).

Each mdoc Response MUST be compliant with the following structure, unless otherwise specified. Each mdoc Response MUST include the following components, unless otherwise specified.

Component	Description
version	(tstr). Version of the mdoc Response structure. Enables tracking changes and maintaining compatibility across versions of the standard or implementation profiles.
documents	(array of Documents, OPTIONAL). CBOR-encoded collection of documents returned in response to the request. Each document includes issuerSigned and deviceSigned components, and follows the structure defined in [ISO18013-5 #10.3.3].
documentErrors	(map, OPTIONAL). A map of error codes for unreturned documents, as defined in [ISO18013-5 #10.3.6]. Each key is a docType, and each value is an ErrorCode (int) indicating the reason why the document was not returned.
status	(uint). Status code indicating the outcome of the request. For example, "status": 0 means successful processing. For details, see Table 3 (ResponseStatus) of [ISO18013-5 #10.3.5].

Each document in documents MUST be compliant with the following structure, unless otherwise specified. Each document in documents MUST include the following components, unless otherwise specified (PPR-029):

Component	Description
docType	(tstr). Document type identifier. For example, for an mDL, the value MUST be `org.iso.18013.5.1.mDL`.
issuerSigned	(map). Contains `nameSpaces` with the issuer-signed data elements and `issuerAuth` with the issuer authentication structure using the Mobile Security Object (MSO). Every disclosed issuer-signed attribute MUST be placed here. See mdoc-CBOR Credential Format.
deviceSigned	(map). Contains the `nameSpaces` `DeviceNameSpaces` structure and the `deviceAuth` structure. It MAY contain attributes only when the Provider explicitly authorized those attributes to be device-signed. See the table below for details.
errors	(map, OPTIONAL). A map of error codes for each unreturned data element grouped by namespace. A `Document` without `errors` is an ISO/mdoc EAAP success. An error-bearing `Document` is not a successful EAAP. See [ISO18013-5 #10.3.6] for details on the errors structure.

A deviceSigned data structure MUST be compliant with the following structure (WP_111a). A deviceSigned data structure MUST include the following components.

Component	Description
nameSpaces	(bstr). Contains the DeviceNameSpaces structure. It MAY be an empty structure. DeviceNameSpaces maps namespace identifiers to a set of data elements signed by the Wallet Instance. Each namespace contains one or more DeviceSignedItem, where each item includes: DataItemName (tstr). The identifier of the data element. DataItemValue (any). The value of the data element.
deviceAuth	(map). Contains the DeviceAuth structure, which MUST include the deviceSignature (COSE_Sign1) for the Wallet Instance authentication. The signature is computed over the DeviceAuthentication data, which binds the returned elements to the session and the request. See [ISO18013-5 #12.4] for details on the authentication structure.

Component

Description

nameSpaces

(bstr). Contains the DeviceNameSpaces structure. It MAY be an empty structure. DeviceNameSpaces maps namespace identifiers to a set of data elements signed by the Wallet Instance.

Each namespace contains one or more DeviceSignedItem, where each item includes:

DataItemName (tstr). The identifier of the data element.
DataItemValue (any). The value of the data element.

deviceAuth

(map). Contains the DeviceAuth structure, which MUST include the deviceSignature (COSE_Sign1) for the Wallet Instance authentication. The signature is computed over the DeviceAuthentication data, which binds the returned elements to the session and the request. See [ISO18013-5 #12.4] for details on the authentication structure.

11.2.2.7.3. Session Termination¶

The session MUST be terminated if at least one of the following conditions occurs (PPR-007 and WP_113–113a).

After a time-out of no activity of receiving or sending session establishment or session data messages occurs. The time-out for no activity implemented by the Wallet Instance and the Relying Party Instance SHOULD be no less than 300 seconds.
When the Wallet Instance does not accept any more requests.
When the Relying Party Instance does not send any further requests.

If the Wallet Instance and the Relying Party Instance do not send or receive any further requests, the session termination MUST be initiated in one of the following ways (PPR-007 and WP_113).

The Wallet Instance or the Relying Party Instance sends the status code for session termination.
The Wallet Instance or the Relying Party Instance dispatches the "End" command as outlined in [ISO18013-5 #11.1.3.3].

When a session is terminated, the Wallet Instance and the Relying Party Instance MUST perform at least the following actions (WP_114):

Destruction of session keys and related ephemeral key material.
Closure of the communication channel used for data retrieval.

Note

See mdoc-CBOR Credential Format for the meaning of CBOR type acronyms.

11.2.2. Proximity Flow¶

11.2.2.1. DeviceEngagement over QR Code¶

11.2.2.1.1. Non-Normative Example with BLE as Data Retrieval¶

11.2.2.1.2. Non-Normative Example with NFC as Data Retrieval¶

11.2.2.2. DeviceEngagement over NFC¶

11.2.2.2.1. Non-Normative Example¶

11.2.2.3. SessionEstablishment over BLE¶

11.2.2.4. SessionData over BLE¶

11.2.2.5. SessionEstablishment over NFC¶

11.2.2.5.1. Definitions (Acronyms and Commands)¶

11.2.2.6. SessionData over NFC¶

11.2.2.7. Device Engagement¶

11.2.2.7.1. mdoc Request¶

11.2.2.7.2. mdoc Response¶

11.2.2.7.3. Session Termination¶

11.2.2.1. `DeviceEngagement` over QR Code¶

11.2.2.2. `DeviceEngagement` over NFC¶

11.2.2.3. `SessionEstablishment` over BLE¶

11.2.2.4. `SessionData` over BLE¶

11.2.2.5. `SessionEstablishment` over NFC¶

11.2.2.6. `SessionData` over NFC¶