jiebi/CodeConvo huggingface dataset:
Code change:
6.1. <del> The JWT Issuer Metadata configuration is retrieved from the JWT </del> <ins> The JWT VC Issuer Metadata configuration is retrieved from the JWT VC </ins> Issuer by the Holder or Verifier.  Similar to other metadata endpoints, the URL for the retrieval MUST be considered an untrusted value and could be a vector for Server-Side Request Forgery (SSRF) attacks. <del> Before making a request to the JWT Issuer Metadata endpoint, the </del> <ins> Before making a request to the JWT VC Issuer Metadata endpoint, the </ins> Holder or Verifier MUST validate the URL to ensure that it is a valid HTTPS URL and that it does not point to internal resources.  This requires, in particular, ensuring that the host part of the URL does

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."
Code change:
6.1. <del> The JWT Issuer Metadata configuration is retrieved from the JWT </del> <ins> The JWT VC Issuer Metadata configuration is retrieved from the JWT VC </ins> Issuer by the Holder or Verifier.  Similar to other metadata endpoints, the URL for the retrieval MUST be considered an untrusted value and could be a vector for Server-Side Request Forgery (SSRF) attacks. <del> Before making a request to the JWT Issuer Metadata endpoint, the </del> <ins> Before making a request to the JWT VC Issuer Metadata endpoint, the </ins> Holder or Verifier MUST validate the URL to ensure that it is a valid HTTPS URL and that it does not point to internal resources.  This requires, in particular, ensuring that the host part of the URL does

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.
Code change:
6.1. <del> The JWT Issuer Metadata configuration is retrieved from the JWT </del> <ins> The JWT VC Issuer Metadata configuration is retrieved from the JWT VC </ins> Issuer by the Holder or Verifier.  Similar to other metadata endpoints, the URL for the retrieval MUST be considered an untrusted value and could be a vector for Server-Side Request Forgery (SSRF) attacks. <del> Before making a request to the JWT Issuer Metadata endpoint, the </del> <ins> Before making a request to the JWT VC Issuer Metadata endpoint, the </ins> Holder or Verifier MUST validate the URL to ensure that it is a valid HTTPS URL and that it does not point to internal resources.  This requires, in particular, ensuring that the host part of the URL does

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.
Code change:
6.1. <del> The JWT Issuer Metadata configuration is retrieved from the JWT </del> <ins> The JWT VC Issuer Metadata configuration is retrieved from the JWT VC </ins> Issuer by the Holder or Verifier.  Similar to other metadata endpoints, the URL for the retrieval MUST be considered an untrusted value and could be a vector for Server-Side Request Forgery (SSRF) attacks. <del> Before making a request to the JWT Issuer Metadata endpoint, the </del> <ins> Before making a request to the JWT VC Issuer Metadata endpoint, the </ins> Holder or Verifier MUST validate the URL to ensure that it is a valid HTTPS URL and that it does not point to internal resources.  This requires, in particular, ensuring that the host part of the URL does

Related discussion:
text: If an authorization server / OpenID provider and a credential issuer are hosted on the same server, the payload of the entity configuration published at of the server contains the following, right?
Hey NAME I'm sure that you meant The answer Is yes, even if we have used a snake case like here URL It's still an initial draft without an official release, several editorials and implementation compromises needs to be resolved but the most of the work Is there, feelfree to open issue for discussion here URL
To make progress with this. Are folks comfortable with renaming "JWT Issuer Metadata"? And if so, would folks be fine with "SD-JWT VC Issuer Metadata" or "VC Issuer Metadata"? I like "VC Issuer Metadata" better because it is more future looking. What do folks think? cc NAME NAME NAME NAME NAME After we agreed on a new name I'd ask NAME to update PR .
Agree that "jwt-issuer" is too general and am in favor of a renaming.
Code change:
receives an unexpected stream identifier MUST respond with a ConnectionErrorHandler of type PROTOCOL_ERROR. <del> The first use of a new stream identifier implicitly closes all streams in the "idle" state that might have been initiated by that peer with a lower-valued stream identifier.  For example, if a client sends a HEADERS frame on stream 7 without ever sending a frame on stream 5, then stream 5 transitions to the "closed" state when the first frame for stream 7 is sent or received. </del> <ins> A HEADERS frame will transition the client-initiated stream identified by the stream identifier in the frame header from "idle" to "open".  A PUSH_PROMISE frame will transition the server-initiated stream identified by the "Promised Stream ID" field in the frame payload from "idle" to "reserved".  When a stream transitions out of the "idle" state, all streams that might have been initiated by that peer with a lower-valued stream identifier are implicitly transitioned to "closed".  That is, an endpoint may skip a stream identifier, with the effect being that the skipped stream is immediately closed. </ins> Stream identifiers cannot be reused.  Long-lived connections can result in an endpoint exhausting the available range of stream

Related discussion:
text: This is a first stab at . I've gone for a minimal change here, simply clarifying that only HEADERS and PUSHPROMISE frames have the effect of implicitly closing streams. While I was writing this I did have a question that may need to be raised on-list: do HEADERS and PUSHPROMISE only implicitly close streams if they are accepted? That is, if a client sends a HEADERS frame that triggers a stream error, does that HEADERS frame still implicitly close all streams with a lower stream ID that are in the "idle" state? This may also be worth clarifying.
Like it. Take the first, maybe take the second, and we can merge this one.
Code change:
9.2. Requests without a payload body can still send a "Digest" field <del> applying the digest algorithm to an empty representation. </del> <ins> applying the digest-algorithm to an empty representation. </ins> As there is no content coding applied, the "sha-256" and the "id-sha- 256" digest-values in the response are the same.

Related discussion:
text: is preliminary to Consistently use instead of . In case we need to further focus on the value, we can say or . Looking at "content-coding" vs "content coding" in URL I think that this choice makes the document more readable.
Code change:
this attack since the Access Token may remain valid even after the Txn-Token has expired. <del> 9.4. </del> <ins> 9.3. </ins> How requesting clients authenticate to the Transaction Token Service is out of scope for this specification.  However, if using the

Related discussion:
text: See meeting notes here where we agreed to remove this: URL
The language in section needs to refer to the RFC and specify how to use them with Txn-Tokens
Code change:
For field names, byte values that are not permitted in an HTTP field name cause the message to be invalid; see HTTP for a definition of <del> what is valid and invalid for handling of invalid messages. Field names and values MUST be constructed and validated according to the rules of H2.  A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed (H2) as invalid; see invalid. </del> <ins> what is valid and invalid for handling of invalid messages.  A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed according to H2 as invalid; see invalid. </ins> The same field name can be repeated in multiple field lines; see HTTP for the semantics of repeated field names and rules for combining values. <ins> Fields that relate to connections (HTTP) cannot be used to produce the effect on a connection in this context.  These fields SHOULD be removed when constructing a binary message.  However, they do not cause a message to be invalid (invalid); permitting these fields allows a binary message to capture the content of a messages that are exchanged in a protocol context. </ins> Like HTTP/2, this format has an exception for the combination of multiple instances of the "Cookie" field.  Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon

Related discussion:
text: The HTTP/2 rules are related to field value validation, so move them there. The rules about Connection fields are not necessary, but it won't hurt to be clearer.
the rules of Section 8.2.1 of [H2]. A recipient MUST treat a message that contains field values that would cause an HTTP/2 message to be malformed (Section 8.1.1 of [H2]) as invalid; see Section 4. Those references are doing a lot of work -- but does it also include 8.2.2? I.e., are and friends allowed? It's ambiguous, because the text implies all things that make it malformed, but only points to one source.
No point duplicating that work, but I agree that it might be unclear as stated. Does this split make it clearer? I'll make a PR with those changes in context. (I think that the latter is consistent with what you and NAME are discussing on-list, though I need to spend a bit more time on understanding that.)
I think it does the job, indeed!
Code change:
the reserved port for SMTP traffic; if allowed, that could trick the proxy into relaying spam email.  Proxies that support CONNECT SHOULD restrict its use to a limited set of known ports or a configurable <del> whitelist of safe request targets. </del> <ins> list of safe request targets. </ins> A server MUST NOT send any

Related discussion:
text: Without getting into the current politics and history of the term, there are two instances of this term in SEMANTICS that don't appear to contribute substantial value versus using a less loaded choice. : Here, "list" seems sufficient. Perhaps "sites that have been explicitly permitted"?
Good catch. I thought I already checked for those when I replaced man-in-the-middle.
For a direct replacement both safelist and allowlist have seen some uptake.
Code change:
A subscription causes the publisher to send newly published objects for a track.  A subscriber MUST NOT make multiple active subscriptions for a track within a single session and publishers <del> SHOULD treat this as a protocol violation. </del> <ins> SHOULD treat this as a protocol violation.  The only objects prior to the current object that can be requested are those in the current group. </ins> The subscriber specifies a filter on the subscription to allow the publisher to identify which objects need to be delivered.

Related discussion:
text: Changes SUBSCRIBE so you can't go back farther than the current Group with any of the filter modes. If a SUBSCRIBE tries to go back farther, it is closed with a SUBSCRIBE_OK. Alternatively, instead of failing the subscription, we could specify that the SUBSCRIBE will be truncated and start at the beginning of the current group.
LGTM.
LGTM .. I had couple of questions on error condition to be MUST instead of SHOULD.
Code change:
A client that prefers server push can use the following workflow: <del> 4.1. </del> <ins> 4.2. </ins> The HTTP version a "https" connection uses is negotiated between client and server using the TLS ALPN extension, described in RFC9113

Related discussion:
text: NAME Med, I have migrated the draft to markdown format (see ). The changes are merged as well. I am taking a complete pass of the markdown before merging it to the main branch.
Thank you, NAME Looking forward merging the new branch into the main.
Code change:
presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C. <del> 2.4.5. </del> <ins> 2.4.4. </ins> The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in

Related discussion:
text: and minor other little fixes to fix issues , , an editor's draft preview of these changes here: URL
says this: However, if the authorization grant is a JWT (which it always should be, but see for details), then defines the grant type of the request to be: The other implication of this is that the only way to distinguish the type of JWT assertion is in the JWT itself, which can be done using the field in the JWT header.
Per is an "identifier [...] for the representation of the issued security token" and I think it's admittedly a bit odd but perfectly reasonable to use the URN of the grant type that the token is intended for as the value conveying the representation that token.
With that said however, I do kinda think that'd it be better to limit to JWT authz grant only (a la ) and not tie the issuedtokentype to the grant type.
My point was more about the grant type of the request as described by RFC7523. access token request as defined in of the OAuth Assertion Framework ] with the following specific parameter values and encodings. So if the request contains a JWT, then the grant type value has to be . Which means according to Section 2.4.3 of this spec the issuedtokentype "SHOULD" be , which is silly. So my proposal is to remove the "and SHOULD be passed into the assertion request" part, so that issuedtokentype can be a value that makes sense, and use as the grant type. As I said in the original comment, the implication is then that the JWT header itself would need to include something that indicates the type of JWT it is, otherwise all token exchange requests look the same.
I might argue that it's not actually silly but I won't b/c it'll be moot as PR addresses this with the removal of the "issuedtokentype parameter in the response indicates the type and SHOULD be passed into the assertion request" URL
issuedtokentype (a required parameter of a token exchange response URL) is missing from the example response at URL
NAME can you prepare a PR with an updated example?
Code change:
presenting the authorization grant it received from the client in Domain A to the authorization server for Domain C. <del> 2.4.5. </del> <ins> 2.4.4. </ins> The example belows shows the message invoked by the client in trust domain A to perform token exchange with the authorization server in

Related discussion:
text: example would be fixed by PR
Feedback from Brian Campbell Conceptually having "flexibility for authorization servers to change format and content" sounds nice but I can't help but wonder if that flexibility is actually useful and if this document wouldn't be better served and more straightforward using just JWT authz grants from 7523 (rather than being abstract about using 7521 and the very brief mention of SAML w/out a 7522 ref).
I agree that limiting the authorization grant format to JWT is useful. In fact you've almost already done that by adding the validation to the processing rules here: URL
As discussed in the meeting with the editors and Aaron, we will make the use of JWT explicit.
PR would limit the authorization grant format to RFC7523 JWT
Code change:
7.5. A workload within a call chain may request the Transaction Token <del> Server to replace a Txn-Token. </del> <ins> Service to replace a Txn-Token. </ins> Workloads MAY request replacement Txn-Tokens in order to change (add to, remove or modify) the asserted values within a Txn-Token.

Related discussion:
text: Update Transaction Token Service responsibility when creating replacement tokens. Also contains minor changes for consistent language. Related URL
Code change:
and discarding the content for a HEAD request, since HEAD is usually requested for the sake of efficiency. <del> A client SHOULD NOT generate content in a HEAD request.  Content received in a HEAD request has no defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (request.smuggling). </del> <ins> Although request message framing is independent of the method used, content received in a HEAD request has no generally defined semantics, cannot alter the meaning or target of the request, and might lead some implementations to reject the request and close the connection because of its potential as a request smuggling attack (request.smuggling).  A client SHOULD NOT generate content in a HEAD request unless it is made directly to an origin server that has previously indicated, in or out of band, that such a request has a purpose and will be adequately supported.  An origin server SHOULD NOT rely on private agreements to receive content, since participants in HTTP communication are often unaware of intermediaries along the request chain. </ins> The response to a HEAD request is cacheable; a cache MAY use it to satisfy subsequent HEAD requests unless otherwise indicated by the

Related discussion:
text: Actually it is even already used and documented: the broadly used ElasticSearch explicitly documents how to perform JSON search requests using : URL So please let's stick to "SHOULD NOT" with Julian's "unless negotiated via other means" or something like this, instead of suddenly adding dangerous exceptions to the protocol and breaking interoperability between already deployed and working components.