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