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: What if one server behaves as both an authorization server and a credential issuer? Should the authorization server publish the same content at both and ? Should intermediate authorities and trust anchors of OIDC Federation also provide ? Such a conflict is what I'm (and ordinary server implementers will be) concerned about. The latest draft of "" defines and jwt-issuer metadata. If so, there is no reason to prevent adding the same metadata to OID4VCI as well. Basically, I believe the metadata should be added to OID4VCI regardless of the discussion about jwt-issuer.
Potentially fixed by
NAME raises an important question that we need to address, at least by giving guidance. I don't have a good answer to that at the moment. Besides that, I don't see a need to rename to .
NAME correct me if I'm wrong. I understand you prefer over , right? And whether the key data will be added to the is a different topic (that's how I read your last statement). Please conform.
We will need more discussions on that topic. Potentially at IETF 117. This means, we won't be able to resolve this issue for our individual draft 03.
We had a small discussion on this and I created a new issue so we can separate between the 2 discussions overlapping here (name of the endpoint and intended usage).
Regarding the path, I have been losing confidence in my own opinion. As an implementer who has implemented numerous OAuth/OIDC specifications and been leading development of Authlete that holds the most OpenID certifications in the world, my intuition told me "The path should be avoided due to possible conflicts with other specifications." However, I haven't received as much support for my opinion as I expected. For now, I will implement my OID4VCI implementation using the path. Please let me withdraw my opinion.
I agree the position of NAME while in the italian solution we're implementing openid-credential-issuer as metadata within the .well-known/openid-federation endpoint, according to OpenID Federation 1.0. This doesn't prevent to include also a jwt-issuer metadata type but there's the decision by our side to wait and the same time give evidence of our implementation to help the consolidation of the vc-jwt-issuer specs
NAME An off-topic question out of curiosity.