add credential format specific sections for IAR endpoint binding in VPs

[awoie]

This PR fixes #590 and #620 by adding credential format specific sections for IAR endpoint binding in VPs.

• Is it clear enough that Credential Formats correspond to the requested Credential in the IAR, and not to the requested Credential in the VCI request?
• Examples for IAR SessionTranscript need to be regenerated
• Fix 620
• I did not update the audience in the VP, see comment below add credential format specific sections for IAR endpoint binding in VPs #602 (comment), but proposal here fix: just do derived origin binding #629

[Sakurann]

i think we need extra line before examples for compilng

[GarethCOliver]

Inconsistent that this is iaeUrl, but we prefix with iar elsewhere. We should be consistent (don't care which).

[awoie]

We didn't prefix with origin: in DC API either. My thought was that the handover type (i.e. OpenID4VCIIAEHandover) in the SessionTranscript would replace the prefixing and this is the way we provide the context on the flow for session transcripts across flows.

[jogu]

discussed on today's WG call: consensus to rename "iar:" prefix to "iae:"

[martijnharing]

Two comments:

1. since expected_origins is optional (or conditional), should we add "if present"?
2. expected_origins can only contain origins, not URLs. While they can match, they don't always match. Is the idea that the expected_origins is converted by the wallet before matching?

[awoie]

I agree that the current definition of Origin and expected_origins in OID4VP clashes with this normative statement. expected_origins contains origin values and is conditional based on if the request was signed. If somebody wants to write a parser for requests, this would be prone to errors since with the current text both, URLs and origins, are allowed.

I also agree that it would be cleaner to say "if present" although I don't know whether this was intentional and part of the original threat mitigation model specifically for IAE requests. I believe it wasn't, so I'm fine with adding "if present".

What we could do (non-breaking):

1. Keep using expected_origins and use the origin part of the URL only. Probably has some security implications but perhaps this is sufficient. For OID4VP it was sufficient to check the origin and not the full URL.
2. same as 1. (since required for signed requests) but additionally define a new optional parameter for the request for signed requests with similar logic to expected_origins, i.e., expected_urls.

[jogu]

discussed on today's WG call - seem to have a consensus for option 1

[awoie]

I updated the PR:

• to harmonize IAE vs IAR terminology
• to use the derived Origin for expected_origins
• to make it clear that deriving the Origin is only required if expected_origins is present (note that OID4VP is not entirely clear if this can be used for unsigned requests too)
• editorial changes

I kept using the IAE (URL) for audience and SessionTranscript binding. However, OID4VP has this for DC API:

The audience for the response (for example, the aud value in a Key Binding JWT) MUST be the Origin, prefixed with origin:, for example origin:https://verifier.example.com/. This is the case even for signed requests. Therefore, when using OpenID4VP over the DC API, the Client Identifier is not used as the audience for the response.

I'm not sure if the current language in this PR would clash with this definition, thoughts? @GarethCOliver @jogu @martijnharing @danielfett. If it does, I can update this PR to use the derived Origin also for the audience and session transcript binding.

[awoie]

I updated the PR:

• to harmonize IAE vs IAR terminology
• to use the derived Origin for expected_origins
• to make it clear that deriving the Origin is only required if expected_origins is present (note that OID4VP is not entirely clear if this can be used for unsigned requests too)
• editorial changes

I kept using the IAE (URL) for audience and SessionTranscript binding. However, OID4VP has this for DC API:

The audience for the response (for example, the aud value in a Key Binding JWT) MUST be the Origin, prefixed with origin:, for example origin:https://verifier.example.com/. This is the case even for signed requests. Therefore, when using OpenID4VP over the DC API, the Client Identifier is not used as the audience for the response.

I'm not sure if the current language in this PR would clash with this definition, thoughts? @GarethCOliver @jogu @martijnharing @danielfett. If it does, I can update this PR to use the derived Origin also for the audience and session transcript binding.

For a proposal on how to use the derived origin instead of the endpoint for the binding, see this PR: #629

[Sakurann]

WG discussion:

• prioritize this PR before discussing fix: just do derived origin binding #629
• open an issue about where to define this new response mode vci or vp -> define a new IAE response mode in OpenID4VP #665
• try merge this PR without addressing above two points in this PR

[jogu]

I've updated this PR to target the 1.1 spec - please review.

As per @Sakurann's comment above, we'll discuss whether to move some of this to the VP spec and will separately handled the discussion about origin vs url in #629, so please ignore those two aspects when reviewing this so we can get the rest of this PR merged (as we have further IAE PRs to create and want to reduce the potential for conflicts).