PID Option D: Authenticated Channel with Secure Element

Basic Ideas

• There is an Applet in the Secure Element of the user's device. This applet belongs to the Wallet Provider's domain (difference in case of eUICC?). It could be used for very security sensitive credentials beyond PIDs.
• The Wallet Design is composed of three elements: Wallet Backend, Wallet App and Wallet Applet
• Applet is installed during Wallet App installation (if supported by the device and provisioning is possible through platform vendor/MNO)
• Applet is provisioned with an assertion attesting applet managed key as (internally used) authentication key
• Access to authentication key is protected by Applet-managed PIN

Note: This flow is shown here using the SD-JWT credential format, but the mdoc format can be used as well.

Responsibilities of the Wallet Components

Wallet App

• RP authentication
• Request processing
• Combination of PID with (Q)EAA presentations
• Response encryption
• Access to Wallet App and Data managed by the App is protected by platform authentication

Wallet Applet

• Management of PID specific device keys
• Access to PID device keys is protected by Applet-managed PIN
• Creation of proof of possession for wallet attestations (with PID device keys)
• Data Storage for PIDs and PID data (could also just HMAC and encrypt and hand them over to App)
• creation of credential presentations (not responses!)

Wallet Provider

• Applet provisioning with authentication key
• Attestation of Wallet App and PID device keys

Cryptographic Formats

Issuance

Long-term keys:

• Authentication key of Wallet Applet: \((auth\_pub, auth\_priv)\) — authenticates the applet
• Wallet provider backend has keys: \((wp\_pub, wp\_priv)\)
• PID Provider backend has keys: \((pp\_pub, pp\_priv)\)

Transaction-specific keys:

• Wallet Secure Area generates device key \((device\_pub, device\_priv)\)
  • authenticity can be determined by applet assertion
  • a new key is generated per issuer
• Wallet generates ephemeral key pair used to encrypt the credential response \((cre\_eph\_pub, cre\_eph\_priv)\)

Artifacts:

• Wallet applet creates device key PoP: \(device\_key\_pop := \text{sign}(wallet\_attestation\_nonce)_{device\_priv}\)
• Wallet applet creates signed assertion: \(device\_key_\_attestation := \text{sign}(device\_pub)_{auth\_priv}\)
• Wallet app creates wallet app attestation: \(wallet\_app\_attestation := \text{app\_attestation}(wallet\_attestation\_nonce)_\text{os\_keys}\)
• Wallet backend creates wallet attestation: \(wallet\_attestation := \text{sign}(device\_pub)_{wp\_priv}\)
• Wallet creates wallet attestation PoP: \(wallet\_attestation\_pop := \text{sign}(pid\_issuer\_session\_id)_{device\_priv}\)
• Wallet applet creates device key PoP for credential issuance: \(device\_key\_pop := \text{sign}(c\_nonce)_{device\_priv}\)
• PID Provider creates \(x5c\_header := \text{sign}(device\_pub)_{pp\_priv}\)
• PID Provider creates \(user\_data\_jwt := \text{hmac}(user\_data, x5c\_header)_{\text{ecdh(device\_pub, pp\_pub)}}\)

Presentation

Long-term keys:

• Device key \((device\_pub, device\_priv)\)

Transaction-specific keys:

• RP contribution to HMAC key: RP generates ephemeral key pair \((rp\_eph\_pub, rp\_eph\_priv)\)
• KB-JWT Keys: Wallet applet generates ephemeral key pair \((kb\_eph\_pub, kb\_eph\_priv)\)

Artifacts:

• \(hmac\_key := \text{ecdh}(device\_priv, rp\_eph\_pub)\)
• \(sd\_jwt := \text{hmac}(x5c\_header, \mathit{eID\_data}, kb\_eph\_pub)_{hmac\_key}\)
• \(kb\_jwt := \text{sign}(nonce, audience, \text{hash}(sd\_jwt, disclosures))_{kb\_eph\_priv}\)

Dependencies

TODO: May want to expand to include metadata.

Not shown: user_data_jwt

Note: x5c header does not have to be signed in SD-JWT

Sequence Diagrams

Wallet Activation

User Journey: Wallet Activation - Authenticated Channel - Secure Element

To initialize the wallet, the Wallet obtains wallet attestation as defined in Wallet Attestation.

Issuance

User Journey: PID Issuance - Authenticated Channel - Secure Element

Presentation

User Journey: PID Presentation - Authenticated Channel - Secure Element

Step-by-Step Description

Issuance

1. The user opens and unlocks their Wallet
2. The user browses through the pre-configured credential catalog and chooses to request a PID
3. The Wallet requests a fresh nonce for the wallet attestation nonce (wallet attestation)
4. The PID Provider generates a fresh nonce linked to the issuance session
5. The PID Provider returns the wallet attestation nonce to the Wallet
6. The Wallet performs a wallet attestation
7. optionally fetches a new wallet attestation from the Wallet Provider if not existent yet
8. generates a proof of possession (PoP) for the public key of the wallet attestation using its WSCD
9. The wallet sends the Pushed Authorization Request to the PID Provider; containing
10. the Wallet Provider's client_id
11. authorization_details for PID
12. a PKCE code_challenge
13. a wallet attestation and proof of possession
14. The PID Provider verifies the wallet attestation and its proof of possession and validates the certification status of the Wallet Solution on a trust list
15. The PID Provider returns a request_uri that is bound to the Pushed Authorization Request
16. The Wallet sends the Authorization Request; containing
    • the PAR request_uri
17. The PID Provider responds with the first step to start the eID process with the wallet app, e.g. the tcToken. Note that this is the direct HTTP Response to Step 14.
18. Further communication is exchanged to perform the eID process
19. The user provides the eID PIN to the wallet app.
20. Further communication is exchanged to perform the eID process
21. The eID process is finished and as a final step the Wallet sends a request to the PID Provider calling the refreshURL. From now on Wallet and PID Provider are using the TLS-PSK channel generated by the eID flow.
22. The PID Provider responds to the Wallet with an Authorization Response; containing
    • the auth code
23. The Wallet sends a Token Request to the PID Provider; containing:
    • the auth code from Authorization Response
    • the PKCE code_verifier matching the code_challenge from Authorization Request
    • the wallet attestation and proof of possession
    • a DPoP key
24. The PID Provider matches the code, verifies the PKCE code_verifier to the previously received code_challenge and verifies the wallet attestation. It then generates an access token bound to the DPoP key.
25. The PID Provider sends a Token Response; containing
    • DPoP-bound access token
    • a c_nonce
26. The Wallet uses the device binding key (device_pub, device_priv) from the wallet attestation and signs the c_nonce using the Secure Element (WSCD)
27. The Wallet generates a new ephemeral keypair (cre_eph_pub, cre_eph_priv).
28. The Wallet creates the credential_response_encryption JSON object containing the following information:
    • a jwk containing the cre_eph_pub
    • the JWE alg parameter
    • the JWE enc parameter
29. The Wallet sends a Credential Request to the PID Provider; containing
    • the DpoP-bound access token
    • the credential_response_encryption object
    • the device binding key device_pub and the proof of possession
30. The Issuer validates the access token and the proof of possession
31. (SD-JWT) The PID Provider performs DH key exchange with the Wallet's public key device_pub and its private key pp_priv, generates a shared secret k and derives a MAC key
32. (SD-JWT) The PID Provider creates a user data JWT containing the eID data and secured with a HMAC
33. (SD-JWT) The PID Provider creates a certificate chain containing device_pub and signing with pp_priv
34. (SD-JWT) The PID Provider creates an encrypted JWT (JWE) using the values received in the credential_response_encryption object and adds (among others) the PID credential to the payload.
35. The PID Provider sends the Credential Response JWT; containing:
    • user data JWT with the certificate chain in x5c header
36. The Wallet decrypts the Credential Response JWT using the cre_eph_priv and retrieves the user data JWT.
37. The Wallet forwards both artifacts to the Secure Element.
38. The Secure Element performs DH key exchange with the PID Provider's public key pp_pub and its private key device_priv, generates a shared secret k, derives the MAC key and validates the authenticity of the user data JWT.
39. The Secure Element stores the user data and the x5c certificate chain securely and associates them to device_pub.
40. The Wallet returns a credential handle to the Wallet for future referencing the data for generating a PID.

Presentation

1. User browses to Relying Party (RP) website
2. Browser app on the user's device opens the RP website
3. RP generates a key pair to be used for ECDH key agreement for SD-JWT hmac'ing
4. RP generates an OpenID4VP Authorization Request and stores it under a request_uri (e.g., https://rp.example.com/oidc/request/1234);
5. The request is bound to the user's browser session
6. It is signed using a key bound to the RP's metadata that can be retrieved using the RP's client_id
7. It contains the ephemeral key for ECDH key agreement for SD-JWT hmacing
8. It contains RP's nonce and state
9. RP returns a HTML page to the browser containing a link to the wallet app (e.g., openid4vp://authorize?client_id=..&request_uri=https://rp.example.com/oidc/request/1234)
10. The user clicks on the link
11. The RP website navigates to the custom scheme link to launch the wallet app
12. The user unlocks the wallet app (see notes below)
13. The wallet app retrieves the Authorization Request from the RP website (e.g., https://rp.example.com/oidc/request/1234)
14. The wallet app receives the Authorization Request
15. The wallet app validates the Authorization Request using the RP's public key
    • Was the signature valid and the key bound to the RP's metadata?
    • Security: This ensures that the Authorization Request was not tampered with; it does not ensure that the party that sent the Authorization Request is the RP.
16. The user gives consent to present the PID to the RP.
17. The wallet app queries the Secure Element for the PID providing:
    • the credential handle referring to the PID credential,
    • the ephemeral RP key rp_eph_pub from the RP's authorization request,
    • a list of claims,
    • input for the KB-JWT (directly or hash)
18. The Secure Element performs DH key exchange with the ephemeral RP public key rp_eph_pub and the private part of DeviceKey device_priv , generates a shared secret k and derives a MAC key for the deviceAuth
19. The Secure Element generates an ephemeral key pair for the KB-JWT (kb_eph_pub, kb_eph_priv).
20. The Secure Element creates the issuer-signed part of the SD-JWT (using the MAC key) containing:
    • stored x5c header
    • stored user claims
    • kb_eph_pub as cnf claim
21. The Secure Element creates a KB-JWT payload containing the nonce, audience, and a hash of the SD-JWT and the selected disclosures and signs it using kb_eph_priv.
22. The Secure Element sends the SD-JWT and KB-JWT to the wallet app.
23. The wallet app creates a VP token and a presentation submission from the received SD-JWT PID.
24. Optional: The wallet app can add the mDL presentation using the nonce and ECDSA according to the presentation definition
25. The wallet app sends the VP token and presentation submission to the RP (encrypted to the RP's public key rp_eph_pub).
26. The RP performs DH key exchange with the PID deviceKey public key, generates a shared secret k and derives a MAC key.
27. The RP finds a session with the state and verifies the PID in the VP token with the MAC key.
28. The RP generates a response code, attaches it to the same session, and returns it to the wallet app via a redirect_uri.
29. The wallet app launches the browser with the redirect_uri and response code.
30. The browser sends the redirect_uri and response code to the RP.
31. The RP matches the response code with the browser session (i.e., ensures that the session tied to the browser session matches the one tied to the response code).
32. The RP considers the user to be identified in the session context and continues the UX flow.

Extensions to the Protocols

This section defines extensions to the protocols required to implement this flow (Option D).

Issuer Session Endpoint (at the PID Provider)

Note that this extension is the same across multiple flows.

This endpoint is used by the Wallet to obtain session_id from the PID Provider that is used to bind PoPs to the session and prove their freshness. Support for this endpoint is REQUIRED.

To fetch the session_id, the Wallet MUST send an HTTP request using the POST method and the application/json media type. The PID Provider MUST return the HTTP Status Code 200 and a session_id parameter defined below.

• session_id: REQUIRED. String that is a unique session identifier, chosen as a cryptographically random nonce with at least 128 bits of entropy.

Communication with the Session Endpoint MUST utilize TLS.

Below is a non-normative example of a request to a Session Endpoint:

POST /session_endpoint HTTP/1.1
Host: server.example.com
Content-Type: application/json

Below is a non-normative example of a response from a Session Endpoint:

HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-store

{
  "session_id": "iOiJSUzI1NiIsInR"
}

OpenID4VCI Credential Issuer Metadata

Note that this extension is the same across multiple flows.

This document defines the following additional Credential Issuer Metadata parameters:

• session_endpoint: REQUIRED. URL of the Credential Issuer's Session Endpoint, as defined in a previous section. This URL MUST use the https scheme and MAY contain port, path, and query parameter components.

Usability Considerations

Initialization

• The Wallet needs to be initialized on a mandatory basis
• During initialization, the user must set a Wallet PIN
• Having only one Wallet PIN has the advantage that the same PIN (eID PIN excluded) could probably also be used for other credentials (also at the same LoA). From a UX perspective, this would be a great added value for users.
• The wallet can only be used after successful initialization

Issuance

• Credential catalogue should inform users in advance of what is required for the successful issuance of the PID and what steps follow
• For reasons of transparency and to increase trust, PID Provider should provide sufficient information (metadata) for the consent screen. This allows users to learn everything relevant e.g. about the PID Provider itself
• eID process is integrated in Wallet. No context switch to the AusweisApp is required
• Physical ID card is required for issuing the PID credential
• Online-Ausweisfunktion must be activated
• eID PIN must be set by the user (replacement of the Transport PIN) and be known to them so that they can successfully confirm the process
• User must confirm the process with the eID PIN and the Wallet PIN. The distinction between the two PINs should be easier for users than the distinction between eID PIN and PID PIN
• User can have a PID credential derived from the eID on several end devices at the same time

Presentation

• Offline support for PID representation
• Relying Party should inform users in advance of what is required for the process to be completed successfully and what steps follow
• It needs to be clarified whether the wallet app needs to be unlocked in this flow and how this should be implemented.
• For reasons of transparency and to increase trust, Relying Parties should provide sufficient information (metadata) for the consent screen. This allows users to learn everything relevant e.g. about the relying party itself, privacy and data retention
• To be able to display the user's data values for the requested attributes on the consent screen, the wallet must first be unlocked with the wallet PIN (to access data from the SE)
• The user only needs to enter the Wallet PIN for each PID presentation
• Physical ID card is not required for PID presentation
• It must be ensured that users return to the correct tab in the correct browser in order to continue the process or know how to get there manually if necessary (especially for iOS devices, if the process was not started in the default browser)

Privacy considerations

• What is the information that is shared with the wallet provider backend? Is it okay if the backend learn which PID Providers are used?
• Multiple device keys must be used to ensure unlinkability across issuers and/or across relying parties
• Selective Disclosure is achieved by ensuring that the credential contains only those data items (claims) that are requested by the RP.

Security considerations

• eID Process in the browser means that a remote cooperating party can complete the eID retrieval for the attacker (easier than when used via app)