Use expected URL instead of expected origins for IAE flow

[awoie]

Fixes #672
Fixes #698

Need feedback on whether expected_url should be plural/ an array. Currently, it is a single value since there is only one IAE endpoint and follow-up requests have to use the IAE endpoint and not a dynamic URL provided by the interactive authorization response that requires interaction. If this should change any reasons (e.g. reusability), I would need to update the PR.

@GarethCOliver if this should be a resuable mechanism, do we need to change the binding the IAE endpoint sections? Currently, they are tightly coupled to IAE by using prefixes etc.

[TimoGlastra]

Should this PR also address #698, since it's related to the origin binding?

I think the reference in A3.5 won't be correct anymore since it links to "derived Origin (as defined in Section 6.2.1.1)"

[awoie]

This PR needs more reviews.

Could you please review again @TimoGlastra

[TimoGlastra]

I think it's missing some required changes to fully remove all references to "Derived origin"

[c2bo]

I found the description/terminology a bit confusing: request vs Interactive Authorization Response in our terminology unless i misunderstood something. This is the current text:

The expected_url parameter is a non-empty string that contains the endpoint of the Verifier that is returning the request. In the openid4vp_presentation interaction type, expected_url MUST be set to the Interactive Authorization Endpoint.

If expected_url is present, the Wallet MUST compare the value in this parameter to the URL of the follow-up request to detect replay of the request from a malicious Verifier.

this is achieved by the Wallet verifying the expected_url parameter in the request, which contains the Interactive Authorization Endpoint that initiated the request.

Given the terminology, wouldn't something like this be more fitting?

the expected_url parameter is a non-empty string that contains the endpoint of the Authorization Server that is returning the Interactive Authorization Response.

If expected_url is present, the Wallet MUST compare the value in this parameter to the URL of the follow-up Interactive Authorization Request to detect replay of the request from a malicious Authorization Server/Verifier.

this is achieved by the Wallet verifying the expected_url parameter in the Interactive Authorization Response, which contains the Interactive Authorization Endpoint that initiated the Interactive Authorization Response.

[Sakurann]

@c2bo can you please respond to @awoie 's suggestions?

[c2bo]

@c2bo can you please respond to @awoie 's suggestions?

I think those changes help clarify / reduce the confusion between request & IA response, thanks @awoie!

[fkj]

Looks good to me with the new suggestions.

[c2bo]

looks good to me with the proposed changes

[brentzundel]

@awoie if you accept @c2bo 's changes, then I believe we can merge this PR.

[brentzundel]

@awoie, please also address merge conflicts.

[mickrau]

@awoie @brentzundel
i solved the merge conflicts in mickrau/fix-672

Feel free to merge it into this PR

Update: After speaking with @paulbastian, I went ahead and merged it myself.

[mickrau]

I fixed the conflicts, but i'm not really satisfied that we're introducing a new VP related variable in this spec and gaining so little from it.
Correct me if I'm wrong, but we get a little more precision (uri instead of origin) but this only addresses potential privacy issues when:

different AS instances use the same origin and one instance is evil
the Authorization Response is not encrypted.
I would prefer to keep it simple and recommend to use response encryption (in HAIP)