Skip to content

3.2.2 PID Presentation

This flow describes the PID presentation process as introduced here in the blueprint. The PID presentation flow uses the standards following the High-Assurance Interoperability Profile (HAIP) for OpenID4VP as defined in the blueprint:

The current flow allows both Wallets and Verifiers to only use same-device flows, as the cross-device using OpenID4VP redirect-based flows does not fulfil LoA high requirements. In future iterations, cross-device PID presentations may be supported.

Data Flow

This section describes the data flow of the PID presentation in a sequence diagram and a more detailed table. Artifacts in italics are further explained in the data register chapter.

Sequence Diagram

PID Presentation bluesequence numbers for steps detailed in other diagramssolid line arrows represent technical functionality, dotted line arrows represent non-technical/user functionalityUserUser Device BrowserRelying Party .RP.Wallet Instance App .WI.Remote WSCA .RWSCA.UserUserUser Device BrowserUser Device BrowserRelying Party (RP)Relying Party (RP)Wallet Instance App (WI)Wallet Instance App (WI)Remote WSCA (RWSCA)Remote WSCA (RWSCA)(001)browse Relying Parties website(002)[TLS] HTTP GET <rp-website>(003)generate rp_openid4vp_state , rp_key_binding_nonce and encryption keys(rp_response_enc_prvk, rp_response_enc_pubk)(004)create OpenID4VP Authorization Request rp_openid4vp_request:(rp_client_id, rp_openid4vp_state, rp_dcql_query, rp_key_binding_nonce,rp_response_enc_pubk, rp_access_cert, rp_registration_cert)(005)sign rp_openid4vp_request with rp_access_cert_priv(006)store rp_openid4vp_request for PAR under rp_request_uri(007)create rp_cookie_id and bind it to rp_openid4vp_request(008)[TLS] HTTP 200 <custom URL scheme linked rp_request_uri, Set-Cookie:rp_cookie_id>(009)initiate presentation of PID(010)launch WI with custom URL scheme openid4vp://(011)[TLS] HTTP GET <rp_request_uri>(012)[TLS] HTTP 200 <rp_openid4vp_request>(013)verify rp_openid4vp_request using rp_access_cert and rp_registration_cert(014)check if stored credentials match rp_dcql_query and whether batchpp_pid_credential is exhausted or expired(015)ask user for consent to present PID to Relying Party(016)enter user_rwsca_pin(017)optionally trigger PID re-issuance using pp_refresh_token if batchpp_pid_credential is exhausted or expired(018)apply selective disclosure to pp_pid_credential according to rp_dcql_query(019)generate wi_key_binding_data from rp_key_binding_nonce, rp_client_id andSD-JWT/mdoc-specific data(020)generate wi_key_binding_data_hash from wi_key_binding_data(021)[TLS] request Remote WSCA Start PIN Session operation(user_rwsca_pin)(022)verify two factor authentication(023)[TLS] respond Start PIN session operation rwsca_pin_session_token(024)[TLS] request Remote WSCA Sign operation (wi_key_binding_data_hash,rwsca_bound_wrapped_key)(025)sign(wi_key_binding_data_hash, rwscd_pid_device_prvk)(026)[TLS] respond Sign operation rwscd_key_binding_signature(027)assemble wi_pid_presentation from selectively disclosed pp_pid_credential,wi_key_binding_data and rwscd_key_binding_signature(028)generate encryption keys (wi_response_enc_prvk, wi_response_enc_pubk)(029)encrypt wi_pid_presentation using keys derived fromECDH(wi_response_enc_prvk, rp_response_enc_pubk)(030)create wi_openid4vp_response from wi_pid_presentation andrp_openid4vp_state(031)delete presented one-time-use pp_pid_credential and correspondingrwsca_bound_wrapped_key(032)[TLS] HTTP POST <Authorization Response (wi_openid4vp_response)>(033)match OpenID4VP session using rp_openid4vp_state and store encryptedwi_pid_presentation(034)create unique rp_redirect_uri and bind it to OpenID4VP session ofrp_openid4vp_state(035)[TLS] HTTP 200 <rp_redirect_uri>(036)launch browser with <rp_redirect_uri>(037)[TLS] HTTP GET <rp_redirect_uri>, Cookie: rp_cookie_id(038)verify that the provided rp_cookie_id matches to the session bound torp_redirect_uri(039)decrypt wi_pid_presentation using keys derived fromECDH(wi_response_enc_pubk, rp_response_enc_prvk)(040)verify wi_pid_presentation using pp_pid_auth_pubk andrwscd_pid_device_pubk(041)extract selectively disclosed es_eid_data(042)[TLS] HTTP 200 <continue with authenticated user>(043)check remaining number and expiry of batch pp_pid_credential, optionallytrigger PID re-issuance using pp_refresh_token and reuserwsca_pin_session_token

Detailed Description

No Description
001 The user browses to a Relying Party (RP) website using the browser on its Wallet Instance (WI).
002 The browser calls the Relying Party website, most likely using one or multiple HTTP GET requests. One of these requests triggers the Relying Party's server to generate the OpenID4VP Authorization Request as described in steps 003-008.
003 The RP generates random values for rp_openid4vp_state and rp_key_binding_nonce with sufficient entropy and an ephemeral response encryption key pair (rp_response_enc_prvk, rp_response_enc_pubk) used for additional application-level encryption with response mode direct_post.jwt.
004 - 005 The RP creates the OpenID4VP Authorization Request rp_openid4vp_request as a JWT-Secured Authorization Request (JAR) using RFC9101 including:
  • The rp_key_binding_nonce encoded as nonce that acts as a challenge for the key-binding of the PID presentation in step 019.
  • The rp_openid4vp_state encoded as state that is responded back by the Wallet to let the RP match the session in step 033.
  • The rp_response_enc_pubk encoded as client_metadata.jwks in the Authorization Request.
  • The rp_client_id encoded as client_id that acts as an identifier for the RP
  • The rp_access_cert encoded as x5c JOSE header that provides the access certificate of the RP provided by the Relying Party Registrar, which is also being used as the signing certificate.
  • The rp_registration_cert encoded as verifier_info that provides the registration certificate of the RP provided by the Relying Party Registrar.
  • The rp_dcql_query encoded as dcql_query that describes the credentials requested by the RP, i.e. the PID and its attributes
  • the response_mode is always direct_post.jwt
  • The rp_response_uri encoded as response_uri that provides the POST endpoint for the response
The RP then sign the Authorization Request rp_openid4vp_request with rp_access_cert_priv.
006 The RP stores rp_openid4vp_request as a Pushed Authorization Request according to RFC9126 under rp_request_uri.
007 The RP creates an HTTP session ID cookie rp_cookie_id and binds it to rp_openid4vp_request.
008 The RP returns the rp_request_uri and sets the rp_cookie_id (using Set-Cookie HTTP headers). The request is embedded into the HTML code of the website, likely as a button using either the WI's app link or a custom URL scheme such as haip-vp:// for wallet invocation.
009 - 010 The user initiates the PID presentation on the RP's website, likely by pushing a button. The WI is launched by the operating system, passing the rp_request_uri as a parameter within the app link/custom URL.
011 - 012 The WI requests the rp_request_uri as a Pushed Authorization Request using a HTTP GET call according to RFC9126. The RP responds with the rp_openid4vp_request as a Pushed Authorization Response that corresponds to the rp_request_uri.
013 The WI validates the fetched rp_openid4vp_request by:
  • verifying the JWS using the the rp_access_cert from the x5c header and matching the certificate chain to its internal Relying Party Registrar trust anchor
  • verifying the JWS of the rp_registration_cert and that it matches to the rp_access_cert
  • verifying that the intended use of the rp_access_cert matches the requested rp_dcql_query.
For details, please see Wallet-Relying Party Authentication in the blueprint.
014 The WI matches the available, stored credentials (i.e. the PID and optionally additional credentials) against the RP's requested credentials from rp_dcql_query. The following situations may appear:
  • the available credentials do not match the query and the WI has no information to get the requested credential(s) ad-hoc. The WI shows an error and aborts the flow.
  • the available credentials do not match the query but the WI has information how to get the requested credential(s) ad-hoc, e.g. through PID issuance or other EAAs from the Credential Catalogue. The WI halts the flow and offers the user to issue the missing credential(s).
  • the available credentials have exactly 1 match with the query. The WI continues for the user's consent
  • the available credentials have more than 1 match with the query. The WI prepares the options to be displayed to and chosen by the user and continues for the user's consent.
The WI selects one pp_pid_credential and the corresponding rwsca_bound_wrapped_key from the batch for further processing. The WI also checks whether the batch of the selected pp_pid_credential is exhausted or expired and, if so, flags that a batch refresh is required in step 017. The exact threshold values and conditions are described in Batch Credential Refresh.
015 - 016 The WI displays the relevant information from rp_openid4vp_request to the user:
  • the identity of the RP from rp_access_cert,
  • the intended use from rp_registration_cert,
  • the data to be presented by applying rp_dcql_query to pp_pid_credential.
The WI then asks the user for consent to present its PID (or parts of it, and potentially other credentials) to the Relying Party. If there is more than 1 match to the rp_dcql_query, the WI offers the user to choose between the options. The user consents by entering his user_rwsca_pin required to authorize the signing of the PID presentation with keys secured by the RWSCA/RWSCD. Collecting consent and the user_rwsca_pin at this early point allows the WI to also authorize a potential batch refresh in the following step without prompting the user again.
017 (optional) If step 014 flagged that the batch of pp_pid_credential is exhausted or expired, the WI triggers a PID re-issuance flow using the pp_refresh_token to obtain a fresh batch before continuing, reusing the user authentication just collected in step 015 - 016. Otherwise, this step is skipped.
018 The WI prepares the PID presentation and applies the selective disclosure to pp_pid_credential according to rp_dcql_query:
  • for mdoc: by removing unnecessary NameSpaceBytes
  • for SD-JWT: by removing unnecessary Disclosures
This is the first preparation step that matches flow of the Remote WSCA Sign operation.
019 The WI generates wi_key_binding_data:
  • for mdoc: by calculating the SessionTranscript using the rp_client_id, rp_key_binding_nonce, rp_response_enc_pubk and the RP's response_uri and generating the deviceAuth structure
  • for SD-JWT: by generating KB-JWT payload using rp_client_id, rp_key_binding_nonce and the hash of pp_pid_credential and the disclosures
020 The WI generates the hash wi_key_binding_data_hash from the wi_key_binding_data, as only the hash is passed to the Remote WSCA for signing.
021 - 023 The WI requests the Remote WSCA Start Session PIN authenticating with two factor authentication (wi_mdvm_prvk and wi_rwsca_pin_prvk derived from user_rwsca_pin). The RWSCA returns the PIN session token (rwsca_pin_session_token) that attests the user authentication. The WI then deletes the user_rwsca_pin and the derived wi_rwsca_pin_prvk.
024 - 026 The WI sends the Remote WSCA Sign operation authenticating with the possession factor wi_mdvm_prvk and the rwsca_pin_session_token as a proof of user authentication to sign wi_key_binding_data_hash with the rwscd_pid_device_prvk belonging to rwsca_bound_wrapped_key associated to the particular pp_pid_credential. The RWSCA ensures, based on the two factor authentication, that only the account which has created the wscd_pid_device_prvk is allowed to use this key for a signing operation. The RWSCA supported by RWSCD then signs the hashed input data wi_key_binding_data_hash ( without knowing the payload) of wi_key_binding_data using rwscd_pid_device_prvk and responds the signature rwscd_key_binding_signature to the WI. If the presentation process was finished successfully and no further re-issuance is required, the cached rwsca_pin_session_token should be flushed, as explained in the PIN Session token section.
027 The WI assembles the PID presentation wi_pid_presentation from pp_pid_credential, wi_key_binding_data and rwscd_key_binding_signature and embeds it into the vp_token structure:
  • for mdoc: using pp_pid_credential as issuerAuth and using wi_key_binding_data and rwscd_key_binding_signature to assemble deviceSigned
  • for SD-JWT: using pp_pid_credential as Issuer-signed SD-JWT, selective Disclosures and using wi_key_binding_data and rwscd_key_binding_signature to assemble KB-JWT.
028 - 029 The WI generates an ephemeral response encryption key pair (wi_response_enc_prvk, wi_response_enc_pubk used for additional application-level encryption with response mode direct_post.jwt. The WI then encrypts wi_pid_presentation using keys derived from Elliptic Curve Diffie-Hellman using wi_response_enc_prvk and rp_response_enc_pubk using JWE.
030 The WI creates the wi_openid4vp_response from the encrypted wi_pid_presentation and the unencrypted rp_openid4vp_state.
031 The WI deletes the presented pp_pid_credential and the corresponding rwsca_bound_wrapped_key, as the WI follows a one-time-use policy to enable unlinkability.
032 The WI sends the OpenID4VP Authorization Response wi_openid4vp_response as a HTTP POST request to the RP's rp_response_uri.
033 The RP matches the OpenID4VP session using rp_openid4vp_state and store the encrypted wi_pid_presentation without validating it yet. The RP must perform a redirect to the WI's browser first to prevent session fixation attacks.
034 - 035 The RP therefore creates a unique rp_redirect_uri and binds it to the OpenID4VP session of rp_openid4vp_state and responds to the WI with a HTTP 200 containing the rp_redirect_uri.
036 - 037 The WI launches the user device browser with rp_redirect_uri. The browser then makes the HTTP GET request to rp_redirect_uri. As the browser has been in this session before, it provides the rp_cookie_id.
038 The RP matches the browser session using the provided rp_cookie_id and can securely map it to the OpenID4VP session bound to rp_redirect_uri.
039 The RP decrypts the stored wi_openid4vp_response from Step 030 using keys derived from Elliptic Curve Diffie-Hellman using wi_response_enc_pubk and rp_response_enc_prvk, equivalent to what WI did in Step 029.
040 - 041 The RP verifies the contents of the wi_pid_presentation using pp_pid_auth_pubk and rwscd_pid_device_pubk and extracts the selectively disclosed es_eid_data:The RP should not permanently store the signed pp_pid_credential, but only the unsigned PID attributes.
042 The RP responds to the WI in the browser session.
043 After the presentation, the WI evaluates the remaining batch of one-time-use pp_pid_credential, as one credential is consumed and deleted per presentation (see step 031). The WI optionally triggers a PID re-issuance flow using the pp_refresh_token to refill the batch if either:
  • the number of remaining pp_pid_credential in the batch has fallen to the threshold, or
  • the remaining pp_pid_credential are close to their expiry
The exact threshold values are described in Batch Credential Refresh. As re-issuance with the refresh token requires user authentication towards the RWSCA, the WI may reuse the still cached rwsca_pin_session_token from this presentation (see step 023) to refill the batch without prompting the user for the user_rwsca_pin again.

Batch Credential Refresh

The WI uses the PID as a batch of one-time-use pp_pid_credential, requests a batch size of 5 for each format during PID issuance and consumes exactly one credential per PID presentation (see step 031). For a PID, the WI stores a long-lived refresh token and the batch of credentials that is refreshed through it:

  • the refresh token, which authorizes a batch refresh via PID re-issuance and is retained across batch refreshes:
    • the pp_refresh_token itself
    • the rwsca_bound_wrapped_key for rwscd_rt_prvk for DPoP-binding the refresh token
    • the expiry of the pp_refresh_token
  • the batch, which is fully replaced on each refresh:
    • a list of pp_pid_credential in both SD-JWT VC and mdoc format, each with the same dataset and expiry but with different rwscd_pid_device_pubk
    • a list of rwsca_bound_wrapped_key for rwscd_pid_device_prvk for each pp_pid_credential

If the WI refreshes a batch of pp_pid_credential, it must delete all remaining credentials and only keep the new batch to ensure they have a homogeneous data set and the same expiry date. The refresh token is not part of the batch and is retained during a batch refresh; it is only renewed through a new eID-authenticated PID issuance once the pp_refresh_token itself has expired.

A batch can no longer be presented in two situations:

  • Expiry: the pp_pid_credential are expired, determined by the exp claim for SD-JWT VC and the validityInfo.validUntil claim for mdoc.
  • Exhaustion: all pp_pid_credential of a batch have been consumed.

The WI evaluates the batch before a PID presentation (step 017) and after a PID presentation (step 043). The WI triggers a PID re-issuance flow using the pp_refresh_token whenever one of the following refresh conditions is met:

  • Expiry:
    • before a PID presentation (step 017): pp_pid_credential is expired (as it may not be presented in time to be evaluated as valid by the Relying Party)
    • after a PID presentation (step 043): pp_pid_credential expires within 10 days (to avoid a time-consuming refresh before the next PID presentation, while a hidden refresh afterwards will not be noticed by the user)
  • Exhaustion:
    • before a PID presentation (step 017): remaining count of pp_pid_credential of the requested format is 0
    • after a PID presentation (step 043): remaining count of pp_pid_credential of either format is 1 or fewer

The user_rwsca_pin should only be entered once by the user and the WI should utilize the rwsca_pin_session_token for the subsequent operations.