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]

text mentions Location header but missing in the example

[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

[TimoGlastra]

Is the show website in this case the "normal" par flow, or just a generic webpage not used for authorization?

In the first party auth spec the challenge endpoint could fallback to behave like the par endpoint and return a request_uri, i think it will be useful to add this here as well, since a wallet won't know beforehand whether to use authorization challenge or PAR endpoint (so in our wallet we default to authorization challenge endpoint if available).

Currently i see no way to handle the case where normal par must be used and the wallet calls the challenge endpoint

[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://eu-digital-identity-wallet.github.io/eudi-doc-architecture-and-reference-framework/1.10.0/discussion-topics/k-combined-presentation-of-attestations/ for further context.

[jogu]

Not a new problem, but the lack of any form of client authentication in this request is slightly disturbing :)

[Sakurann]

can you please open a separate issue on this so that we can fix it in another PR?

[jogu]

I think one of the direct_post response modes needs to be used too. At least I'm having trouble seeing how the below 'repeat the authorization challenge' could work if response_mode=query was used?

I think there's also a need to ignore the redirect_uri in the direct_post response?

[jogu]

It intuitively feels necessary to me - I'm sure there are cases where the issuer is going to need to interact directly with the user, perhaps a simple case might be needing to ask the user for an email address so they can inform the user when the credential is ready or something...

re: your query on this: " 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."

I believe the correct interpretation of the first-party app drafts is that a fallback to the regular web flow would(should) open an in-app browser tab as per https://datatracker.ietf.org/doc/rfc8252/ - is there more flexibility needed?

What extra privacy considerations might we need considering a PAR request can already do this and I don't think we have any extra text around that?

[jogu]

The JSON body/content-type requirement is missing?

[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