Code change:
component. The following is a non-normative example of a HTTP request for the <del> JWT Issuer Metadata configuration when </del> <ins> JWT VC Issuer Metadata configuration when </ins> is set to : <del> 4.2. </del> <ins> 5.2. </ins> A successful response MUST use the <del> and return the JWT Issuer Metadata configuration using the </del> <ins> and return the JWT VC Issuer Metadata configuration using the </ins> content type. An error response uses the applicable HTTP status code value. <del> This specification defines the following JWT Issuer Metadata </del> <ins> This specification defines the following JWT VC Issuer Metadata </ins> configuration parameters: <del> JWT Issuer Metadata MUST include either </del> <ins> JWT VC Issuer Metadata MUST include either </ins> or <del> in their JWT Issuer Metadata, but not both. </del> <ins> in their JWT VC Issuer Metadata, but not both. </ins> It is RECOMMENDED that the JWT contains a JWT header parameter that can be used to lookup the public key in the <del> JWK Set included by value or referenced in the JWT Issuer Metadata. </del> <ins> JWK Set included by value or referenced in the JWT VC Issuer Metadata. </ins> <del> The following is a non-normative example of a JWT Issuer Metadata </del> <ins> The following is a non-normative example of a JWT VC Issuer Metadata </ins> configuration including : <del> The following is a non-normative example of a JWT Issuer Metadata </del> <ins> The following is a non-normative example of a JWT VC Issuer Metadata </ins> configuration including : <del> Additional JWT Issuer Metadata configuration parameters MAY also be used. </del> <ins> Additional JWT VC Issuer Metadata configuration parameters MAY also be used. </ins> <del> 4.3. </del> <ins> 5.3. </ins> The

Related discussion:
text: This PR introduces the following changes: renamed JWT Issuer Metadata to JWT VC Issuer Metadata which - moved JWT VC Issuer Metadata to the end of the specification for editorial reasons
3 approvals, resolved merge conflicts, merging
Every entity in the OAuth/OpenID is potentially a JWT issuer, then I found the name of this endpoint misleading. Considering that this brand new specification defines a profile for SD JWT verifiable credentials, I'd propose to change the pathname to .well-known/vc-jwt-issuer
The idea is that the JWT Issuer could be used with any JWT, not necessarily VCs only.
NAME what do you think?
NAME is there a reason the JWT Issuer should not be used with something else than VCs?
There are well known endpoints like openid-configuration or openid-federation that publish entities metadata, including jwks Since this specs Is related to VC based on sd-jwt, this specs should not be in conflict to pre existing Oauth2/OpenID ecosystem SD-JWT-VC should define only the resources needed for the solution It defines
I'm ok with the proposed change. I anyway assume we will add VC issuance specific metadata in the future (it is not limited to key distribution).
I agree NAME Key attestation alone Is not enough, this endpoint deserves a proper identity with a specialized protocol metadata Also the verifiable attestations related to the entity may be available in it
To me this sounds reasonable. I will update the spec accordingly.
(As a record, I repeat my question I made elsewhere in the past.) Why is it necessary to introduce a new path, especially if the expected content is just like below (excerpt from "")? Isn't the JWS header parameter (RFC 7515 ) like below sufficient?
(For the record, I repeat my answer I gave on Slack and add more context) The jku header is not sufficient for the intended purpose. The purpose of the well-know endpoint is to establish a stable issuer identifier independent of the jwks location. This issuer identifier can be used in other structures to establish trust, e.g. it can be added to trusted lists (verifier end or trusted 3rd party). Additionally, it fits nicely with the other well-known locations, like openid-credential-issuer and oauth-authorization-server. So the issuer can distribute the role specific metadata in different location residing under the same issuer identifier.