-
Notifications
You must be signed in to change notification settings - Fork 2
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Consider if metadata resources can be consolidated to the SIOPv2 Request #20
Comments
It does not look like the metadata the spec defines supports this. Perhaps we could leverage the dynamic client registration metadata specifically with the 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). |
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. |
Thank you to you both @decentralgabe @selfissued Any objections or additional commentary @mistermoe @tomdaffurn? Else I'll mark this ticket as closed |
PR #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
/.well-known/openid-credential-issuer
)/.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
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)
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
anduri
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:GET /idv
http request to the issuerPOST /idv
http request to the issuer, wherein the http request body is the SIOPv2 ResponseSo 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.
The text was updated successfully, but these errors were encountered: