jiebi/CodeConvo huggingface dataset:
Code change:
2.3.4. <del> In order to prevent mix-up attacks, clients MUST only process redirect responses of the authorization server they sent the respective request to and from the same user agent this authorization request was initiated with.  Clients MUST store the authorization server they sent an authorization request to and bind this information to the user agent and check that the authorization response was received from the correct authorization server.  Clients MUST ensure that the subsequent access token request, if applicable, is sent to the same authorization server.  Clients SHOULD use distinct redirect URIs for each authorization server as a means to identify the authorization server a particular response came from. </del> <ins> When an OAuth client can only interact with one authorization server, a mix-up defense is not required.  In scenarios where an OAuth client interacts with two or more authorization servers, however, clients MUST prevent mix-up attacks.  In order to prevent mix-up attacks, clients MUST only process redirect responses of the issuer they sent the respective request to and from the same user agent this authorization request was initiated with. See mixupcountermeasures for a detailed description of two different defenses against mix-up attacks. </ins> 2.3.5.

Related discussion:
text: Most of the text is copied from the security BCP and only slightly adjusted. I am not sure if 2.1 needs to contain the detailed description of mix-up attacks and variants (56b6b6cdcfccf30baa124d37597d18a7cecf032e) or if it would be sufficient to add mix-up mitigations (2d07d10b9787d3798fab0913ff67ea1cd2e29d89).
Thank you, in general we have been erring on the side of leaving the detailed discussion of the security considerations in the Security BCP, and only moving the mitigation recommendations in 2.1. Would you be able to remove the detailed description from this PR?
Finally had the time for this quick revert of my latest commit. Do you think the description of mix-up is fine now? Should we add a reference to the detailed description of mix-up attacks in the security BCP?
Thanks, I added a reference to the security BCP in that section
Code change:
The "public" response directive indicates that a cache MAY store the response even if it would otherwise be prohibited, subject to the <del> constraints of any other response directives present.  In other words, public explicitly marks the response as cacheable.  For example, public permits a shared cache to reuse a response to a request containing an Authorization header field (caching.authenticated.responses). </del> <ins> constraints defined in response.cacheability.  In other words, public explicitly marks the response as cacheable.  For example, public permits a shared cache to reuse a response to a request containing an Authorization header field (caching.authenticated.responses). Note that it is not necessary to add the public directive to a response that is already cacheable according to response.cacheability. </ins> <del> If no explicit freshness information is provided, the response is is heuristically cacheable (heuristic.freshness). </del> <ins> If no explicit freshness information is provided on a response with the public directive, it is heuristically cacheable (heuristic.freshness). </ins> 5.2.2.7.

Related discussion:
text: NAME see revision.
The language for and indicates that they override the rest of the caching model unconditionally; as discussed in , that is too broad. Also, is often used even though the message is still cacheable, because developers misunderstand its semantics.
The text in question for private: to any other cache directives present, even if the response would not otherwise be heuristically cacheable by a private cache. lists one or more field names, then only the listed fields are limited to a single user: a shared cache [...] &MAY; store the remainder of the response message without those fields. I think there are two problems here: 1) "subject to any other cache directives present" is too narrow; the requirements in 3. Storing Responses in Caches go far beyond cache directives (e.g., method and status code cache ability). 2) The second paragraph omits any such condition. I think this can be addressed by replacing the clause above with something like "subject to the other requirements in [ref to section 3]", and repeating it in the second paragraph. We'd also need to add to the list in section 3 (probably below .
For public, we have: response even if it would otherwise be prohibited, subject to the constraints of any other response directives present. In other words, public explicitly marks the response as cacheable. Similar to above, I think it should be "subject to the constraints defined in [ref to section 3]. A note like this would also help:
LGTM.
Code change:
Boolean values can be conveyed in Structured Fields. <del> When serialised in a textual HTTP field, a Boolean is indicated with </del> <ins> When serialized in a textual HTTP field, a Boolean is indicated with </ins> a leading "?" character followed by a "1" for a true value or "0" for false.  For example:

Related discussion:
text: There are currently some uses of "serialise" in place of the far more common "serialize", including one case that breaks the pattern of header names ("Serializing a List", "Serializing a Dictionary", "Serializing an Item", …, "Serialising a Date"). This PR also includes an analogous update of "summarises" to "summarizes" to increase the general pattern of American spellings.
Speaking Danglish myself, I am disqualified from having an opinion on this subject matter :-)
Despite my Australianised sensibilities, I see that 8941 was normalised to American spelling by the RFC Editor, and changing things now would introduce more diffs. Thanks for the PR.
Code change:
7.1. <ins> ToDo: add text explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT: - create a test suite that forces hash computation by the Verifiers, and includes negative test cases in test vectors - use only implementations/libraries that are compliant to the test suite - etc. 7.2. </ins> The SD-JWT MUST be signed by the issuer to protect integrity of the issued claims.  An attacker can modify or add claims if an SD-JWT is not signed (e.g., change the "email" attribute to take over the

Related discussion:
text: Would like to go with salted hashes based approach, since there has been a lot of feedback that "simplicity (of salted hases approach) is a feature". However, acknowledging , adding a text to the security considerations explaining mechanisms that should be adopted to ensure that verifiers validate the claim values received in SD-JWT-R by calculating the hashes of those values and comparing them with the hashes in the SD-JWT.
Code change:
Abstract This specification describes three CBOR data structures for primary <del> use in COSE envelopes.  A format for Merkle Tree Root Signatures with metadata, a format for Inclusions Paths, and a format for disclosure of a single hadh tree leaf payload (Merkle Tree Proofs). </del> <ins> use in COSE envelopes.  A CBOR encoding of Merkle Roots for use in COSE payloads.  A CBOR encoding of Inclusions Proofs for use in COSE unprotected headers.  A CBOR encoding of Consistency Proofs for use in COSE unprotected headers. </ins> 1.

Related discussion:
text: These changes focus this draft on the minimal definitions required to secure the data structures defined in RFC9162 using CBOR and COSE. Extraneous information has been removed. There is a wip implementation available here: URL There is a demo here: URL
LGTM!sry 4 the l8 approvalI recommend merging now
Code change:
7.2.1.2. <del> When sending the access token in the HTTP request entity-body, the client adds the access token to the request-body using the "access_token" parameter.  The client MUST NOT use this method unless all of the following conditions are met: </del> <ins> When sending the access token in the HTTP request payload, the client adds the access token to the request-body using the "access_token" parameter.  The client MUST NOT use this method unless all of the following conditions are met: </ins> The HTTP request entity-header includes the "Content-Type" header field set to "application/x-www-form-urlencoded". <del> The entity-body follows the encoding requirements of the "application/x-www-form-urlencoded" content-type as defined by HTML 4.01 W3C.REC-html401-19991224. </del> <ins> The payload follows the encoding requirements of the "application/ x-www-form-urlencoded" content-type as defined by HTML 4.01 W3C.REC-html401-19991224. </ins> <del> The HTTP request entity-body is single-part. </del> <ins> The HTTP request payload is single-part. </ins> <del> The content to be encoded in the entity-body MUST consist entirely of ASCII USASCII characters. </del> <ins> The content to be encoded in the payload MUST consist entirely of ASCII USASCII characters. </ins> The HTTP request method is one for which the request-body has defined semantics.  In particular, this means that the "GET" method MUST NOT be used. <del> The entity-body MAY include other request-specific parameters, in which case the "access_token" parameter MUST be properly separated from the request-specific parameters using "&" character(s) (ASCII code 38). </del> <ins> The payload MAY include other request-specific parameters, in which case the "access_token" parameter MUST be properly separated from the request-specific parameters using "&" character(s) (ASCII code 38). </ins> For example, the client makes the following HTTP request using transport-layer security:

Related discussion:
text: align terminology with RFC7231 term. I'd consider switching to httpbis-semantics URL
Hi NAME NAME it would be great to have some feedback on this PR. In case I could brush even more the spec to ensure compatibility with the ongoing HTTP work :)
Thanks! I'm working on this this week so I will take a look soon!
NAME let me know if you need more feedback ;)
This looks great. I'm not sure of the other implications of switching the references to draft-ietf-httpbis-semantics so we can discuss that in a new issue if you'd like.
Code change:
3.3. <del> Once the HTTP/2.0 connection is established, clients and servers can begin exchanging frames. </del> <ins> Once the HTTP/2.0 connection is established, endpoints can begin exchanging frames. </ins> 3.3.1. <del> HTTP/2.0 frames share a common base format consisting of an 8-byte header followed by 0 to 65535 bytes of data. </del> <ins> All frames share a common base format consisting of an 8-byte header followed by 0 to 65,535 octets of payload data. </ins> The fields of the frame header are defined as:

Related discussion:
text: As discussed in the interim... (I had previously submitted this in a batch against the Layering branch... redoing against the Master)
Looks good for the most part, consider the comments as advisory only.
Code change:
however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and submissions can certainly be executed in conjunction with other <del> attack vectors such as cross-site scripting. </del> <ins> attack vectors such as cross-site scripting or abuse of page redirections. Understanding how and when a request is considered same-site is also important in order to properly design a site for SameSite cookies. For example, if a top-level request is made to a sensitive page that request will be considered cross-site and SameSite cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive SameSite cookies.  Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn't include the appropriate cookies. </ins> Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are

Related discussion:
text: If we standardize different behavior for default vs explicit SameSite=lax … We increase the complexity of SameSite cookies significantly. Is that desirable? Will developers be able to know the difference without this effectively being displayed as an additional cookie attribute in developer tools? Are we arriving at the desired end state or piling on more legacy and technical debt? It looks to me like this should instead be a fourth SameSite value, beside none, lax, and strict. Then we’ll have to decide if the new, fourth value is the default or the old explicit lax. I generally don’t like fixing legacy problems by increased spec complexity since it doesn’t help the web/Internet progress. I will bring this up with the CFNetwork folks at Apple to see what they have to say.
Hi John, You bring up some good points. I'm curious if the CFNetwork folks had anything to add.
I think what's under discussion is making the fourth value explicit in the specification. It apparently is already a thing in some implementations. I'm not sure we have a good reason to expose it in syntax though. But yeah, a clear name in the specification would help with tooling and such.
+1
"Default" is an explicit value for the in the algorithms and storage model defined in Section 5. It's not a part of the syntax. Unfortunately it looks like the algorithm only sets the if there's an explicit SameSite attribute in step 17 ("Default" is used for an otherwise unknown value). Presumably the should be initialized to "Default" somewhere, but that's an assumption and not explicit. The value of same-site-flag is technically undefined if there isn't a SameSite attribute and that's clearly not the intent.
Hi, Zhenchao Li from Apple working on CFNetwork. This change sounds quite complex to me. Although, if it means minimizing website breakage and tightening cookie restriction, I'm in favor of explicitly adding the behavior to the RFC. It does sound like we need to move from "SameSite=lax by default" to "SameSite=[fourth value] by default". Also, "default" still needs to be a separate state persisted in "Storage Model" so as not to be conflated any time.
Code change:
however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and submissions can certainly be executed in conjunction with other <del> attack vectors such as cross-site scripting. </del> <ins> attack vectors such as cross-site scripting or abuse of page redirections. Understanding how and when a request is considered same-site is also important in order to properly design a site for SameSite cookies. For example, if a top-level request is made to a sensitive page that request will be considered cross-site and SameSite cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive SameSite cookies.  Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn't include the appropriate cookies. </ins> Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are

Related discussion:
text: The current limbo state isn't helping anyone :) cc NAME
Yes, +1 to documenting reality and no longer blocking the IETF process for 6265bis on this particular item (which I do agree we should treat as a security bug to be eventually solved).
Not an editor, but LGTM (given that it reflects reality).LGTM, given the context.
Code change:
however, prudent to ensure that this designation is not the extent of a site's defense against CSRF, as same-site navigations and submissions can certainly be executed in conjunction with other <del> attack vectors such as cross-site scripting. </del> <ins> attack vectors such as cross-site scripting or abuse of page redirections. Understanding how and when a request is considered same-site is also important in order to properly design a site for SameSite cookies. For example, if a top-level request is made to a sensitive page that request will be considered cross-site and SameSite cookies won't be sent; that page's sub-resources requests, however, are same-site and would receive SameSite cookies.  Sites can avoid inadvertently allowing access to these sub-resources by returning an error for the initial page request if it doesn't include the appropriate cookies. </ins> Developers are strongly encouraged to deploy the usual server-side defenses (CSRF tokens, ensuring that "safe" HTTP methods are

Related discussion:
text: All of the above, actually. I understand that it's challenging to change the behavior at this point. Still, I think it would be beneficial to explicitly document both redirection gadgets and authenticated subresource requests under Sec. 8.8 of the spec. This would help web developers to understand the risks better and adopt mitigations. Cheers, Marco
Still LGTM.
Code change:
bandwidth-delay product (see RFC7323). Even with full awareness of the current bandwidth-delay product, <del> implementation of flow control can be difficult.  When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion.  Failure to do so could lead to a deadlock when </del> <ins> implementation of flow control can be difficult.  Endpoints MUST read and process HTTP/2 frames from the TCP receive buffer as soon as data is available.  Failure to read promptly could lead to a deadlock when </ins> critical frames, such as WINDOW_UPDATE, are not read and acted upon. <ins> Reading frames promptly does not expose endpoints to resource exhaustion attacks as HTTP/2 flow control limits resource commitments. </ins> 5.2.3.

Related discussion:
text: Editorial change only. The idea is to read as soon as data arrives in the TCP buffer. In practice, this is not necessary, but leaving things in the TCP buffer indefinitely can deadlock. (Some implementations of over TCP-based protocols do this and in this case it is BAD.) For .
[x] 1. ----- FP: Is the working group aware that RFC 793bis is in IESG evaluation (URL) ? Was the choice of having a normative reference to 793 conscious, in order to avoid any delay that might come from publication of draft-ietf-tcpm-rfc793bis? (Just checking this was considered) [x] 2. ----- for HTTP/2 over TLS. The general TLS usage guidance in [TLSBCP] SHOULD be followed, with some additional restrictions that are specific to HTTP/2. FP: Given this requirement, I would have expected to see [TLSBCP] normatively referenced, rather than informatively. [x] 3. ----- layer. The frame and stream layers are tailored to the needs of the HTTP protocol and server push. FP: I would think the server push is part of the HTTP protocol, which makes this formulation "HTTP protocol and server push" confusing. [x] 4. ----- Type: The 8-bit type of the frame. The frame type determines the Flags: An 8-bit field reserved for boolean flags specific to the FP: I would find a reference to the IANA registry useful. [x] 5. ----- implementation of flow control can be difficult. When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion. Failure to do so could lead to a deadlock when FP: "When using flow control" might be rephrased to indicate "when flow control limits are lower than the maximum" (or something of the sort), since if I understand correctly the capability is always used, it is just the window size that changes (effectively implementing control of flow). Also "timely fashion" - I know that it is probably hard, but it would be nice to have a more precise qualification, or at least a hint of what is timely. [x] 6. ----- stream that it successfully received from its peer.
Code change:
bandwidth-delay product (see RFC7323). Even with full awareness of the current bandwidth-delay product, <del> implementation of flow control can be difficult.  When using flow control, the receiver MUST read from the TCP receive buffer in a timely fashion.  Failure to do so could lead to a deadlock when </del> <ins> implementation of flow control can be difficult.  Endpoints MUST read and process HTTP/2 frames from the TCP receive buffer as soon as data is available.  Failure to read promptly could lead to a deadlock when </ins> critical frames, such as WINDOW_UPDATE, are not read and acted upon. <ins> Reading frames promptly does not expose endpoints to resource exhaustion attacks as HTTP/2 flow control limits resource commitments. </ins> 5.2.3.

Related discussion:
text: The GOAWAY frame includes an error code that indicates why the connection is FP: "error code" - here as well I would have liked a reference to the IANA registry. [x] 7. ----- Exclusive: A single-bit flag. This field is only present if the PRIORITY flag is set. Stream Dependency: A 31-bit stream identifier. This field is only present if the PRIORITY flag is set. Weight: An unsigned 8-bit integer. This field is only present if the PRIORITY flag is set. FP: I would have expected to see some definition of how the fields are used. If this is defined somewhere else, a reference would be good. [x] 8. ----- SETTINGS Frame { Length (24), Type (8) = 4, Unused Flags (7), ACK Flag (1), Reserved (1), Stream Identifier (31), Setting (48) ..., } Setting { Identifier (16), Value (32), } FP: Is there any reason why the Stream Identifier line is not: Stream Identifier (31) = 0, [x] 9. ----- a server does include a value it MUST be 0. A client MUST treat receipt of a SETTINGS frame with SETTINGSENABLEPUSH set to 1 as a connection error (Section 5.4.1) of type PROTOCOLERROR. FP: This is just my curiosity: what is the reason for this stronger requirement - I would think it shouldn't be a problem for the sender if it wants to advertise that it would permit/support server push. What am I missing? [x] 10. ----- A value of 0 for SETTINGSMAXCONCURRENTSTREAMS SHOULD NOT be treated as special by endpoints. A zero value does prevent the FP: When is it ok that the 0 value is treated as special? [x] 11. ----- set. Upon receiving a SETTINGS frame with the ACK flag set, the sender of the altered settings can rely on the value having been applied. FP: nit s/value/values. Also I believe this could be misunderstood - can it be made more precise on the fact that only the values that are present in the received frame with the ACK flag set (and not those that might have been ignored because not understood) have been applied. [x] 12.