jiebi/CodeConvo huggingface dataset:
Code change:
1. <del> The JSON-based content of signed JSON Web Token (JWT) as defined in RFC7515 is secured against modification using digital signatures.  A consumer of a JWT that has checked the document's signature can safely assume that the content has not been modified.  However, anyone receiving a JWT can read the actual content of the document if not encrypted. </del> <ins> The JSON-based claims in a signed JSON Web Token (JWT) RFC7519 document are secured against modification using JSON Web Signature (JWS) RFC7515 digital signatures.  A consumer of a signed JWT document that has checked the document's signature can safely assume that the contents of the document have not been modified.  However, anyone receiving an unencrypted JWT can read all of the claims and likewise, anyone with the decryption key receiving an encrypted JWT can also read all of the claims. </ins> This document describes a format for JWT that supports selective disclosure (SD-JWT) which would enable sharing only subset of the

Related discussion:
text: We are discussing whether there's really a case where we need to hide the names. In most cases, you'll need to reveal info about the issuer and the schema.
Yup. And once you reveal info about the issuer and the schema, there is no point in hiding the claim names in most cases. So, I am arguing that we do not need to hide them.
I agree. We can close this issue. Thank you!
I think we should add the rationale why we are not hiding claim names. leaving a note for self to do a PR on this.
Code change:
usual requirements for classic CONNECT proxies in this HTTP version (see RFC9113 and RFC9114). <ins> 3.3. A templated TCP proxy has an unambiguous origin of its own.  Origin- scoped HTTP header fields such as "Alt-Svc" RFC7838 and "Strict- Transport-Security" RFC6797 apply to this origin when they are associated with a templated TCP proxy request or response. </ins> 4. This section discusses some behaviors that are permitted or

Related discussion:
text: After looking harder, I found that RFC 9110 that a proxy "is usually identified by an "http" or "https" URI". I'm not sure that's 100% accurate, but it conveniently resolves the wording problem, and who am I to argue with RFC 9110?
At the moment, section 1.2 (Problems) start with the following sentence: I totally get what it tries to say, but it is confusing if not incorrect. states that a CONNECT request is handled by a "proxy" and the target specified by the "host:port" tuple is the "origin." Therefore, HTTP CONNECT proxies are not identified by an origin. Rather, they are identified by the user's proxy settings. I think we'd better update the problem statement, and might also consider pointing out that the definition of "origin" will be different between CONNECT and connect-tcp (or use different terms to identify the CONNECT target and the entity that creates a tunnel in order to avoid confusion, maybe?).
PS. Practical example showcasing the side effect of the change to the definition is that the way to authenticate becomes different; when a client tries to establish a CONNECT tunnel with authentication, it uses "proxy-authorization" header, whereas when a client tries to establish a connect-tcp tunnel, it uses "authorization." I think it's worth noting.
I'm realizing that this spec has the opportunity to fix the origin issues present in regular CONNECT. While we're there it'd be great to clarify how connect-tcp interacts with Alt-Svc because it's unclear for CONNECT. I sent some more about why it's unclear for CONNECT.
Thanks for the discussion!
Code change:
StartGroup: The start Group ID. <del> StartObject: The start Object ID, plus 1.  A value of 0 means the entire group is requested. </del> <ins> StartObject: The start Object ID. </ins> EndGroup: The end Group ID, plus 1.  A value of 0 means the subscription is open-ended.

Related discussion:
text: I'm not totally sure what to do with the special value of 0 for StartObject and EndObject. If StartObject == 0, that's requesting the whole group. But if it's 1, that maps to a first object of zero, which is also consistent with requesting the whole group. For EndObject, the special value makes sense, because the subscriber might not know how many objects there are. There's also the error case where StartObject == 0 and EndObject != 0, or the reverse. IMO it would make more sense for EndObject to have the special value at zero, but not StartObject.
You're correct, this was an editorial error on my part. I did not intend to make StartObject have a special value.
Code change:
the resource identifier URL it is using as the prefix for the metadata request exactly matches the value of the "resource" metadata value in the protected resource metadata document received by the <del> client. </del> <ins> client, as described in PRConfigurationValidation. </ins> 7.4.

Related discussion:
text: Cc NAME
Section 3.3 should reference the attack described in section 7.3 URL And evaluate whether it makes sense to add a back reference from 7.3 to 3.3.
Looks good to me.
Code change:
Common Name: Token type for Unsigned JSON Object <del> Change Controller: IESG </del> <ins> Change Controller: IETF </ins> Specification Document: Section unsigned-json-subject-token- type of this specification

Related discussion:
text: We received the following email from IANA: Before the IETF meeting, we check working group agendas for documents with IANA-related issues. We have notes about the current version of this document: URL 1) We haven’t been asked to update the change controller field for existing registrations, but the IESG prefers that the IETF be listed as the change controller for new registrations. 2) A few minor editorial notes about the media type registration: The applicant name and email field should be omitted. Where those fields appear on the IANA website, they’re an artifact of the web form, and not officially part of the template. We’re gradually removing those fields from existing registrations.The media type registrations don’t appear to include a change controller field.The quotation marks around type, subtype, and required and optional parameters can be removed, as should the “(RFC 2046)” after “application.” Finally, please note that RFC 6838 recommends asking the mailing list for an informal review. If you have any questions, just let us know. If you'd like to talk in person, you can find us next to the RFC Editor's table from Monday through Thursday. You can also request another review at any time by contacting us at . For more information about IANA Considerations section requirements, please see URL Best regards, Amanda Baber IANA Operations Manager
Code change:
Client certificates are not meaningful for URLs with the "http" scheme, and therefore clients creating new TLS connections to alternative services for the purposes of this specification MUST NOT <del> present them.  Established connections with client certificates MAY be reused, however. </del> <ins> present them.  Connections that use client certificates for other reasons MAY be reused, though client certificates MUST NOT affect the responses to requests for "http" resources. </ins> 2.1.

Related discussion:
text: We've been circling an answer to this for a while. The entire gamut of possible solutions is broad, and we haven't had much luck in reaching clarity here. One the one end of the scale, it should be perfectly OK to send a request for an origin over an authenticated TLS connection. But we still have the (entirely legitimate) concern there is that some servers might get themselves confused by this. The other end of the scale is the bells and whistles JSON stuff. NAME seemed OK with this based on his implementation experience, but it is a little complicated. We found too many corner cases for me to be happy that it implementations wouldn't end up busted. And now that we insist on authentication for the server, many of the features didn't make sense. We've also considered an HTTP/2 setting. That's appealing, but it does limit the applicability a little. This change aims more to the conservative end of that scale. It keeps the resource, but simplifies it, reducing it to a flat list of origins. The client only needs to acquire this from the authenticated server. This doesn't defend against Alt-Svc attacks mounted by attackers with the ability to both send header fields and run an authenticated server, but we're in a very strange place if this is the sort of capabilities we ascribe to our attackers in our threat models. I've explicitly added here. I believe that's reflective of consensus, but that part is easy to revert. The text about client certificates is now clearer.
Code change:
The server session header consists of just a SETTINGS that MUST be the first frame the server sends in the HTTP/2.0 session. <del> In order to avoid unnecessary latency, clients are permitted to send </del> <ins> To avoid unnecessary latency, clients are permitted to send </ins> additional frames to the server immediately after sending the client session header, without waiting to receive the server session header. <del> However, it is important to note that the server session header </del> <ins> It is important to note, however, that the server session header </ins> SETTINGS frame might include parameters that necessarily alter how a <del> client is expected to communicate with the server. </del> <ins> client is expected to communicate with the server.  Upon receiving the SETTINGS frame, the client is expected to honor any parameters established. </ins> Clients and servers MUST terminate the TCP connection if either peer does not begin with a valid session header.  A GOAWAY MAY be omitted

Related discussion:
text: Same edits as before with additional tweaks based on feedback. I've adjusted the formatting on my edits to match the current styling as much as possible (must... resist... OCD... tendencies ;-) ...). Specific edits can be reviewed in the commit log.
Careful, you could end up with a new job if you keep this up.
Code change:
the intended priority to the client by including the Priority field in a PUSH_PROMISE or HEADERS frame. <ins> 9.1. An intermediary serving an HTTP connection might split requests over multiple backend connections.  When it applies prioritization rules strictly, low priority requests cannot make progress while requests with higher priorities are inflight.  This blocking can propagate to backend connections, which the peer might interpret as a connection stall.  Endpoints often implement protections against stalls, such as abruptly closing connections after a certain time period.  To reduce the possibility of this occurring, intermediaries can avoid strictly following prioritization and instead allocate small amounts of bandwidth for all the requests that they are forwarding, so that every request can make some progress over time. Similarly, servers SHOULD allocate some amount of bandwidths to streams acting as tunnels. </ins> 10. Transport protocols such as TCP and QUIC provide reliability by

Related discussion:
text: This PR talks about the server-side recommendation discussed in URL
This PR really just documents an existing consideration that was quielty overlooked, so I think it's good to merge whenever we feel like
Agreed. Let's merge and see.
Code change:
underlying credentials ensures their confidentiality. When client authentication is not possible, the authorization server <del> SHOULD employ other means to validate the client's identity -- for </del> <ins> SHOULD employ other means to validate the client's identity - for </ins> example, by requiring the registration of the client redirect URI or enlisting the resource owner to confirm identity.  A valid redirect URI is not sufficient to verify the client's identity when asking for

Related discussion:
text: uses the ::boilerplate macro of URL
I'm not sure what I'm doing wrong but when I try this I get an error: I'm using kramdown-rfc2629 version 1.4.3
fixed in URL NAME
Friendly reminder ;)
PTAL
Code change:
When generating a conditional request for validation, a cache starts with either a request it is attempting to satisfy, or -- if it is initiating the request independently -- it synthesises a request <del> using a stored response by copying the method, request-target, and </del> <ins> using a stored response by copying the method, target URI, and </ins> request header fields identified by the Vary header field caching.negotiated.responses.

Related discussion:
text: NAME please review.
Roy noticed that we use a special meaning of "invalidate" and then define it pretty casually below. This can be improved.
Code change:
If one or more encodings have been applied to a representation, the sender that applied the encodings MUST generate a Content-Encoding header field that lists the content codings in the order in which <del> they were applied.  Additional information about the encoding parameters can be provided by other header fields not defined by this specification. </del> <ins> they were applied.  Note that the coding named "identity" is reserved for its special role in , and thus SHOULD NOT be included. Additional information about the encoding parameters can be provided by other header fields not defined by this specification. </ins> Unlike Transfer-Encoding (field.transfer-encoding), the codings listed in Content-Encoding are a characteristic of the

Related discussion:
text: It might be worth checking that clients indeed treat it the same as an unknown value.
That's an interesting question as well; but it seems to be orthogonal to this issue. Handling content codings is tricky (such as wrt ordering, repetition, and unknown encodings), It would indeed be good to have tests.
-> move req into field definitions
fixed by
Code change:
can be a simple object with claim names mapped to hash digests over the claim values with unique random salts: <ins> The claim name ( ) is an optional </ins> can also be nested deeper to capture more complex objects, as will be shown later.

Related discussion:
text: Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT
Code change:
The header fields in PUSH_PROMISE and any subsequent CONTINUATION frames MUST be a valid and complete set of HttpRequest.  The server <del> MUST include a method in the </del> <ins> MUST include a method in the " </ins> <del> pseudo-header field that is safe and cacheable.  If a client receives a PUSH_PROMISE that does not include a complete and valid set of header fields or the </del> <ins> " pseudo-header field that is safe and cacheable.  If a client receives a PUSH_PROMISE that does not include a complete and valid set of header fields or the " </ins> <del> pseudo-header field identifies a method that is not safe, it MUST </del> <ins> " pseudo-header field identifies a method that is not safe, it MUST </ins> respond on the promised stream with a StreamErrorHandler of type PROTOCOL_ERROR.

Related discussion:
text: I had to add to one use of :authority.
and subsequent: Please note that, per the rest of this cluster of documents, we have placed the terms beginning with a colon (":method", ":scheme", etc.) in double quotes where they appear in running text. Please review, and let us know any objections.
Code change:
4.5. The SD-JWT and the SD-JWT-R can be combined into one document using <ins> period character </ins> as a separator (here for Example 1):

Related discussion:
text: Some minor edits: consistency of hyphenation in base64url-encode(d) use transaction instead of use case in one place because selective might be needed or not within one use case, depending on the interaction with RP explicitly called out period character to avoid misinterpreting as missing word some typos
changed six . separated to four per Christian's separate comment
What did I miss? The presentation should be six dot separated elements. Three for the SD-JWT, three for the SD-JWT-R.
Why would you need to merge both? I don't understand the proposed flow between issuer, holder, and verifier; perhaps a data flow section would help. I would think the holder gets a 3+1 part JWS with SVC (which can be -concatenated). Then all you need to present to a verifier is the same data, along with some user proof key signature if the JWT is bound to a user key (for which a property is added in the SD-JWT-R, if I understood correctly; more details would be helpful here).
creating a separate issue on six vs four period separated elements to merge this editorial PR
LGTM
Code change:
requiring prior update of deployed intermediaries. All defined header fields ought to be registered with IANA in the <del> "Message Headers" registry. </del> <ins> "HTTP Header Field Name" registry. </ins> 4.1.3.

Related discussion:
text: For
I believe the registry URI should actually say "http-header-fields". Can I change that?
The text might be confusing to IANA as the registry does not exist yet.
Code change:
browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE. <del> 11.3. </del> <ins> 11.4. </ins> The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side-channel disclosing

Related discussion:
text: Introduced the phrase in the end of the Section 8.1 on Verifying the SD-JWT for
Fair question. But I did add this one mention of the term in the location that NAME requested it in URL And it was already used in the text at the end of . And the just merged URL sprinkled in a few casual uses of it too. So I think it's sufficient enough. Also we have a fair number of kinda similar terms/phrases that are used in the doc but not formally introduced in the the terminology section. Which I think is fine. But putting this one there might be somewhat inconsistent and beg the question about other similar terms/phrases being there too.
We had the discussion in SD-JWT VC how to refer to the dehydrated (or maybe hydrated) result (Issuer-signed JWT payload) of the . It would help if we could give it a name to allow us to be more precise in other specs that are building on top of SD-JWT. The discussion occurred when adding the Schema for SD-JWT VCs that uses that result of the SD-JWT processing section to match the JSON schema against: URL We also have another issue that asks for an example of the result as well which would benefit from giving it a defined name: URL
Perhaps you can also confirm that this result in fact contains things like , , etc., and would only remove , , .
I was typing the following over in when it closed out from under me in favor of this issue.
why is not good enough? (in any case, would really like to avoid using hydrated/dehydrated since that term is kind of confusing and i used for something related but different in ISO I think)
I don't think that helps when referencing from another spec such as SD-JWT VC. The text you are referring to is from 8.3 Verification by the Verifier which is not general enough. I'd suggest to add one sentence to URL, e.g., "7. Let xzy be the processed result of the asdf algorithm ..." ... and make xzy a defined term, so it can be referenced. I don't think we can use from SD-JWT VC since it is not really defined in SD-JWT. If you don't define it in SD-JWT, we will define it in SD-JWT VC which I prefer not to.
Btw.
Code change:
browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE. <del> 11.3. </del> <ins> 11.4. </ins> The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side-channel disclosing

Related discussion:
text: if you call it processed payload, that is fine by me but it should be added to 8.1.
+ 1000000000% !
Defining terms is good. Dehydrated/hydrated would be bad. ;-)
PR URL has a small addition to sec 8.1 for this
agree to common law definition
Code change:
browser or end up in web server logs, the SD-JWT SHOULD be encrypted using JWE. <del> 11.3. </del> <ins> 11.4. </ins> The use of decoy digests is RECOMMENDED when the number of claims (or the existence of particular claims) can be a side-channel disclosing

Related discussion:
text: Despite or maybe in light of some recentish discussion on the mailing list, the topic seems like it deserves more prominent placement.
Code change:
A list of error codes is included in ErrorCodes. <ins> It is possible that an endpoint will encounter frames that would cause multiple errors.  Implementations MAY discover multiple errors during processing, but they SHOULD report at most one stream and one connection error as a result. The first stream error reported for a given stream prevents any other errors on that stream from being reported.  In comparison, the protocol permits multiple GOAWAY frames, though an endpoint SHOULD report just one type of connection error unless an error is encountered during graceful shutdown.  If this occurs, an endpoint MAY send an additional GOAWAY frame with the new error code, in addition to any prior GOAWAY that contained NO_ERROR. If an endpoint detects multiple different errors, it MAY choose to report any one of those errors.  If a frame causes a connection error, that error MUST be reported. </ins> 5.4.1. A connection error is any error that prevents further processing of

Related discussion:
text: Thanks NAME ready for re-review I think.
Oh, you proposed changing "handling" to "reporting": did you want to do that pervasively in this document?
Let's take that up separately.
Ready for merge I think.
I agree, but as this is substantive, let's run this by the working group.
As there is a draft deadline, I will open an issue for my niggle, and ask for forgiveness rather than permission.
It's not clear to me from RFC 7540 how an endpoint should behave upon receiving a frame that is erroneous in more than one way. For example, suppose a server receives the following frame when it has stream id 1 in half-closed (remote) state: According to §4.2, the frame "MUST be treated as a connection error" and the server "MUST send an error code of FRAMESIZEERROR" (because the length of 4 "is too small to contain mandatory frame data", namely the weight and header block fragment fields); According to §5.1, the server "MUST respond with a stream error (Section 5.4.2) of type STREAMCLOSED" (because a frame "other than WINDOWUPDATE, PRIORITY, or RSTSTREAM" was received for a stream that is in "half-closed (remote)" state); and According to §5.3.1, the server "MUST treat this as a stream error (Section 5.4.2) of type PROTOCOLERROR" (because "a stream cannot depend on itself"). That is to say, according to the RFC, the server MUST (at very least) respond to this frame with one GOAWAY frame and two RSTSTREAM frames. However, sending all these frames would violate other requirements: According to §5.4.1, "after sending the GOAWAY frame for an error condition, the endpoint MUST close the TCP connection". This obviously prevents other frames from being sent. According to §5.1, sending a RSTSTREAM transitions the stream to closed state, in which "an endpoint MUST NOT send frames other than PRIORITY". This prevents any further RSTSTREAM frames from being sent for the same stream.