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: An example with concrete values would be "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 ()." It might be beneficial to define as the ultimate fallback general-purpose option for locating the public key required to verify the JWT's signature (not as the sole rule for every VC to follow), especially when it is challenging to reach a consensus on a single method within a limited timeframe among the following. starting with Others However, maybe I'm still missing something, sorry.
The well-known endpoint is indeed also a stable identifier. But it depends on a certain well-known location, i.e. different well-known locations are different identifiers. I'm looking for a stable identifier for the issuer that works across .well-known locations and is not bound to a certain key. That's pretty simple with well-known locations as the iss value can be extended by several different .well-known locations, but the identifier is still the same, right? So for example, the issuer could use the jwt-issuer mechanism share keys and (at the same time) be part of an OpenID Federation as shown in the following: /.well-known/jwt-issuer /.well-known/openid-federation The same issuer's URL could also at the same time used in an external data structure at the verifier or at a trusted 3rd party. Effect: I can establish trust in a certain issuer/entity/server that works across different roles/perspectives. I hope that explains better.
this would allow an entity to use different keys to sign ID Tokens, VCs, access tokens, etc.
my question is how to specify different capabilities for different metadata protocols? this is an example in oidc federation URL here we're saying, this is the wallet provider metadata, where multiple metadata/roles cohexists in a single .well-known how jwt-issuer endpoint achieves this?
If the JWS header indicates that the JWT is a VC (e.g. ), the following paths also can work. (defined in OID4VCI) (proposed by this issue) I'd like to understand why the generic name is chosen. The generic name is subject to interpretation where authorization servers, relying parties and any JWT-issuing systems should provide to expose their metadata (at least or ) as the last resort.