Presentation During Issuance

[danielfett]

First, minimal version of Presentation During Issuance (Issue #473) . Work in Progress.

There are four open todos:

• Determine whether we a way to show a website. The first-part apps draft right now only contains a fallback to the regular web flow, not a flexible way to open an in-app browser tab. If we add something like this, we may need to include privacy considerations.
• The original draft contains a presentation_during_issuance_session parameter, for binding the presentation response to the issuance process. Do we need this, and if yes, how do we define it?
• Determine if we want to make the extension point ("define your own responses here for scanning an ID card") explicit or not.
• Add new endpoint / OAuth error / etc to IANA considerations

[Sakurann]

thank you! changes to the PAR section are editorial, and not related to presentation during issuance, right?

[stefan-kauhaus]

Thank you for the proposal! From a business requirements point of view (financial services in this case), I can confirm that there is a requirement for the issuer to have the option to ensure that the credential to be issued ends up in the same wallet unit as where the other one was presented from, both without and with DC API. I also believe that in this presentation-during-issuance scenario, the issuer receives 2x key material from/for holder binding and 2x the WUA. Processing these could be a way to achieve the binding between presentation and issuance beyond a auth_session/presentation_during_issuance_session parameter.

[cre8]

I don't think going via a new endpoint is necessary. It was done by following the first party draft approach, where the new endpoint gets the information via a post request. But since we already have the par endpoint, we can reuse it as it is.

The only thing then to extend is the authorization error response
instead of returning a 302, we could return a 400 authorization error response with the required information.

I am not sure if this is a good practice since it the server could either return an error via 302 (current approach) or the 400 (new approach).

Edit: I mixed up one approach, so pls forget my suggestion above. Going via a new endpoint sounds like a good way to got. Open question is what should the verifier return when the wallet is using the other endpoint (for some reasons) and not the new one.

[charsleysa]

I think the Authorization Challenge Response should be more like the Pushed Authorization Request response, where a request URI is provided for the authorization endpoint. This way there is still issuer interactivity after the credential is presented to the issuer.

This is needed for use cases where there are extra steps to perform, not just relying on the presentation of the credential, for example biometric face matching to ensure that the current user performing the action is the same person as described by the credential, or the user providing extra information for record matching.

The use cases this would applicable to are for example:

• upgrading from one assurance level of credential to a higher assurance level of credential, e.g. from a Student ID to a National ID
• receiving another type of credential, e.g. receiving a tax number credential using a National ID credential and confirming tax information
• renewing an expired credential, e.g. policy dictates that expired National ID credentials up to 6 months expired can be used to go through a streamlined/shortened process to obtain a new National ID credential

[stefan-kauhaus]

Thank you for the proposal! From a business requirements point of view (financial services in this case), I can confirm (...)

Please also see requirement ACP_07 on https://github.com/eu-digital-identity-wallet/eudi-doc-architecture-and-reference-framework/blob/main/docs/discussion-topics/k-combined-presentation-of-attestations.md for further context.
(edit: updated link)

[jogu]

@charsleysa

I think the Authorization Challenge Response should be more like the Pushed Authorization Request response, where a request URI is provided for the authorization endpoint. This way there is still issuer interactivity after the credential is presented to the issuer.

This would make the cases where the issuer doesn't need interactivity weird I think. The issuer can already force interactivity assuming we do go ahead with the web flow fallback Daniel has proposed in the text, I think that would mean both cases are possible at the issuers discretion.

[jogu]

@cre8

I don't think going via a new endpoint is necessary. It was done by following the first party draft approach, where the new endpoint gets the information via a post request. But since we already have the par endpoint, we can reuse it as it is.

PAR isn't mandatory in VCI. I think either the first party draft or Daniel's proposal could choose to reuse/mandate PAR, I don't think there's anything inherently different between the two.

I think if we did reuse the PAR endpoint there are other things we'd need to think about, like giving the wallet a way to indicate if it is willing/able to do presentation during issuance perhaps. The first party draft also seems to be considering using the PAR endpoint: oauth-wg/oauth-first-party-apps#134

[jogu]

Discussed on today's WG call:

People are happy with the general direction, Daniel to fill out the missing sections tomorrow. Should be extensible but we won't define how to solve other use cases in VCI 1.0. Referencing OID4VP security considerations make sense. Presenting during issuance using DC API can come in a later version of VCI once we have implementation experience.

Gareth, Tobias to review on Thursday.

[awoie]

I am generally fine with the direction but we should add a7eccad to this proposal to support certain real world use cases.

Updated: it seems this has been addressed.

[danielfett]

What does "to the Wallet" mean here? To the redirect URI?

[danielfett]

"returns a response with" means that the parameter is appended to the redirect URI?

[tplooker]

Yes on both accounts here, what about.

Once this phase of the Authorization process is completed, the Authorization Server MUST redirect the user-agent back to the Wallet as per [@RFC6749]. If the Authorization process is complete when this redirect occurs, the Authorization Server returns the `authorization_code` based authorisation response as per Section 1.3.1 of [@RFC6749]. If the Authorization process is not complete when this redirect occurs, the Authorization Server returns an authorisation response with the `auth_session` parameter. In the event a Wallet receives a response from the Authorization Server which contains the `auth_session` parameter, the Wallet MUST make a follow-up request as per (#follow-up-request) to continue the Authorization process.

[tplooker]

The language around redirection I lifted from RFC 6749.

[tplooker]

Suggested change

Once this phase of the Authorization process is completed, the Authorization Server MUST redirect back to the Wallet as per [@RFC6749]. If the Authorization process is complete when this redirect occurs, the Authorization Server returns a response with the `code` parameter as per Section 1.3.1 of [@RFC6749]. If the Authorization process is not complete when this redirect occurs, the Authorization Server returns a response with the `auth_session` parameter. In the event a Wallet receives a response from the Authorization Server which features the `auth_session` parameter, the Wallet MUST make a follow-up request as per (#follow-up-request) to continue the Authorization process.

Once this phase of the authorization process is completed, the Authorization Server MUST redirect the user-agent back to the Wallet as per [@RFC6749]. If the authorization process is complete when this redirect occurs, the Authorization Server returns the authorization code based response as per Section 1.3.1 of [@RFC6749]. If the authorization process is not complete when this redirect occurs, the Authorization Server returns an authorisation response with the `auth_session` parameter. In the event a Wallet receives a response from the Authorization Server which contains the `auth_session` parameter, the Wallet MUST make a follow-up request as per (#follow-up-request) to continue the authorization process.

@danielfett copied my suggestion from your comment to here.

[Sakurann]

• @danielfett waiting on the input from @aaronpk if there are any security conciderations we need to add about auth_session being returned in the redirect.
• another mix-up attack is introduced here?
  @tplooker to open a PR with the suggestion made here so that we can continue security considerations discussion there.

[tplooker]

Approving on the basis that we address the residual concerns with follow up PRs before v1.0