expected_origins in browser API

[jogu]

There are two outstanding questions around expected_origins in the browser API ( https://github.com/openid/OpenID4VP/pull/155 ):

1. https://github.com/openid/OpenID4VP/pull/155/files#r1640368803 - Kristina asked if using expected_origins in unsigned requests could provide some security benefits in some cases.

2. On the 18th June WG call it was discussed whether expected_origins should be considered as client metadata (i.e. we register a new client metadata parameter) that could be communicated in other ways, e.g. pulled from a federation entity id or pull from a .well-known location for the client (as well as being passed in signed requests in the client_metadata parameter) - i.e. treating it in a very similar way are redirect Uris are registered.

[lj-raidiam]

1. Probably not given that it can be modified by an attacker. Maybe inclusion of the origin sourced from the user_agent in the response could help?
2. These alternatives make sense provided that wallet can pull this info. We should then define wallet behavior given that this information might be available to it through different channels.

[Sakurann]

on 1., given that in unsigned requests, the Wallet will use the Verifier's origin as asserted by the user agent to determine the Verifier's effective Client Identifier., I think there is no benefit of expected_origins. hence, PR #388 to clarify.

On 2., as long as the behavior is set (not used for unsigned requests, mandatory for signed requests) I don't think it matters whether it is a top level parameter or client_metadata or something, so keeping it as-is (top level parameter is probably ok)