12.1.3. eID Substantial Authentication with MRTD Verification for PID Issuance

This Section defines an eID Substantial Authentication with MRTD Verification protocol that integrates within the PID issuance flow as defined in the Section Credential Issuance Low-Level Flows extending OAuth 2.0 flows to include:

• Electronic identification with Level of Assurance "Substantial" (LoA3).

• Electronic document verification as an additional identity verification layer.

• Session correlation and security binding between authentication steps.

• Integration with Credential issuance flows.

While CIEid with LoA High authentication remains the primary method for Wallet activation and PID issuance, the eID Substantial Authentication with MRTD Verification mechanism defined in this Section provides an alternative approach to enhance service accessibility and usability, without compromising the overall security of the IT-Wallet ecosystem.

Note

This Section currently only supports the CIE id card for the MRTD verification protocol, the protocol described in this Section MAY be extended to support other MRTD Documents such as Electronic Passports.

12.1.3.1. Design Principles

The protocol adheres to the following design principles:

• Standard Compatibility: Extends existing authorization frameworks without breaking changes to the standard OAuth 2.0 Authorization Framework.

• Multi-Step Authentication: Implement progressive enforcement of authentication with MRTD verification.

• Session Integrity: Maintains secure session correlation across authentication steps.

• Unified Flow: Integrates multiple authentication factors in a single authorization session.

12.1.3.2. System Architecture

The system architecture comprises the following main components:

• Wallet Instance: It handles the PID request according to IT-Wallet Specification, supporting additional cryptographic capabilities for MRTD/IAS Electronic Document reading according to ICAO 9303 and BSI-03110 specifications.

• eID Substantial Authentication with MRTD Verification System: Orchestrates the authentication flow, integrating LoA3 Identity Providers, Electronic Document Verification Service, and performing all the identity correlation checks to guarantee that the User requesting a PID mathes with the authenticated one.

  • PID Authorization Server: Handles the authorization flow for PID Issuance, coordinating the User authentication and the remote identity proofing.

  • MRTD PoP Service: Handles electronic document proof of possession with cryptographic document validation.

• LoA3 Identity Provider: Provides Electronic Identification Schemes with eIDAS LoA3 compliance (CIEid and SPID).

• CIE National Registry: Provides privacy-preserved evidence of the binding between NIS and User's Tax payer's identification number required for the MRTD verification and, optionally, the MRZ data (document number, date of birth, expiry date, citizenship and gender) to improve the User experience. It also provides information related to the validity status of the document. It acts as the authoritative source for the CIE.

Fig. 12.7 eID Substantial Authentication with MRTD Verification System Architecture.

12.1.3.3. High-Level Flow

The protocol consists of the following sequential phases:

1. OAuth Authorization Request: PAR and authorization request with eID Substantial Authentication with MRTD Verification.

2. Primary Authentication: LoA3 electronic identification (SPID/CIEid L2).

3. MRTD Proof of Possession (PoP) Validation: Electronic document reading and cryptographic verification (Proof of Possession, integrity, and authenticity checks).

4. OAuth Authorization Response: Final authorization code issuance.

Fig. 12.8 eID Substantial Authentication with MRTD Verification High-Level Flow.

12.1.3.4. Session Management

The Authorization Server MUST maintain a unified session across all authentication steps, ensuring:

• Session Continuity: Single session identifier throughout the authentication flow.

• State Correlation: Authentication results from each step are correlated.

• Security Binding: Binding between authentication steps.

Since the PID Authorization Server and the MRTD PoP Service operate within the PID Provider boundary implementation, it is RECOMMENDED that the OAuth 2.0 session and the nonces used within the protocol flow are properly handled by both components seamlessly.

When both services operate within the same trust boundary, the following mechanisms are available for session correlation:

• Direct memory access to shared session stores.

• Internal service-to-service authentication using pre-shared keys.

• Synchronized nonce validation without external communication overhead.

• Unified audit logging and security event correlation.

When the PID Authorization Server or MRTD PoP Service is deployed outside the PID Provider boundary implementation, the Security Considerations MUST be taken into account to harden the User authentication sessions management. These measures include but are not limited to secure session token handling, distributed session validation, and enhanced audit trail mechanisms.

12.1.3.5. Low-Level Flow

This section provides technical details about the PID Issuance using Level of Assurance Substantial and remote identity proofing through verification of the electronic document using a MRTD Verification service.

Fig. 12.9 eID Substantial Authentication with MRTD Verification Detailed Flow.

12.1.3.5.1. Phase 1: OAuth Authorization Request

The Wallet Instance initiates the eID Substantial Authentication with MRTD Verification flow by submitting a Pushed Authorization Request (PAR), using a JWT-secured Authorization Request (JAR) and Rich Authorization Requests (RAR) as specified below.

12.1.3.5.1.1. Authorization Details

The JWT Request Object MUST contain the same parameters as defined in Pushed Authorization Request Endpoint. When the User requests a PID using eID Substantial Authentication with MRTD Verification, the Wallet Instance MUST include an additional Authorization Details Object in the authorization_details parameter, with the structure and claims as defined in the Table of the JWT Request parameters of Section Pushed Authorization Request Endpoint

Below a non-normative example of PAR:

POST /as/par HTTP/1.1
Host: pid-provider.example.org
Content-Type: application/x-www-form-urlencoded
OAuth-Client-Attestation: eyJhbGciOiJFUzI1NiIsImtp…
OAuth-Client-Attestation-PoP: eyJhbGciOiJFUz…

client_id=47b982369791d08003a7283f059cb0d1&
request=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJqdGkiOiJmODU1NWNlYi1jNjVjLTQwMjUtOTM3OC1iNjY3MmI2MTQ5YWYiLCJhdWQiOiJodHRwczovL3BpZC1wcm92aWRlci5leGFtcGxlLm9yZyIsImlhdCI6MTcxNTg0MjU2MCwiZXhwIjoxNzE1ODQyODYwLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlc3BvbnNlX21vZGUiOiJmb3JtX3Bvc3Quand0IiwiY2xpZW50X2lkIjoiNDdiOTgyMzY5NzkxZDA4MDAzYTcyODNmMDU5Y2IwZDEiLCJpc3MiOiI0N2I5ODIzNjk3OTFkMDgwMDNhNzI4M2YwNTljYjBkMSIsInN0YXRlIjoiZnlaaU9MOUxmMkNlS3VOVDJKenhpTFJEaW5rMHVQY2QiLCJjb2RlX2NoYWxsZW5nZSI6IkU5TWVsaG9hMk93dkZyRU1USmd1Q0hhb2VLMXQ4VVJXYnVHSlNzdHctY00iLCJjb2RlX2NoYWxsZW5nZV9tZXRob2QiOiJTMjU2Iiwic2NvcGUiOiJwaWQiLCJhdXRob3JpemF0aW9uX2RldGFpbHMiOlt7InR5cGUiOiJvcGVuaWRfY3JlZGVudGlhbCIsImNyZWRlbnRpYWxfY29uZmlndXJhdGlvbl9pZCI6ImRjX3NkX2p3dF9waWQifSx7InR5cGUiOiJpdF9sMitkb2N1bWVudF9wcm9vZiIsIm11bHRpX3N0ZXBfbWV0aG9kIjoibXJ0ZCtpYXMiLCJpZHBoaW50aW5nIjoiaHR0cHM6Ly9pZHAuZXhhbXBsZS5vcmciLCJtdWx0aV9zdGVwX3JlZGlyZWN0X3VyaSI6Imh0dHBzOi8vc3RhcnQud2FsbGV0LmV4YW1wbGUub3JnL2NoYWxsZW5nZSJ9XSwicmVkaXJlY3RfdXJpIjoiaHR0cHM6Ly9zdGFydC53YWxsZXQuZXhhbXBsZS5vcmcifQ.AuthRequestSign456_NoKidJWTSignature-abc123def456ghi789jkl012mno345pqr678stu901vwx234yz567

12.1.3.5.2. Phase 2: Primary Authentication

Upon successful processing of the PAR, the Authorization Server redirects the User Agent to the configured LoA3 Identity Provider for primary authentication. The User completes the LoA3 authentication flow (SPID or CIEid Substantial) and the Authorization Server correlates the authenticated identity with the active OAuth session.

The PID Authorization Server MUST ensure that the mrtd_auth_session parameter is maintained throughout this phase for proper session correlation with subsequent authentication steps.

12.1.3.5.3. Phase 3: MRTD PoP Validation Flow

Following successful primary authentication, the Authorization Server initiates the electronic document proof of possession flow by providing the Wallet Instance with the necessary parameters for MRTD validation.

12.1.3.5.3.1. MRTD Proof JWT

The Authorization Server MUST provide a signed JWT containing the challenge requirements for document validation. The JWT structure is defined as follows:

Table 12.1 MRTD Proof JWT Header

Parameter	Type	Description
alg	string	REQUIRED. Signature algorithm.
typ	string	REQUIRED. It MUST be mrtd+ias+jwt.
kid	string	REQUIRED. Identifier of the PID Provider's key that MUST be used to verify the signature of this JWT.

Table 12.2 MRTD Proof JWT Payload

Parameter	Type	Description
iss	string	REQUIRED. PID Provider identifier.
aud	string	REQUIRED. Wallet Instance identifier.
iat	integer	REQUIRED. Issuance time (Unix timestamp).
exp	integer	REQUIRED. Expiration time (Unix timestamp).
status	string	REQUIRED. Challenge status. MUST be require_interaction.
type	string	REQUIRED. Type of the required interaction. It MUST be set to mrtd+ias.
mrtd_auth_session	string	REQUIRED. Session identifier.
state	string	REQUIRED. MUST be the same value as in the initial Request Object.
mrtd_pop_jwt_nonce	string	REQUIRED. Nonce value for replay protection. It MUST be obtained by the MRTD PoP Service that MUST have direct control over this value.
htu	string	REQUIRED. HTTP URI of the MRTD PoP initialization endpoint.
htm	string	REQUIRED. HTTP method for the MRTD PoP initialization request. MUST be POST.

A non-normative example is provided below:

HTTP/1.1 302 Found

The Authorization Server MUST:

• Generate a unique challenge identifier with sufficient entropy (minimum 128 bits) for cryptographic security.

• Create MRTD Proof JWT with proper header (alg, typ, kid) and payload parameters (as defined in the table above).

• Sign the MRTD Proof JWT using its private key with the cryptographic algorithm chosen. See Section Cryptographic Algorithms.

• Construct a secure redirect URL with proper encoding to the Wallet Instance universal link.

• Set the redirect timeout to prevent indefinite waiting and handle timeout scenarios

• Optionally request MRZ information directly from the CIE National Registry using the authenticated User's taxpayer identification number.

• Maintain session correlation between the LoA High result and the document proof challenge

The Wallet Instance MUST:

• Validate the JWT signature using the PID Provider's public key obtained through trust evaluation.

• Verify aud claim matches its client_id.

• Verify iat and exp claims indicate the token has a correct issuance date and has not expired.

• Verify that the status field is set to "require_interaction".

• Verify the authentication type matches the expected value mrtd+ias.

• Extract HTTP target URI (htu) and method (htm) for the next step.

• Handle JWT validation and network errors, and provide user feedback with appropriate retry mechanisms.

• Extract correlation parameters (mrtd_auth_session, state, mrtd_pop_jwt_nonce) for subsequent requests.

12.1.3.5.3.2. MRTD PoP Request

The Wallet Instance MUST send an HTTP POST Request to the MRTD PoP Service initialization endpoint with application/json as content type, including Wallet Attestation and Wallet Attestation JWT PoP in the header according to OAUTH-ATTESTATION-CLIENT-AUTH. The payload of the Request contains the following parameters:

Table 12.3 MRTD PoP Request Parameters

Parameter	Type	Description
mrtd_auth_session	string	REQUIRED. Session identifier for session binding.
mrtd_pop_jwt_nonce	string	REQUIRED. Nonce value obtained from the MRTD Proof JWT.

Below a non-normative example of an MRTD PoP Request:

POST /edoc-proof/init HTTP/1.1
Host: pid-provider.example.org
Content-Type: application/json
OAuth-Client-Attestation: eyJhbGciOiJFUzI1NiIsImtp…
OAuth-Client-Attestation-PoP: eyJhbGciOiJFUz…

{
  "mrtd_auth_session": "wxroVrBY2MCq4dDNGXACS",
  "mrtd_pop_jwt_nonce": "f42cccb7f1c8269f9d4aeefe339c6b13"
}

The Wallet Instance MUST:

• Validate the MRTD Proof JWT signature using the PID Provider's public key.

• Verify the JWT aud claim matches its client_id.

• Ensure the JWT exp claim indicates the token has not expired.

• Extract the mrtd_auth_session and mrtd_pop_jwt_nonce values for correlation.

• Include valid Wallet Attestation according to OAUTH-ATTESTATION-CLIENT-AUTH.

• Handle network errors and implement appropriate retry mechanisms.

The MRTD PoP Service MUST:

• Validate the Wallet Attestation according to OAUTH-ATTESTATION-CLIENT-AUTH.

• Verify the mrtd_auth_session parameter matches an active session.

• Validate the mrtd_pop_jwt_nonce parameter corresponds to the one issued at the previous step.

The MRTD PoP Service MAY request the MRZ information (document number, date of birth, expiry date, citizenship and gender) directly to the CIE National Registry using the Tax payer's identification number of the authenticated User. In this case, the MRTD PoP Service is able to check if the authenticated User owns a valid CIE and If this is not the case, it MUST send an HTTP Error Response with HTTP Error code access_denied.

12.1.3.5.3.3. MRTD PoP Response

If the HTTP Request is successfully processed, the MRTD PoP Service MUST send a HTTP Response with code 202 Accepted and application/jwt as content type. The JWT structure is defined as follows:

Table 12.4 MRTD PoP Response Parameters

Parameter	Type	Description
alg	string	REQUIRED. Signature algorithm.
typ	string	REQUIRED. It MUST be mrtd-ias-pop+jwt.
kid	string	REQUIRED. Identifier of the PID Provider's key that MUST be used to verify the signature of this JWT.

Table 12.5 MRTD PoP Response Parameters

Parameter	Type	Description
iss	string	REQUIRED. PID Provider identifier.
aud	string	REQUIRED. Wallet Instance identifier.
iat	integer	REQUIRED. Issuance time (Unix timestamp).
exp	integer	REQUIRED. Expiration time (Unix timestamp).
challenge	string	REQUIRED. Challenge data for cryptographic document validation. It SHOULD be the SHA-256 hash value of a random value with the mrtd_auth_session and timestamp for cryptographic binding.
mrtd_pop_nonce	string	REQUIRED. Unique nonce value for the next step, preventing replay attacks.
mrz	string	OPTIONAL. Machine Readable Zone information including document number, date of birth, expiry date, citizenship and gender.
htu	string	REQUIRED. HTTP URI of the MRTD PoP validation endpoint.
htm	string	REQUIRED. HTTP method for the MRTD PoP validation request. MUST be POST.

Below a non-normative example of an MRTD PoP Response:

HTTP/1.1 202 Accepted
Content-Type: application/jwt; charset=utf-8
{
  "alg":"ES256",
  "typ":"mrtd-ias-pop+jwt",
  "kid":"b3f1a6c2e9d54a8f9c3e7d1a2f4b6c78"
}
.
{
  "iss":"https://pid-provider.example.org",
  "aud":"https://wallet.example.org/instance/12345",
  "iat": 1753555800,
  "exp": 1753556000,
  "mrtd_pop_nonce":"9f2c4a7e3b1d8c9a6e5f4b2a1c3d7e8f",
  "mrz":"...",
  "challenge":"...",
  "htu":"...",
  "htm":"..."
}

The MRTD PoP Service MUST:

• Generate cryptographically secure challenge data with sufficient entropy (to be used in Anti-Cloning Internal Authentication protocol by the Wallet Instance), storing it with an appropriate expiration time. Moreover, the MRTD PoP Service MUST ensure challenge uniqueness to prevent reuse attacks.

• Create a new unique mrtd_pop_nonce for the next step to prevent replay attacks.

• Validate session continuity by ensuring the mrtd_auth_session parameter corresponds to an active session.

• Return HTTP 202 Accepted status to indicate asynchronous processing initiation.

• Include proper Content-Type header (application/json; charset=utf-8).

• Handle service errors and return appropriate error responses.

• Extract and validate MRZ information if provided from external registry services.

The Wallet Instance MUST:

• Validate HTTP response status (202 Accepted) and content type.

• Parse JSON response and validate required parameters (challenge, mrtd_pop_nonce).

• Extract challenge data for cryptographic document validation.

• Store new mrtd_pop_nonce value securely for subsequent validation requests.

• Validate optional MRZ information if present in the response.

• Extract HTTP target URI (htu) and method (htm) for the next step.

• Handle errors, providing relative user feedback.

• Store challenge data temporarily.

• Prepare NFC reading session.

The Wallet Instance performs NFC-based electronic document reading and validation, then submits the evidence to the PID Provider for final verification and identity correlation with the LoA3 authentication result.

12.1.3.5.3.4. MRTD PoP Validation Request

Upon all the evidence has been collected through NFC interaction with the Electronic Document, the Wallet Instance MUST send all data to the PID Provider Authorization Server for the final validation and identity cross checks. The Wallet Instance MUST send a HTTP POST Request with application/json as content type, including Wallet Attestation and Wallet Attestation JWT PoP in the header according to OAUTH-ATTESTATION-CLIENT-AUTH. The payload of the Request contains the following parameters.

Table 12.6 MRTD PoP Validation Request Parameters

Parameter	Type	Description
mrtd_validation_jwt	string	REQUIRED. JWT containing document evidence, cryptographic proofs, Data Groups (DGs), and validation results.
mrtd_auth_session	string	REQUIRED. Session identifier for session binding.
mrtd_pop_nonce	string	REQUIRED. MUST match the value obtained from the MRTD PoP Response.

12.1.3.5.3.5. Validation JWT Structure

The Validation JWT (mrtd_validation_jwt) structure is given in the following table.

Table 12.7 Validation JWT Header Parameters

Header Parameter	Type	Description
alg	string	REQUIRED. Signature algorithm.
typ	string	REQUIRED. It MUST be mrtd+ias+jwt.
kid	string	REQUIRED. Identifier of the Wallet Instance's key that MUST be used to verify the signature of this JWT.

Table 12.8 Validation JWT Payload Parameters

Payload Parameter	Type	Description
iss	string	REQUIRED. Wallet Instance identifier.
aud	string	REQUIRED. PID Provider identifier.
iat	integer	REQUIRED. Issuance time (Unix timestamp).
exp	integer	REQUIRED. Expiration time (Unix timestamp).
document_type	string	REQUIRED. Type of document validated. MUST be set to cie.
mrtd	JSON Object	REQUIRED. MRTD validation data containing Data Groups and SOD.
ias	JSON Object	REQUIRED. IAS validation data containing NIS, Anti-Cloning Public Key, and SOD.

12.1.3.5.3.6. MRTD Object Structure

The mrtd object contains the following fields:

Table 12.9 MRTD Object Structure

Field	Type	Description
dg1	string	REQUIRED. Base64-encoded Data Group 1 (MRZ information:document number, date of birth, expiry date, citizenship and gender).
dg11	string	REQUIRED. Base64-encoded Data Group 11 (additional personal data).
sod_mrtd	string	REQUIRED. Base64-encoded Security Object of Document for MRTD.

12.1.3.5.3.7. IAS Object Structure

The ias object contains the following fields:

Table 12.10 IAS Object Structure

Field	Type	Description
nis	string	REQUIRED. NIS (Service Identification Number) value.
ias_pk	string	REQUIRED. Base64-encoded IAS public key in DER format.
sod_ias	string	REQUIRED. Base64-encoded Security Object of Document for IAS.
challenge_signed	string	REQUIRED. Base64-encoded signed challenge response.

Below a non-normative example of an MRTD PoP Validation Request:

POST /edoc-proof/verify HTTP/1.1
Host: pid-provider.example.org
Content-Type: application/json
OAuth-Client-Attestation: eyJhbGciOiJFUzI1NiIsImtp…
OAuth-Client-Attestation-PoP: eyJhbGciOiJFUz…

{
  "mrtd_validation_jwt":"eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3dhbGxldC5leGFtcGxlLm9yZy9pbnN0YW5jZS8xMjM0NSIsImF1ZCI6Imh0dHBzOi8vcGlkLXByb3ZpZGVyLmV4YW1wbGUub3JnIiwiaWF0IjoxNzUzNTU1NDAwLCJleHAiOjE3NTM1NTU3MDAsImRvY3VtZW50X3R5cGUiOiJjaWUiLCJtcnRkIjp7ImRnMSI6IlVEeEpWRUU4VTAxSlZFZzhQRXBQU0U0OFBFcFBTRTRnVTAxSlZFZzhQREU1T0RBME1UVThUVDxQTnpjM056SXpNUT09IiwiZGcxMSI6Ik1USXpORFUyTnpnNVFVSkRSRVZHUjBoSlNrdE1UVTVQVUVGT1IxSlRWRlZXV0ZsYVUwRkVSVVU9Iiwic29kX21ydGQiOiJNSUlGempDQ0JMYWdBd0lCQWdJSVFPWTJLSkdGVFVJd0RRWUpLb1pJaHZjTkFRRUxCUUF3WHpFTE1Baz0ifSwiaWFzIjp7Im5pcyI6IklUMTIzNDU2Nzg5MDEyMzQiLCJpYXNfcGsiOiJNSUlCSWpBTkJna3Foa2lHOXcwQkFRRUZBQU9DQVE4QU1JSUJDZ0tDQVFFQXoxMjM0NTY3ODkwPSIsInNvZF9pYXMiOiJNSUlGYURDQ0JGQ2dBd0lCQWdJSkFMMktKR0ZUVUl3RFFZSktvWklodmNOQVFFTEJRQXdYekVMTUE9PSIsImNoYWxsZW5nZV9zaWduZWQiOiJhMWIyYzNkNGU1ZjY3ODkwMTIzNDU2Nzg5MDEyMzQ1Njc4OTBhYmNkZWYxMjM0NTY3ODkwYWJjZGVmPT0ifX0.xyz456abc789def012ghi345jkl678mno901pqr234stu567vwx890yz123",
  "mrtd_auth_session":"wxroVrBY2MCq4dDNGXACS",
  "mrtd_pop_nonce":"9f2c4a7e3b1d8c9a6e5f4b2a1c3d7e8f"
}

The Wallet Instance MUST:

• Perform ICAO 9303 compliant NFC document reading (PACE,etc.).

• Validate document cryptographic signatures and certificate chains.

• Extract identity attributes (DG1 and DG11), NIS, Anti-Cloning Public Key from document data groups, and SODs (form MRTD and IAS Applications).

• Perform the Anti-Cloning Internal Authentication.

• Generate validation evidence in the JWT.

• Authenticate using a valid Wallet Instance Attestation.

• Include the exact mrtd_auth_session and mrtd_pop_nonce from the init response.

• Sign the mrtd_validation_jwt with its private key.

• Handle document reading errors and provide appropriate feedback.

The MRTD PoP Service MUST:

• Validate Wallet Instance Attestation according to IT-Wallet specifications.

• Verify OAuth-Client-Attestation-PoP signature.

• Validate the mrtd_auth_session parameter matches an active session.

• Verify the mrtd_pop_nonce matches the value sent in the previous response.

• Parse and validate the mrtd_validation_jwt signature (using Wallet Instance's public key) and structure.

• Extract and verify document evidence from the mrtd_validation_jwt.

• Validate document authenticity using ICAO 9303 standards.

• Verify Anti-Cloning challenge response.

• Validate document cryptographic proofs and certificate chains.

• Perform identity correlation between document data and LoA3 result.

• Check document validity (non revocation status).

• Check the binding between NIS obtained from IAS Application and Tax payer's identification number of the User read from the MRTD Application in order to ensure that both values are coming from the same chip.

12.1.3.5.3.8. MRTD PoP Validation Response

Upon successful completion of all checks by the MRTD PoP Service, it MUST send to the Wallet Instance an HTTP Response with code 202 Accepted including the following parameters:

Table 12.11 MRTD PoP Validation Response Parameters

Parameter	Type	Description
status	string	REQUIRED. It MUST be require_interaction.
type	string	REQUIRED. It MUST be redirect_to_web.
mrtd_val_pop_nonce	string	REQUIRED. New nonce for final confirmation.
redirect_uri	string	REQUIRED. Browser redirect URI for completion of the Authorization Flow.

Below a non-normative example of an MRTD PoP Validation Response:

HTTP/1.1 202 Accepted
Content-Type: application/json; charset=utf-8

{
  "status": "require_interaction",
        "type": "redirect_to_web",
  "mrtd_val_pop_nonce": "0f2bff024317345b6927ce17e776361d",
  "redirect_uri":"https://pid-provider.example.org/cb"
}

The MRTD PoP Service MUST:

• Generate a new nonce mrtd_val_pop_nonce for browser-based final confirmation.

• Return HTTP 202 status to indicate async processing completion.

The Wallet Instance MUST:

• Validate the response.

• Extracts the parameters nonce mrtd_val_pop_nonce and redirect_uri to prepare the next browser-based GET Request.

12.1.3.5.3.9. Browser-based Final Confirmation

Upon successful MRTD PoP validation, the Wallet Instance MUST redirect the User Agent to the challenge_redirect_uri specified in the initial Authorization Details Object, including the mrtd_val_pop_nonce and mrtd_auth_session as a query parameter:

https://pid-provider.example.org/l2plus-callback?mrtd_val_pop_nonce=0f2bff024317345b6927ce17e776361d_signed&mrtd_auth_session=wxroVrBY2MCq4dDNGXACS

The Wallet Instance MUST validate that the mrtd_val_pop_nonce matches the value received from the MRTD PoP Validation Response.

The Authorization Server MUST:

• Validate the mrtd_val_pop_nonce matches the value sent in the verification response, and that it is signed using the Wallet Instance’s private key.

• Verify the mrtd_auth_session parameter matches an active session.

• Verify all authentication steps (LoA3 + MRTD PoP) have been completed successfully (including the identity correlation between LoA3 and document evidence).

• Generate the final authorization code.

12.1.3.5.4. Phase 4: OAuth Authorization Response

Upon successful completion of all authentication steps and identity matching, the Authorization Server MUST issue the final OAuth Authorization Response. If all validation checks have been passed, the Authorization Server MUST redirect the User Agent to the Wallet Instance with an OAuth Authorization Response including the authorization code as defined in steps 6-7 of Low-Level Issuance Flow, and in Section Authorization Response. The Authorization Server MUST use the redirect_uri included in the initial Request Object by the Wallet Instance.

12.1.3.6. Error Management

The error management MUST follow the same rules as defined in the Section Credential Issuance Endpoints, regarding the formats and the related standard references.

During the MRTD PoP Validation flow, when recoverable errors occur, the MRTD PoP Service MAY generate and return a fresh nonce to enable the User to retry attempts while maintaining session security and preventing replay attacks.

In addition to the error codes already defined in the Section Credential Issuance Endpoints, at least the following error codes MUST be supported.

12.1.3.6.1. MRTD PoP Response Errors

Table 12.12 MRTD PoP Response Error Codes

Error Code	Description
invalid_client	Wallet Instance authentication failed.
invalid_request	HTTP Request is invalid or malformed (malformed structure, missing data, etc.) or required session parameters are missing or invalid.
access_denied	User is not eligible for eID Substantial Authentication with MRTD Verification mechanism (e.g. CIE not found in the CIE Registry)
temporarily_unavailable	Document validation service or CIE Registry service is temporarily unavailable.

12.1.3.6.2. MRTD PoP Validation Response Errors

Table 12.13 MRTD PoP Validation Response Error Codes

Error Code	Description
invalid_client	Wallet Instance authentication failed.
invalid_request	HTTP Validation Request or Validation JWT is invalid or malformed (due to a malformed structure, missing data, signature failure, request timeout, etc.).
access_denied	User authentication or document validation failed.
invalid_document	Document cryptographic validation failed (SOD validation, NIS/CF binding, revocation status, etc.).
id_matching_failed	The matching between the identity obtained during primary authentication (eID LoA3) and the one obtained from the PoP of the Electronic Document failed.
temporarily_unavailable	Document validation service or CIE Registry service is temporarily unavailable.

12.1.3.6.3. HTTP Status Code Mapping

Error responses MUST use appropriate HTTP status codes:

• 400 Bad Request: For invalid_request errors.

• 401 Unauthorized: For invalid_client errors.

• 403 Forbidden: For access_denied errors.

• 422 Unprocessable Entity: For invalid_document or id_matching_failed errors.

• 503 Service Unavailable: For temporarily_unavailable errors.

12.1.3.7. Security Considerations

12.1.3.7.1. Secure Session Management

The mrtd_auth_session parameter serves as the primary correlation mechanism between authentication steps. Implementations MUST ensure this identifier has sufficient entropy (minimum 128 bits) and is cryptographically secure. The session identifier MUST be validated at each step to prevent session fixation attacks.

Each authentication step MUST be cryptographically bound to the OAuth session through signed JWT validation to prevent session fixation, session confusion, and identity substitution attacks. The Authorization Server MUST maintain the correlation between the LoA3 identity and the document proof within a single session context.

In particular, each authentication step MUST validate the correlation between:

• Session identifier consistency across all protocol phases.

• LoA3 identity attributes binding to the session context.

• Document evidence correlation with authenticated identity.

• Temporal sequence validation to prevent out-of-order attacks.

When components operate outside the PID Provider boundary, the following additional security measures MUST be implemented:

• Secure Inter-Service Communication (for example, through Certificate pinning, mutual TLS, etc.).

• Encryption and integrity of sensitive session data and/or personal identity information (for example, using JWE/JWS tokens).

• Distributed locks for session state updates.

Fig. 12.10 eID Substantial Authentication with MRTD Verification Security Controls.

12.1.3.7.2. Cryptographic Challenge Generation

The MRTD PoP Service MUST generate cryptographically secure challenges with sufficient entropy (minimum 256 bits) for document validation. Challenge values MUST be unique and MUST NOT be reused across different sessions (cryptographically bound to the specific OAuth session context) or authentication attempts. The challenge generation algorithm SHOULD incorporate the mrtd_auth_session identifier and timestamp to ensure proper cryptographic binding.

12.1.3.7.3. Nonce Lifecycle Management

Each step in the eID Substantial Authentication with MRTD Verification flow MUST use unique nonce values (minimum 128 bits) to prevent replay attacks. Nonce values MUST have appropriate expiration times and MUST be invalidated after successful use. The PID Authorization Server and MRTD PoP Service MUST maintain synchronized nonce validation to ensure session integrity.

Moreover, each nonce serves a specific security purpose.

• mrtd_pop_jwt_nonce MUST be correlated with the MRTD Proof JWT.

• mrtd_pop_nonce MUST:

• Be cryptographically independent from mrtd_pop_jwt_nonce.

• Incorporate the mrtd_pop_jwt_nonce as input to maintain the chain of trust.

• Use a different entropy source to prevent correlation attacks.

• mrtd_val_pop_nonce MUST:

• Be signed by the Wallet Instance private key.

• Include anti-replay timestamp validation.

• Be verified against the entire nonce chain for integrity.

12.1.3.7.4. Security Controls

The following security controls MUST be implemented in the protocol:

Table 12.14 eID Substantial Authentication with MRTD Verification Security Controls

#	Description	Phase
SC1	The network communication channels are protected by using TLS with secure ciphers (at the time of this release, it is at least TLS v1.2).	All
SC2	The Wallet Instance ensures the authenticity of the PID Provider and the eID Identity Provider by pinning the leaf certificate of each server.	All
SC3	The PID Authorization Server verifies that the eID Identity Provider used within the eID LoA3 phase is trustworthy.	Phase 2
SC4	The PID Authorization Server verifies the authenticity and integrity of the data extracted from the eID LoA3 assertion, by checking the digital signature.	Phase 2
SC5	The challenge value and all nonce values are generated with safeguards to prevent bruteforce or guessing attacks.	Phase 3
SC6	The PID Provider verifies all the nonce values to detect replay attacks.	Phase 3
SC7	The Wallet Instance verifies that challenge_info is properly signed by the PID Authorization Server. Moreover, it checks that challenge_info contains: an iss value corresponding to the value of the PID Authorization Server; an aud value equal to the client_id of the Wallet Instance; and a state value equal to the one in the PAR request, to be sure that the response is bound to the initial request that is made by the Wallet Instance in Step 2. Therefore the information provided as part of challenge_info, in particular the htu that corresponds to the redirect url to follow for the MRTD PoP, is not tampered with.	Phase 3
SC8	The PID Provider checks that the mrtd_auth_session is associated with the same Wallet Instance in all the requests within the MRTD PoP phase. Therefore the PID Provider can be sure that the Wallet Instance performing the MRTD PoP phase: is trusted; is always the same across the protocol; and has previously started the PID issuance (PAR request). This can be implemented by requesting the Wallet Instance to perform a proof of possession of its private key (e.g., within OAuth-Client-Attestation or by signing a nonce value).	Phase 3
SC9	The PID Provider checks that the mrtd_auth_session is not expired (validity timeout typically of 5 minutes), i.e., that the operation has been concluded within a certain amount of time.	Phase 3
SC10	The integrity and confidentiality of the channel between the physical CIE and the physical device_wallet is secured with the PACE protocol (via the algorithm and key derivation functions supported by the card).	Phase 3
SC11	The MRTD PoP Service verifies the authenticity and integrity of the mrtd_validation_jwt by checking that it is signed with the Wallet Instance private key associated with the mrtd_auth_session.	Phase 3
SC12	The MRTD PoP Service verifies that challenge_signed contained in mrtd_validation_jwt corresponds to the original challenge signed with the CIE AntiClone private key (SDO.Servizi_Int_Kpriv). This demonstrates the Wallet Instance and the CIE performed the Internal Authentication (in line with Sec. 5.2.3.5.1 in IAS ECC, but with randomness value RND.IFD provided by the MRTD PoP Service instead of generating it in the Wallet Instance).	Phase 3
SC13	The MRTD PoP Service verifies the authenticity of the data extracted from the CIE by checking the SOD elements (both IAS and MRTD) and the related signature certificate chains.	Phase 3
SC14	The MRTD PoP Service verifies the integrity of the data extracted from the CIE by checking the SOD elements (both IAS and MRTD) and the related hashes.	Phase 3
SC15	The PID Authorization Server verifies the existence and consistency of the User’s Tax payer's identification number extracted from the eID LoA3 assertion, by interacting with the Authoritative Source (AS_NIS).	Phase 3
SC16	The MRTD PoP Service verifies that the identity proven during the IAS interaction is correlated with the identity proven during the MRTD interaction, by interacting with the Authoritative Source (AS_NIS).	Phase 3
SC17	The MRTD PoP Service verifies that the identity proven during the eID LoA3 phase is correlated with the identity proven during the MRTD PoP phase.	Phase 3
SC18	The MRTD PoP Service verifies that the CIE used during the MRTD PoP phase has not expired and not revoked by interacting with the CIE National Registry.	Phase 3

Additional implementation requirements:

• Rate limiting: Protection against automated attacks and brute force attempts.

• Session timeout: Automatic cleanup of incomplete authentication sessions.

• Audit logging: Comprehensive logging of all authentication events with correlation identifiers.

• Error handling: Secure error responses that do not leak sensitive information.

• Cryptographic material cleanup: Secure deletion of temporary keys and challenges.

12.1.3.8. Implementation Considerations

Implementations SHOULD incorporate rate-limiting mechanisms to protect against automated attacks and resource exhaustion, and a timeout configuration balancing user experience and security posture, accommodating the variability inherent in NFC-based document reading.

PID Provider SHOULD implement session timeouts approach with proper cleanup mechanisms, ensuring session resources are released and temporary cryptographic material is securely deleted when sessions expire.

All security-relevant events throughout the eID Substantial Authentication with MRTD Verification flow MUST be logged with sufficient detail for auditing purposes while preserving the privacy of the User, ensuring that personally identifiable information, when stored, is appropriately hashed. The audit logs SHOULD have consistent correlation identifiers, enabling end-to-end tracing across all protocol phases, with cryptographic integrity protection to prevent tampering.