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:
OAuth Authorization Request: PAR and authorization request with eID Substantial Authentication with MRTD Verification.
Primary Authentication: LoA3 electronic identification (SPID/CIEid L2).
MRTD Proof of Possession (PoP) Validation: Electronic document reading and cryptographic verification (Proof of Possession, integrity, and authenticity checks).
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.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:
Parameter |
Type |
Description |
|---|---|---|
alg |
string |
REQUIRED. Signature algorithm. |
typ |
string |
REQUIRED. It MUST be |
kid |
string |
REQUIRED. Identifier of the PID Provider's key that MUST be used to verify the signature of this JWT. |
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 |
type |
string |
REQUIRED. Type of the required interaction. It MUST be set to |
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 |
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
audclaim matches itsclient_id.Verify
iatandexpclaims indicate the token has a correct issuance date and has not expired.Verify that the
statusfield 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:
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
audclaim matches itsclient_id.Ensure the JWT
expclaim indicates the token has not expired.Extract the
mrtd_auth_sessionandmrtd_pop_jwt_noncevalues 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_sessionparameter matches an active session.Validate the
mrtd_pop_jwt_nonceparameter 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:
Parameter |
Type |
Description |
|---|---|---|
alg |
string |
REQUIRED. Signature algorithm. |
typ |
string |
REQUIRED. It MUST be |
kid |
string |
REQUIRED. Identifier of the PID Provider's key that MUST be used to verify the signature of this JWT. |
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_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 |
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_noncefor the next step to prevent replay attacks.Validate session continuity by ensuring the
mrtd_auth_sessionparameter 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_noncevalue 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.
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.
Header Parameter |
Type |
Description |
|---|---|---|
alg |
string |
REQUIRED. Signature algorithm. |
typ |
string |
REQUIRED. It MUST be |
kid |
string |
REQUIRED. Identifier of the Wallet Instance's key that MUST be used to verify the signature of this JWT. |
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 |
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:
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:
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_sessionandmrtd_pop_noncefrom the init response.Sign the
mrtd_validation_jwtwith 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_sessionparameter matches an active session.Verify the
mrtd_pop_noncematches the value sent in the previous response.Parse and validate the
mrtd_validation_jwtsignature (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:
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_noncefor 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_nonceandredirect_urito 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_noncematches the value sent in the verification response, and that it is signed using the Wallet Instance’s private key.Verify the
mrtd_auth_sessionparameter 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.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¶
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¶
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_requesterrors.401 Unauthorized: For
invalid_clienterrors.403 Forbidden: For
access_deniederrors.422 Unprocessable Entity: For
invalid_documentorid_matching_failederrors.503 Service Unavailable: For
temporarily_unavailableerrors.
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_nonceMUST be correlated with the MRTD Proof JWT.mrtd_pop_nonceMUST:Be cryptographically independent from
mrtd_pop_jwt_nonce.Incorporate the
mrtd_pop_jwt_nonceas input to maintain the chain of trust.Use a different entropy source to prevent correlation attacks.
mrtd_val_pop_nonceMUST:
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:
# |
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 |
Phase 3 |
SC8 |
The PID Provider checks that the |
Phase 3 |
SC9 |
The PID Provider checks that the |
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 |
Phase 3 |
SC12 |
The MRTD PoP Service verifies that challenge_signed contained in |
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.