Code change:
4. <del> This specification defines the JWT Issuer Metadata to retrieve the JWT Issuer Metadata configuration of the JWT Issuer of the JWT.  The JWT Issuer is identified by the </del> <ins> This section defines encoding, validation and processing rules for presentations of SD-JWT VCs. 4.1. If the presentation of the SD-JWT VC includes a Key Binding JWT, the Key Binding JWT MUST adhere to the rules defined in Section 5.3 of I- D.ietf-oauth-selective-disclosure-jwt. </ins> <del> claim in the JWT.  Use of the JWT Issuer Metadata is OPTIONAL. </del> <ins> The Key Binding JWT MAY include addtional claims which, when not understood, MUST be ignored by the Verifier. 4.2. The following is a non-normative example of a presentation of the SD- JWT shown above including a Key Binding JWT: </ins> <del> JWT Issuers publishing JWT Issuer Metadata MUST make a JWT Issuer </del> <ins> In this presentation, the Holder provides only the Disclosure for the claim . Other claims are not disclosed to the Verifier. The following example shows a presentation of a (different) SD-JWT without a Key Binding JWT: 5. This specification defines the JWT VC Issuer Metadata to retrieve the JWT VC Issuer Metadata configuration of the Issuer of the SD-JWT VC. The Issuer is identified by the claim in the JWT.  Use of the JWT VC Issuer Metadata is OPTIONAL. Issuers publishing JWT VC Issuer Metadata MUST make a JWT VC Issuer </ins> Metadata configuration available at the path formed by concatenating the string

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."