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.

• [x] 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?
• [x] Examples for IAR SessionTranscript need to be regenerated
• [x] Fix 620
• [ ] I did not update the audience in the VP, see comment below https://github.com/openid/OpenID4VCI/pull/602#issuecomment-3184017712, but proposal here https://github.com/openid/OpenID4VCI/pull/629

[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: https://github.com/openid/OpenID4VCI/pull/629

[Sakurann]

WG discussion:

• prioritize this PR before discussing #629
• open an issue about where to define this new response mode vci or vp -> #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).

[Sakurann]

@GarethCOliver @davidz25 @martijnharing @hlozi can one of you review sessionTranscript in this PR and approve if it makes sense?

[tlodderstedt]

WG meeting on 9th of Dec: @martijnharing will be reviewing this PR over xmas. @awoie will add a resolutuion for #672 within the same time frame.