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: And not to forget, this well-known location also could work well with openid-federation. Moreover, any additional VC issuer metadata we will come across can be added to this endpoint. BTW: I think a dedicated issue would be the better place for this discussion.
I am actually in favor of . This mechanism is meant to be general enough to be used with not just a 'verifiable credential'. and I don't think anyone would think to use with ID Tokens and Access Tokens, UserInfo responses , etc. that are JWTs.
I understand your point NAME below my thoughts Why defining jwt-issuer for general purpose in a spec that's specialized for VC? Requirement: definition of a specs in IETF for general purpose JWT Issuer metadata (enabling client metadata, that today is only available in openid-federation...) I agree that jwt-vc-issuer semantically collides with credential-issuer, and we should not do collisions why we can't use .well-known/openid-federation? Federation entity discovery is required for the entities that builds trust chain according to the federation specs, nothing prevent to publish all the metadata of all thw "JWT-role" in a single metadata, that should not be signed if request (content-type) asks it in plain text I suggest to use to consolidate a unique way to publish all the metadata types and roles of an entity. coming back to the name change proposal. Why we use the term since the metadata contains also general capabilities not related to the issuance? in a more general purpose way, wouldn't it be a ? then the question: if that entity has more functionalities and roles, being at the same time a RP and a AS, how the metadata should be organized? We've resolved this issue in openid-federation, with the below schema, where a RP can be also a OP, AS, Client, credential-issuer and so on: URL
I'm a little embarrassed, but to be honest, I still don't understand the reasoning. "A stable issuer identifier" is represented by the claim, not by the URL of the well-known endpoint, isn't it? A possible reason for necessity of a well-known path I guess is "to make sure that the host identified by the issuer identifier actually exists and is accessible, by forcing JWT verifiers to access a path under the domain."