Add a standard way to request additional evidence based on OpenID4VP during OpenID4CI credential issuance

[OIDF-automation]

Imported from AB/Connect bitbucket: https://bitbucket.org/openid/connect/issues/1783

Original Reporter: @awoie

Currently, there is no standardized way to request credentials or other information from the user during the issuance process. How this can be achieved today is during the authorization step which the issuer orchestrates. The issuer may request additional information through OpenID4VP as part of the authorization step which requires a system browser or an internal browser for native apps. To have a native UI experience especially for native apps it would be beneficial to provide a OpenID4VP request either in the token or credential response in case additional credentials are required for issuance.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

To add a little color..

so far the spec says OpenID4VP should be used if presentation of VCs is required during the Issuance process using OpenID4VCI. We have looked into this option with our engineers and it does not seem ideal from the user experience and session management perspective - openid4vp authz req will require an internal web view or the system browser opening in the wallet after receiving openid4vci authz response:

two options to improve the experience:

1. Issuer will pass openid4vp authorization request in the openid4vci authorization response asking to present a certain VC.
2. issuer publishes in the credential issuer metadata that it requires VC(s) of which type/format to be presented in order to issue certain VCs, so the wallet can send a that VC in an authorization/token request of VCI.

in either way what needs to be defined is how to include 4vp authorization request or input VCs in the VCI request/response.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

to 1: why is that better in terms of UX? How is the issuer able to complete the authorization process without the request credential?

to 2: possible, however that is a static configuration - there is no way to determine what is needed for a certain user and sub-sequently request it. Sending the credential in the token request means that the grant is split - the authz code or pre-authz code somehow authorizes (what?) and the credential complements it.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

I think this issue needs more meat. Can you please add descriptions of use cases?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: oliver-terbu

As a developer, I want to integrate issuer services to retrieve VCs from that issuer that require the presentation of other credentials (e.g., W3C VCs, ISO mdocs etc.), so that I can provide a native user experience to my end users without requiring a system browser, or internal browser in my mobile app, or proprietary issuer SDK.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: oliver-terbu

I agree with @{557058:cf344cf5-3085-4fd6-abb3-eaa88b0f0ab9} that option 2 has the downside that a static configuration is quite limited. I was thinking whether we could use https://datatracker.ietf.org/doc/draft-ietf-oauth-step-up-authn-challenge/ in the credentials endpoint to request additional VCs but I haven’t fully thought that through. Any thoughts?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: tlodderstedt

That is basically what the description already states, right?

Can you give a concrete example of such a flow (what credentials) and how you would envision it to work? Perhaps you could also answer my questions further up (to 1 and 2)?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: oliver-terbu

@{557058:cf344cf5-3085-4fd6-abb3-eaa88b0f0ab9} re 1: The UX can be improved by allowing the app developer to control UI elements.

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: oliver-terbu

Another thought I had is that if we solve this we would also make OpenID4CI more accessible to IOT/smart device developers. What would be the strategy for IOT or smart device developers to integrate OpenID4CI into their application?

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: oliver-terbu

@{557058:cf344cf5-3085-4fd6-abb3-eaa88b0f0ab9} regarding concrete example…

Can you give a concrete example of such a flow (what credentials) and how you would envision it to work?

After reading the section on Dynamic Credential Request again, I believe the wallet_issuer parameter might achieve already what I had in my mind but it is too complicated at the moment.

Imagine the following:

1. Wallet generates OpenID4CI authz request and includes the wallet_issuer URL in case the credential issuer has to request additional VCs to issue the credential. The wallet also includes their client_metadata credential_offer_endpoint.
2. Wallet sends the OpenID4CI authz request to the credential issuer’s authz endpoint.
3. Credential issuer verifies the OpenID4CI authz request and requires additional VCs from the user. Credential issuer fetches config from wallet_issuer and generates OpenID4VP authz request corresponding to wallet_issuer config to request additional VCs from the user. Credential issuer generates authz response which is a OpenID4VP 302 redirect (to wallet).
4. Wallet receives the 302 redirect with the OpenID4VP authz request.
5. Wallet asks the user to give consent.
6. Wallet generates the OpenID4VP response and sends the response to the redirect_uri (callback).
7. Credential issuer receives OpenId4VP response whereas redirect_uri contains some parameter (path, state) that allows the credential issuer to understand where to proceed in the OpenID4CI flow.
8. Credential issuer verifies OpenID4VP response and generates 302 with OpenID4CI Credential Offer with pre-authz code.
9. Wallet goes to OpenID4CI token endpoint with pre-authz code which results in an access_token for the credential endpoint where the wallet can get the final VC.

While the above flow can be done, it is very convoluted since it requires two 302 redirects.

By introducing a dedicated error response in the authorization error response that contains the OpenID4VP request, the process could be much simpler by removing the two 302 redirects. IMO, this would also help with interop.

I would also feel more comfortable if we could tie the initial authz request in step 1. together with the token request in step 9, e.g., through PKCE, which could be done if the OpenID4VP request would be more integrated in OpenID4CI.

‌

[OIDF-automation]

Imported from AB/Connect bitbucket - Original Commenter: KristinaYasuda

SIOP call: sequence diagrams would help to understand why 4vp flow during a VCI flow is a hustle.

[Sakurann]

this has been brought up multiple times in my conversations with the implementers.
there are some use-cases for presentation during issuance where desired behavior is

1. wallet sends authorization request (VCI)
2. issuer responds with presentation request (VP)
3. wallet returns requested credential (VP)
4. issuer responds with an authorization code in response to 1. (VCI)
   so that the user stays in the wallet and no issuer browser pops up. so sending 1. as a redirect is not the best option.

One proposed solution has been 1. being send as a POST to the issuer's endpoint instead of a redirect. there is a related draft https://datatracker.ietf.org/doc/html/draft-parecki-oauth-first-party-apps-01 in the oauth wg that defines a behavior very similar to the one desired here. (cc @aaronpk)

[dlongley]

Another option is:

1. wallet requests credentials (VCI)
2. issuer responds with a 400 error code with JSON including a presentation_required error and a presentation request (this is the same pattern as requiring a DID-based proof today with invalid_proof error)
3. wallet responds to presentation request (VP)
4. wallet requests credentials again (VCI)
5. issuer returns credentials (VCI)

No redirection is needed with this approach and it technically could support multiple rounds of requests depending on what is submitted (for more complex flows).

[jogu]

The discussion about this requirement appears to be proceeding on #360
I hence suggest we close this issue and continue in #360. If anyone objects please say otherwise we'll close in a week or two.

[Sakurann]

@dlongley I think using first party apps draft as discussed here is very close to what you are proposing. one difference is probably that 3. will be another authorization challenge endpoint request resulting in 200 and authorization code.

also, I am ok closing this issue - let's continue in #360 or an issue in first party apps GH.

[Sakurann]

@dlongley chairs can't find a contribution agreement for you or digital bazaar for DCP WG. Could you please sign one, or we cannot incorporate your comments.

[msporny]

@dlongley chairs can't find a contribution agreement for you or digital bazaar for DCP WG. Could you please sign one, or we cannot incorporate your comments.

Done. Please incorporate our comments.

[jogu]

As per above comment, closing in favour of #360 - let's continue the discussion there!