Consider if metadata resources can be consolidated to the SIOPv2 Request

[KendallWeihe]

PR https://github.com/TBD54566975/known-customer-credential/pull/12 proposes to add the requirement of two metadata resources hosted at well known URIs

Link specifically to the relevant part of the README: https://github.com/TBD54566975/known-customer-credential/tree/kendallw/credential-iss-metadata?tab=readme-ov-file#1-metadata-endpoints

1. Credential Issuer Metadata (OID4VCI) (/.well-known/openid-credential-issuer)
2. OAuth 2.0 Authorization Server Metadata (OID4VCI) (RFC8414) (/.well-known/oauth-authorization-server)

Rather than offering the metadata at these two well known URIs, could we instead include either/both inside the SIOPv2 Authorization Request's client_metadata?

Motivation: two less endpoints required to be hosted, and two less requests the client is required to make, would reduce the perception of complexity in our developer guides.

---

Starting from SIOPv2

From SIOPv2 Authorization Request

client_metadata: OPTIONAL. This parameter is used by the RP to provide information about itself to a Self-Issued OP that would normally be provided to an OP during Dynamic RP Registration, as specified in Section 7.3.

Section 7.3, references OID4VP, but doesn't specify the exact section (spec is a "draft").

Presumably, the referred-to section in OID4VP is to 9. Verifier Metadata (Client Metadata)

To convey Verifier metadata, Client metadata defined in Section 2 of [RFC7591] is used

Section 2 of RFC7591 is linked here, and doesn't seem to be compatible with the two metadata resources required (in the ordered list above). Am I missing something?

---

Alternative Idea

An alternative idea is to include the metadata along side credential_offer and uri in the IDV Request. The IDV Request isn't part of any of the relevant specs, it's a part of this (known-customer-credential) spec. The sequence of events here is:

1. Wallet makes GET /idv http request to the issuer
2. Issuer responds with the SIOPv2 Request in the http response body
3. Wallet makes a POST /idv http request to the issuer, wherein the http request body is the SIOPv2 Response
4. Issuer responds with the IDV Request in the http response body

So the idea being we place the metadata inside the IDV Request wherein the wallet can subsequently make use of the information, rather than needing to turn back around and make two requests to the well known URIs.

With this alternative idea, do we still need to make the well known URIs a required part of this (known-customer-credential) specification, in order to be compatible with OID4VCI? In other words, we support both metadata inside the IDV Request and also at well known URIs. The benefit here being that we could still simplify our developer guides while being spec compatible.

[decentralgabe]

Rather than offering the metadata at these two well known URIs, could we instead include either/both inside the SIOPv2 Authorization Request's client_metadata?

It does not look like the metadata the spec defines supports this. Perhaps we could leverage the dynamic client registration metadata specifically with the request_uris property...but this seems to not be a normal path.

Also noting that the guidance is that we MUST host those endpoints, so I do not think we can get away from hosting these endpoints without normative language making its way into the spec that sets these as optional and allows for providing them dynamically during a SIOPv2 Request..

IMO the more we align with the standard the better as we cannot guarantee that other implementers of the specs will make the same deviations that we do, and we want to make sure that (1) other clients built according to the spec work with our issuance servers and (2) our clients work with other issuance servers.

That is not to say we cannot find a 'legal' way to get the URIs needed (as you have outlined) but that it might harm (1) and (2).

[selfissued]

I agree with Gabe that, to the extent that we're using the OpenID4VC specs, we should use them as intended. Interoperability will be improved by doing so.

Reacting to the idea of including this metadata in SIOPv2 requests, the problem with that is that the Client/RP is not authoritative for the Credential Issuer/Authorization Server metadata. Modularity considerations indicate that each party that is participating in the protocol should supply its own metadata.

[KendallWeihe]

Thank you to you both @decentralgabe @selfissued

Any objections or additional commentary @mistermoe @tomdaffurn? Else I'll mark this ticket as closed