You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on Dec 12, 2024. It is now read-only.
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.
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").
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:
Wallet makes GET /idv http request to the issuer
Issuer responds with the SIOPv2 Request in the http response body
Wallet makes a POST /idv http request to the issuer, wherein the http request body is the SIOPv2 Response
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.
The text was updated successfully, but these errors were encountered:
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.
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: