Presentation During Issuance

[danielfett]

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

There are three 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.

[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: https://github.com/oauth-wg/oauth-first-party-apps/issues/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.

[tlodderstedt]

WG Call 19.6

• Add description of the reasons/limitation for this mechanism
• Add differentiation to DC API (for getting the credential presentation) - this mechanism is for the classical OpenID4VP

[jogu]

I think we probably need to say something about the authentication of the VP request from the issuer by the wallet?

I think there are two options:

1. The authentication is somehow implicit in the wallet knowing which issuer it is talking to and whether that issuer is entitled to request the particular claims/credentials requested
2. The issuer needs to pass a signed request to the wallet (in which case we'd need to use JAR but a request-object-by-value I think).

[GarethCOliver]

I think we probably need to say something about the authentication of the VP request from the issuer by the wallet?

I think there are two options:

1. The authentication is somehow implicit in the wallet knowing which issuer it is talking to and whether that issuer is entitled to request the particular claims/credentials requested
2. The issuer needs to pass a signed request to the wallet (in which case we'd need to use JAR but a request-object-by-value I think).

Supporting (2) would be necessary in cases where the document being requested has an existing trust framework that can not map back. (1) is similar to using Origin in DC API (for same-device flows), so may be convenient to optionally allow, but can't be the only way

[jogu]

Discussed on today's working group call:

We don't want to align too much the 1st party apps draft, it's inspiration, but we shouldn't depend on it, so should use a different endpoint name, Daniel suggested interactive_authorization_request.

We do need something like this in 1.0 for EU use cases otherwise something non-standard will happen. We can potentially replace in 1.1 if needed.

Paul to make a proposal on different ways to handle 400 error in happy path flows.

Daniel suggested we make it more explicit that this is a generic mechanism we expect people to extend for things like presenting German ID cards, potentially including a non-normative example. We can do that after WGLC though.

[Sakurann]

wg discussion: good to merge once @c2bo review is in

[nklomp]

Editorial name change for "interactive"?

Upon first glance this approach could also be used for machine to machine type of exchanges, for instance between 2 business wallets, without a user involved at the OID4VP step (provided they have a shared trust establishment mechanism). An example would be sharing an LPID, which is more or less public anyway, or another chamber of commerce like credential in other jurisdictions.

2 questions:

1. Am I right in my first analysis this could be used non-interactive quite well as well?
2. If so is the term "interactive" really what is happening here, or could it be slightly reword?

To be clear I am not asking for scoping this to M2M support, but at present I do not see why this could not be used quite well for it and then the name is a bit off to me

[danielfett]

1. Am I right in my first analysis this could be used non-interactive quite well as well?

I think it is suitable for M2M purposes, yes.

2. If so is the term "interactive" really what is happening here, or could it be slightly reword?

My thinking behind "interactive" was to highlight that there is a kind of dynamic "negotiation" between the AS and the Wallet before the issuance process can be completed. The focus was less on the human interaction, as authorization requests typically involve human interaction.

[nklomp]

Maybe something like direct instead of interactive? To highlight that it is not using the front channel at all

[Sakurann]

WG discussion:

• what needs to be defined:
  • 1. support to add a new response mode that talks to a same endpoint as authorization request-response go to
  • 2. for supported types - redirect to the web, openid4vp, etc. -> add considerations for non-openid4vp protocols.
    • how does the wallet communicates which type it supports? interaction_types_supported currently in the PR? wallet pre-registering with the issuer as usual client registration process? (let's handle this in another issue/PR)

3. define behavior for unsigned request in line with dc api case behavior

• security considerations must align with those in dc api
  • requirements for openid4vp request during presentation during issuance follow openid4vp over dc api requirements? there is no browser API in-between. if we see this as the same model as DC API, multi-RP request would apply too for example. (wallet -> (issuer -> wallet -> issuer) -> wallet) : in the second arrow, wallet needs to authenticate who the caller is but it is the same endpoint to which the wallet has sent the original issuance request.
• should not use client_id_scheme origin, it's a url, not origin -> iar:
• not sure we need multi-rp request because wallet and issuer already interacted with each other... allowed because references dc api section in openid4vp
  • wallet can indicate in the initial issuance request which openid4vp version it supports
• in a sense that url of the issuer calling
  • how is URL/origin being authenticated? wallet sent request to that endpoint already
  • what is client_id for unsigned request? - wallet "trusts" the IAE because it is obtained from a trusted issuer metadata
• Gareth/Tobias taking over this PR for the next 2 weeks.