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.