In the digital credentials ecosystems, a common scenario is the issuance of a credential to a user who authenticates by presenting another credential to the issuer.
The Interactive Authorization Endpoint, defined in the current draft of version 1.1, enables the integration and binding of this presentation in the issuance process without switching context between wallet and browser, which has benefits for both security and user experience.
However, since it is unclear when version 1.1 will be finalized, and the first major applications building on 1.0 are currently under development, it is essential to collect pros and cons, as well as experiences, on how to combine presentation with issuance using VCI 1.0.
After discussing with some developers of both wallets and issuers, it appears that different approaches and variants exist, which may not be compatible, do not have the same level of security (binding of presentation to issuance) and differ in user experience (context switches).
Variants for Combining Presentation with Issuance
There are three different variants with various flavors each:
Variant 1: Separated Flows
Complete OpenID4VP flow for user authentication first,
start OpenID4VCI flow second, use data in credential-offer (A1, A2, B3) or browser session for binding.
A: Using Pre-Authorized Code Flow
- A1: Without transaction code
- A2: With transaction code (out-of-band communication necessary)
B: Using Authorization Code Flow
- B1: With re-authentication using pre-established (browser) session context of OpenId4VP flow
- B2: Only consent, no (session-based) authentication (no real security benefit compared to A1)
Variant 2: Nested Flows (VCI 1.0)
This variant involves starting with the OpenID4VCI Authorization Code Flow and performing the presentation via OpenID4VP in the authorization step. Flavors see "Which Browser to use".
Variant 3: Integrated Authentication
Using the Interactive Authorization Endpoint (IAE) or OAuth for first-party applications is out of scope, as it is defined in version 1.1 or is proprietary.
Which Browser to use?
Implementation details/considerations for Authorization Code Flow
- open
request_uri in system browser
- open
request_uri in webview/browser tap in app context
- shared cookies with (system browser)
- no shared cookies
Some first thoughts:
Variant 1 seems to be the most robust in terms of interoperability, because of lower complexity for the wallet (just process two separated flows one after the other). However, in terms of security, Variants A1, A2 and B2 come with security risks that inherit with the Pre-Auth Flow. Only B1 builds on top of a secure session that was established before. But B1 requires that the VP session is shared in the VCI authorization step (same user-agent must be used, how robust is this?)
Variant 2 is, for me, the natural way to implement user authentication in the issuance process and would be very similar to Variant 3. However, I heard from wallet implementers that they see issues with interrupting an ongoing issuance process by a presentation process and proceeding with the issuance process afterwards (This is not required in any spec).
Some questions:
-
Does anywhere a detailed comparison of the variants exist?
-
Is there implementer feedback, especially on Variant 2? Should all wallets support variant 2?
-
Do you think Variant 1 has "HAIP-level"? Only B1?
In the digital credentials ecosystems, a common scenario is the issuance of a credential to a user who authenticates by presenting another credential to the issuer.
The Interactive Authorization Endpoint, defined in the current draft of version 1.1, enables the integration and binding of this presentation in the issuance process without switching context between wallet and browser, which has benefits for both security and user experience.
However, since it is unclear when version 1.1 will be finalized, and the first major applications building on 1.0 are currently under development, it is essential to collect pros and cons, as well as experiences, on how to combine presentation with issuance using VCI 1.0.
After discussing with some developers of both wallets and issuers, it appears that different approaches and variants exist, which may not be compatible, do not have the same level of security (binding of presentation to issuance) and differ in user experience (context switches).
Variants for Combining Presentation with Issuance
There are three different variants with various flavors each:
Variant 1: Separated Flows
Complete OpenID4VP flow for user authentication first,
start OpenID4VCI flow second, use data in credential-offer (A1, A2, B3) or browser session for binding.
A: Using Pre-Authorized Code Flow
B: Using Authorization Code Flow
Variant 2: Nested Flows (VCI 1.0)
This variant involves starting with the OpenID4VCI Authorization Code Flow and performing the presentation via OpenID4VP in the authorization step. Flavors see "Which Browser to use".
Variant 3: Integrated Authentication
Using the Interactive Authorization Endpoint (IAE) or OAuth for first-party applications is out of scope, as it is defined in version 1.1 or is proprietary.
Which Browser to use?
Implementation details/considerations for Authorization Code Flow
request_uriin system browserrequest_uriin webview/browser tap in app contextSome first thoughts:
Variant 1 seems to be the most robust in terms of interoperability, because of lower complexity for the wallet (just process two separated flows one after the other). However, in terms of security, Variants A1, A2 and B2 come with security risks that inherit with the Pre-Auth Flow. Only B1 builds on top of a secure session that was established before. But B1 requires that the VP session is shared in the VCI authorization step (same user-agent must be used, how robust is this?)
Variant 2 is, for me, the natural way to implement user authentication in the issuance process and would be very similar to Variant 3. However, I heard from wallet implementers that they see issues with interrupting an ongoing issuance process by a presentation process and proceeding with the issuance process afterwards (This is not required in any spec).
Some questions:
Does anywhere a detailed comparison of the variants exist?
Is there implementer feedback, especially on Variant 2? Should all wallets support variant 2?
Do you think Variant 1 has "HAIP-level"? Only B1?