8.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.

8.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.

8.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. 8.7 eID Substantial Authentication with MRTD Verification System Architecture.

8.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. 8.8 eID Substantial Authentication with MRTD Verification High-Level Flow.

8.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.

8.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. 8.9 eID Substantial Authentication with MRTD Verification Detailed Flow.

8.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.

8.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…

request=eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJodHRwczovL3dhbGxldC5leGFtcGxlLm9yZy9pbnN0YW5jZS8xMjM0NSIsImF1ZCI6Imh0dHBzOi8vcGlkLXByb3ZpZGVyLmV4YW1wbGUub3JnIiwibmJmIjoxNzUzNTU1NDAwLCJleHAiOjE3NTM1NTU3MDAsImlhdCI6MTc1MzU1NTQwMCwianRpIjoiYWFjNDVkZGMtY2ZiOC00OTNlLWI2NmItZTQ5ZDY4ZDVhNzVhIiwiY2xpZW50X2lkIjoiaHR0cHM6Ly93YWxsZXQuZXhhbXBsZS5vcmcvaW5zdGFuY2UvMTIzNDUiLCJyZXNwb25zZV90eXBlIjoiY29kZSIsInJlc3BvbnNlX21vZGUiOiJxdWVyeSIsInJlZGlyZWN0X3VyaSI6Imh0dHBzOi8vd2FsbGV0LmV4YW1wbGUub3JnL2NhbGxiYWNrIiwic3RhdGUiOiJhMWIyYzNkNGU1ZjY3ODkwIiwiY29kZV9jaGFsbGVuZ2UiOiJxampqUDdmaC1FdEFWcjJMWGU2ZzZwZi1LYVRGeDl6WmhIVGFHN3VIYnBvIiwiY29kZV9jaGFsbGVuZ2VfbWV0aG9kIjoiUzI1NiIsImF1dGhvcml6YXRpb25fZGV0YWlscyI6W3sidHlwZSI6Im9wZW5pZF9jcmVkZW50aWFsIiwiY3JlZGVudGlhbF9jb25maWd1cmF0aW9uX2lkIjoiZGNfc2Rfand0X1BJRF9hbHQyIiwiY3JlZGVudGlhbF9kZWZpbml0aW9uIjp7InR5cGUiOlsiVmVyaWZpYWJsZUNyZWRlbnRpYWwiLCJQZXJzb25JZGVudGlmaWNhdGlvbkRhdGEiXSwiY3JlZGVudGlhbFN1YmplY3QiOnt9fX0seyJ0eXBlIjoiaXRfbDIrZG9jdW1lbnRfcHJvb2YiLCJpZHBoaW50aW5nIjoiaHR0cHM6Ly9pZHAuZXhhbXBsZS5vcmciLCJjaGFsbGVuZ2VfbWV0aG9kIjoibXJ0ZCtpYXMiLCJjaGFsbGVuZ2VfcmVkaXJlY3RfdXJpIjoiaHR0cHM6Ly93YWxsZXQuZXhhbXBsZS5vcmcvbDJwbHVzLWNhbGxiYWNrIn1dfQ.signature

8.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.

8.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.

8.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 8.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 8.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.

The Wallet Instance MUST:

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

• 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.

8.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 8.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.

8.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/json as content type. The payload of the JSON response contains the parameters included in the following table:

Table 8.4 MRTD PoP Response Parameters

Parameter	Type	Description
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.

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

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

{
  "mrtd_pop_nonce":"9f2c4a7e3b1d8c9a6e5f4b2a1c3d7e8f",
  "mrz":"...",
  "challenge":"..."
}

The MRTD PoP Service MUST:

• Generate cryptographically secure challenge data for MRTD+IAS validation 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.

• 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.

8.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 8.5 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.

8.1.3.5.3.5. Validation JWT Structure

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

Table 8.6 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 8.7 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.

8.1.3.5.3.6. MRTD Object Structure

The mrtd object contains the following fields:

Table 8.8 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.

8.1.3.5.3.7. IAS Object Structure

The ias object contains the following fields:

Table 8.9 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 and structure.

• Validate document authenticity using ICAO 9303 standards.

• Verify Anti-Cloning challenge response.

• 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.

8.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 8.10 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"
}

8.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 as a query parameter:

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

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

8.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.

8.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.

8.1.3.6.1. MRTD PoP Response Errors

Table 8.11 MRTD PoP Response Error Codes

Error Code	Description
temporarily_unavailable	Document validation service or CIE Registry service is temporarily unavailable.

8.1.3.6.2. MRTD PoP Validation Response Errors

Table 8.12 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.

8.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.

• 503 Service Unavailable: For temporarily_unavailable errors.

8.1.3.7. Security Considerations

8.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.

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

8.1.3.7.2. Cryptographic Challenge Generation

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

8.1.3.7.3. Nonce Lifecycle Management

Each step in the eID Substantial Authentication with MRTD Verification flow MUST use unique nonce values 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.

8.1.3.7.4. Security Controls

The following security controls MUST be implemented in the protocol:

Table 8.13 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

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.

8.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.