Type definition of `expected_origins` clashes with IAE endpoint URL

[awoie]

For the IAE flow, we are using the IAE endpoint URL for the expected_origins for signed requests. The definition of expected_origins is that it contains Origins, not arbitrary URLs. OID4VP implementations might have issues with validating the value if it contains a request URL but an Origin value is expected.

Potential solutions:

1. (clean but potentially duplication) use a different field than expected_origins, e.g., expected_urls. This approach might need to require more spec changes and duplication of some parts of OID4VP in OID4VCI.
2. (clean but possibly same security concerns as 3.) use derived origin for expected_origins as proposed in this PR add credential format specific sections for IAR endpoint binding in VPs #602. This approach loses some precision which might have an impact on security.
3. (ugly but quick) Just say that in this case expected_origins can contain arbitrary URLs including path and query string. Some implementations might cut the non-Origin parts of the URL if they share code paths with DC API handling. Not sure if this could lead to some form of mix-up attack if a host (or Origin) is serving multiple issuer services.

[tlodderstedt]

WG discussion:

• two questions: (1) what is the solution to the problem at hand and (2) do we solve it in VCI or do we move the mechanism to VP

1. the sense in the WG meeting was to go with a new field (option 1) as it is the clean, simple and safe solution
2. different opinions, suggestion to do the first PR and decide on this later on (file new issue for that)

[tlodderstedt]

@awoie will add the resolution to the existing PR #602

[tlodderstedt]

WG call on 11th of Dec: sense in the call was to go with (1), a new parameter