jiebi/CodeConvo huggingface dataset:
Code change:
an upload.  For example, a subsequent resource could allow the client to fetch information extracted from the uploaded data. <del> 12. </del> <ins> 14. </ins> The upload resource URL is the identifier used for modifying the upload.  Without further protection of this URL, an attacker may

Related discussion:
text: defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!
Code change:
response is supposed to provide a URI that is specific to the created resource. <del> 10.2.4. </del> <ins> 10.2.3. </ins> Servers send the "Retry-After" header field to indicate how long the user agent ought to wait before making a follow-up request.  When

Related discussion:
text: This works well on multiple levels because these fields are not about the request or response context, but rather about the message itself. Date is now defined early and close to the date value definitions of 5.6.7. Trailer is now defined just after the description of trailers. Also, it avoids changing any xrefs from HTTP/3. Only the section heading and intro are new -- the moved text has not been changed.
Oops, that wasn't intentional. The Trailer field is the main one that goes both directions. It should really be in a different section. Date is the other.
I think we should move it to 6.6 (in the message abstraction, just after trailers are defined).
I also forgot that Date can be sent in requests. How about a 10.3 section on "Generation Context" that would contain Date and Trailer? I am a little worried that this might change the section numbering for HTTP/3, so we should check that first.
I checked HTTP/3 and there are no references to section 10 of [SEMANTICS].
Looks good, want to see it in situ tho
Code change:
9.2. <del> TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data </del> <ins> TODO consumers/Relying Party of the status list should be aware if they fetch the up-to-date data </ins> 9.3.

Related discussion:
text: Use term Relying Party and Issuer URL
Sometimes we use Verifier, sometimes we use Relying Party. After deciding this, we should add them to the Terminology
As this is moving to OAuth Security working Group, we should adopt Relying Party as terminology
Code change:
Transfer-Encoding header fields received in a successful response to CONNECT. <del> Content within a CONNECT request message has no defined semantics; sending content in a CONNECT request might cause some existing implementations to reject the request. </del> <ins> A CONNECT request message does not have content.  The interpretation of and allowability of data sent after the header section of the CONNECT request message is specific to the version of HTTP in use. </ins> Responses to the CONNECT method are not cacheable.

Related discussion:
text: The spec currently says this about data sent along with a CONNECT request: Is there a demarcation between data "within" a request and data to be sent on the tunnel if it opens successfully? HTTP/2 and HTTP/3 are fairly specific that all DATA frames are data for the tunnel. Do we need to say anything about the client prospectively sending data before the proxy responds?
We should decide what we want to allow. If HTTP/3 is going to send CONNECT data within HTTP/3 frame payloads after (or before) the recipient accepts the CONNECT, then we should specify it differently than how we specified CONNECT in 1.1. I am fine with that.
Hm. Does this imply we special-case 1.1, and require the HTTP/2/3 behaviour for new versions?
I think it is already a special case for 1.1, so that's not a problem.
OK, let me rephrase this then :-). Are we trying to make it consistent for all "new" versions?
Given that CONNECT is specified on a version-by-version basis anyway, I think I'd rephrase it with something like this: CONNECT is one of those weird edges of the protocol where each version will have to respecify its behavior; we don't necessarily need to prescribe what it will be, just make allowances for versions to differ.
Code change:
The HEADERS frame is associated with an existing stream.  If a HEADERS frame is received with a stream identifier of 0x0, the <del> recipient MUST respond with a StreamErrorHandler of type </del> <ins> recipient MUST respond with a ConnectionErrorHandler of type </ins> PROTOCOL_ERROR. The HEADERS frame changes the connection state as defined in

Related discussion:
text: Error when stream identifier field is 0x0 is not stream error but connection error because it is impossible to send RST_STREAM of 0x0.
Code change:
apply the redirection directly in an immediate subsequent upload append (upload-appending). <del> 11. </del> <ins> 12. A message might have a content coding, indicated by the "Content- Encoding" header field, and/or a transfer coding, indicated by the "Transfer-Encoding" header field (RFC9112), applied, which modify the representation of uploaded data in a message.  For correct interoperability, the client and server must share the same logic when counting bytes for the upload offset.  From the client's perspective, the offset is counted after content coding but before transfer coding is applied.  From the server's perspective, the offset is counted after the content's transfer coding is reversed but before the content coding is reversed. 13. </ins> The server might process the uploaded data and make its results available in another resource during or after the upload.  This

Related discussion:
text: defines a framework for problem types, which can be used as a standardized response format when errors occurs. With resumable uploads, we have a few cases where such problem types could be useful, but usage remains entirely optional. The text in this PR has been inspired by similar sections from .
Thank you very much for quick feedback, Lucas!
Code change:
of the client attestation that was used for client authentication when the refresh token was issued. <ins> 5.3. This specification does not provide a mechanism to rotate the Client Instance Key in the Client Attestation JWT's "cnf" claim.  If the Client Instance needs to use a new Client Instance Key for any reason, then it MUST request a new Client Attestation JWT from its Client Backend. </ins> 6. 6.1.

Related discussion:
text: This PR makes explicit an already implicit feature of the specification - that it is not possible to rotate the confirmation key. URL) -->
NAME NAME Any reason this can't be merged?
Waiting for NAME approval
Currently section 5.2 states: In the case that the original client attestation JWT has expired, what should happen? If it is acceptable for the client to re-use the same key in the "cnf" field across attestation JWTs, then the client can easily generate a new attestation JWT with the same "cnf" key. But if the client needs to use a fresh "cnf" key, then I can think of three options: Define a flow which endorses the new "cnf" key with the old "cnf" key. Define a field in the client attestation JWT that contains a unique identifier for the client instance, and use that identifier to bind the refresh token to the client instance. Explicitly don't permit this in the specification, add text to the specification that makes it clear that the "cnf" key must stay the same across refreshed client attestations. My preference would be for option 2.
Currently the client instance needs to go back to the client backend and request a new client attestation JWT bound to the same key used in the old JWT. In general because we are effectively using the client instance key to identify the instance at the authorization server this makes key rotation of the client instance key difficult with active refresh tokens. 1 feels too complex, 3 is an option and NAME and I have discussed 2 before. The flip side to consider with option 2 is the privacy implications of formally electing to track client instances, personally i'm not convinced its a bad idea but we should carefully consider the impact.
Do we? I had assumed the AS identifies the client by the value. I don't see a need to identify a client instance.
the forth option is to have long living client attestations, which in my opinion is no problem the client should then use different attestations with different ASs
This just makes explicit the tracking of client instances that already existed through the requirement for the "cnf" key to stay the same over attestations. This is really a decision for the use-case in my opinion.
Code change:
of the client attestation that was used for client authentication when the refresh token was issued. <ins> 5.3. This specification does not provide a mechanism to rotate the Client Instance Key in the Client Attestation JWT's "cnf" claim.  If the Client Instance needs to use a new Client Instance Key for any reason, then it MUST request a new Client Attestation JWT from its Client Backend. </ins> 6. 6.1.

Related discussion:
text: In the context of software integrity being established through the client attestation, it is trivial to inject malware after the generation of the attestation, so some in some cases it may be a requirement to have fresh attestations.
Isn't the AS identifying the client also by the refresh token itself? I dislike option 2 due to the privacy implications. As any optional fields in the client attestation JWT are valid, profiles could still use this option, but it should not be a good requirement in my opinion. I see two options: A: the wallet initially gets one client attestation and uses the cnf key over a longer period to bind a sequence of refresh tokens to it. -> similar to option 4? B: the Wallet initially gets one client attestation and the AS binds the first refresh token to the cnf key. When it uses the refresh token, it also provides a new client attestation with a new cnf key and the AS binds a new refresh token to this new key. -> similar to option 1?
Well the current language doesn't actually guarantee that the AS can track the client instance (which is a good thing IMO), as the instance can in many common cases, rotate the keys it uses in between fetching tokens. But in the event a client instance is exchanging a refresh token for a fresh access token and potentially another refresh token, the client instance must authenticate using a client attestation JWT with the same key in the cnf claim that was in the original attestation used when the refresh token was obtained. This ensures one client instance can't use another client instances refresh token. So in this case the AS can track that the client instance who obtained the refresh token is the client instance now requesting to exchange it for a new access token, which is desired from a security perspective. As I said above in response to Torsten's point, using the key instead of an explicit claim means a single client instance could actually use multiple keys over time meaning the AS can't track the client instance across all of those interactions. The concern if we make an explicit claim in the client attestation JWT for identifying the client instance, is that implementations won't rotate this identifier over time thus meaning the instance would be tracked.
Code change:
of the client attestation that was used for client authentication when the refresh token was issued. <ins> 5.3. This specification does not provide a mechanism to rotate the Client Instance Key in the Client Attestation JWT's "cnf" claim.  If the Client Instance needs to use a new Client Instance Key for any reason, then it MUST request a new Client Attestation JWT from its Client Backend. </ins> 6. 6.1.

Related discussion:
text: Ironically if your goal is to reduce the ability of the AS to track the client instance over time, this option will in fact enable that as the attestation itself becomes the tracking vector. Agreed, the additional requirement of requiring the same client authentication method with the same key just means that obtaining the refresh token alone is not enough for another instance to be able to exercise the refresh token, it doesn't materially change the ability for the AS to track the client instance because as you highlight the refresh token itself creates the same possibility for correlation.
I think this is basically my option 3. Unless there is a mechanism to issue a refresh token that I am not aware of, it is not possible to rotate keys according to the current language. The spec states: This is what I mean by "This just makes explicit the tracking of client instances that already existed through the requirement for the "cnf" key to stay the same over attestations."
I don't think rotation of the key within the lifetime of a refresh token is something that needs to be accounted for. So my preference would be for option 3 (which is how it functionally is now but could be made more explicit in the text). Adding an explicit claim in the client attestation JWT which identifies the client instance, i.e. option 2, would be okay too. But I think it'd get complicated/confusing to describe it in the spec.
By saying you can't rotate the key within the lifetime of a refresh token, I think this means that you cannot rotate the key without starting from scratch at the authorization endpoint. I just wanted to make sure that is what you meant?
Basically yeah, I think so. Rotating the the key would mean you'd have to go back to the authorization endpoint. That seems acceptable/reasonable. Maybe it's too narrow of a view but it seems like if there's a reason to rotate that key then reauthorizing is probably needed or at least acceptable anyway.
I'm not sure that's true. IMO authorization is more of a user-identification concern, the rotation of the key is a client-security concern. Saying that, I think I agree that it's probably acceptable to say key-rotation isn't possible without returning to the authorization endpoint. Given this I would suggest we add a sub-section to the Implementation Considerations section, something along the lines of this:
Code change:
The JWT MAY contain other claims. <del> The JWT MUST be digitally signed or have a Message Authentication Code (MAC) applied by the issuer.  The authorization server MUST reject JWTs with an invalid signature or MAC. </del> <ins> The JWT MUST be digitally signed using an asymmetric cryptographic algorithm.  The authorization server MUST reject the JWT if it is using a Message Authentication Code (MAC) based algorithm.  The authorization server MUST reject JWTs with an invalid signature. </ins> The authorization server MUST reject a JWT that is not valid in <del> all other respects per "JSON Web Token (JWT)". </del> <ins> all other respects per "JSON Web Token (JWT)" RFC7519. </ins> The following example is the decoded header and payload of a JWT meeting the processing rules as defined above.

Related discussion:
text: The following changes are encapsulated in this PR: Update references from RFC7523 to RFC7521. Added a recommendation around order of validation for the two JWTs in the client_assertion parameter. Removed the note from the exp and iat claims for the client key Attestation JWT that imply this cannot be re-used across multiple requests. Removed the ability to use MAC based algorithms when producing the client key Attestation JWT. Updated the requirements around the presence of the JTI claim for the client key attestation PoP to be a MUST inline with DPoP PoPs for reliable basic replay attack detection mechanism. Added references to the JWT RFC. Added an implementation consideration that highlights a client instance can re-use a client key attestation JWT in multiple AS interactions/requests. Added aud as a required claim in the client attestation pop JWT. Add IANA registration request for the new client assertion type and token endpoint authentication method.
Code change:
Controller Enhanced (PIE) RFC8033; and Low Latency, Low Loss, and Scalable Throughput (L4S) RFC9332. <ins> Congestion control algorithms that set one of the two Explicit Congestion Transport (ECT) codepoints in the IP header can gain the benefits of receiving Explicit Congestion Notifictaion (ECN) Congestion Experienced (CE) signals from an on-path AQM RFC8087.  Use of ECN ?RFC3168,RFC9332 results in requirements for the congestion control algorithm to react when it receives a packet with an ECN-CE marking.  This reaction needs to be evaluated to confirm that the algorithm conforms with the requirements of the ECT codepoint that was used. </ins> 5.2. The "Internet of Things" (IoT) is a broad concept, but for congestion

Related discussion:
text: Added the missing 'd' - thanks Neal.
I'm separating AQM from ECN, although ECN relies on AQM design and deployment - ECN can be a force for good when detecting bottlenecks and latency - aka RFC 8087.
Well, yes. ECN, by itself, is one of the signals that can be used by CC algorithms, together with packet loss, delay variation, and packet acks (input to bandwidth measurement). Makes sense to separate it. However, the L4S folks have introduced a tight coupling between a very specific use of ECN in the L4S AQM, and a fine grain mandate of the expected behavior of the CCA. And I cringe each time I read their dual queue formula based on the asymptotic limit of Reno -- but not Cubic. I wish we could walk that back, or describe it in more neutral terms. With L4S, ECT(1) is a signal from the sending host to the network that CE marks should be apply at incipient congestion, instead of waiting for actual loss-generating queue buildup as in RFC 3168. Maybe that should be true even for algorithms that are not described in L4S. Of course, we have to deal with what we have. Maybe we should just quote all the relevant RFCs, and denote the difference between ECT(1)/EC and ECT(0)/EC. Senders using ECT(1) should consider that the rate of CE marking signals the intensity of the congestion, while senders using ECT(0) should consider individual CE marks as denoting actual congestion.
I think the ECN text ought to approach with something very generic like setting ECT can provide nice properties [RFC8087], but comes with requirements for reacting to ECN-CE marking. This reaction to ECN-CE marks needs to be evaluated to ensure this conforms with the style of ECN being used. I'll make a PR.
see Neal's comment
Code change:
to determine if a request is for an "https" resource; for example, they might look for TLS on the stack, or a server port number of 443. <del> This might be due to limitations in the protocol (the most common HTTP/1.1 request form does not carry an explicit indication of the URI scheme), or it may be because how the server and application are </del> <ins> This might be due to expected limitations in the protocol (the most common HTTP/1.1 request form does not carry an explicit indication of the URI scheme and the resource might have been developed assuming HTTP/1.1), or it may be because how the server and application are </ins> implemented (often, they are two separate entities, with a variety of possible interfaces between them).

Related discussion:
text: I tried to make this work, but NAME is right: this is entirely a transport decision and given that our best option was to violate a MUST in RFC 7230, that's too hard. This just says that HTTP/1.1 is no good because we can't include the scheme (because RFC 7230 says we can't). I almost made this h2-specific, but then remembered that there might be another protocol that has favourable properties.
It's official - MT says "HTTP/1.1 is no good."
Code change:
6.1.16. <del> The user MAY be asked to verify if they initiated an authentication </del> <ins> The user MAY be asked to confirm if they initiated an authentication </ins> or authorization request by sending a one-time password (OTP) or PIN to the user's Authorization Device and asking them to enter it on the Consumption Device to confirm the request.  If the request was

Related discussion:
text: Added reference to the mitigation when describing .
NAME I made one editorial change. If your OK with it, I will merge.
Ok for me, thanks! NAME
Code change:
A client that doesn't perform authentication is an easy victim of server impersonation, through man-in-the-middle attacks. <del> A client that is willing to use cleartext to resolve the resource will do so if access to any TLS-enabled alternative services is blocked at the network layer. </del> <ins> A client that is willing to use HTTP over cleartext to resolve the resource will do so if access to any TLS-enabled alternative services is blocked at the network layer. </ins> Given that the primary goal of this specification is to prevent passive attacks, these are not critical failings (especially

Related discussion:
text: for encryption. I had these in my local repo. They weren't pushed, but I wanted to make sure that they are OK before merging them.
Code change:
Transparency Services MUST ensure that for any Signed Statement they register, enough information is made available to Auditors (either in the Append-only Log and retrievable through audit APIs, or included <del> in the Receipt) to authenticate and retrieve the Transparent Statements describing the registration policy and trust anchors that apply to this registration. </del> <ins> in the Receipt) to reproduce the Registration checks that were defined by the Registration Policies at the time of Registration. </ins> 4.1.2.

Related discussion:
text: Hi all, This PR comes from a place that agrees: If using an identity scheme, then yes, it must be used in maner consistent with that scheme, But aslo that There is no identity scheme we could all agree on as universally applicable or agreable, further, the space continues to evolve. And, The trustworthiness or otherwise of issuers identity, in the context of a transparency ledger, is temporal and subjective in nature. It's just a question of time frame. This means that regardless of registration time checks, relying parties, auditors and general consumers will have to re evaluate regardless. And will do so according to their own subjective context. Remembering that "It can never be assumed that some Issuers and some Transparency Services will not be corrupt.". And also "A Verifier SHOULD validate a Transparent Statement originating from a given Issuer" ... "and would not depend on any other Issuer or Transparency Services." It does seem obvious that, Syntactic validation of the issuer identity claims makes good sense and supports interoperability. But, Specifying a single identity scheme in the core architecture as "minimally required" does not meaningfully help interoperability when there is no single agreeable scheme, and especially when a TS may be used to underpin identity schemes themselves. Regarding the burden on Relying Parties and Auditors, The definition for "Relying Party" states "a Relying Parties consumes Transparent Statements, verifying their proofs and inspecting the Statement payload, either before using corresponding Artifacts, or later to audit an Artifact's provenance on the supply chain". IOW: Relying parties are already expected to deeply consider statements. Assessing the identity asserted by the issuer, at the time the artifact is being considered, seems to be a natural and useful part of that process. Registration Auditability: Requiring that Transparency Services "enough information is made available to Auditors" ... "to authenticate and retrieve the Transparent Statements" is essentially impossible to specify at this level, imposes un-bounded maintenance and storage issues on implementations, and represents a significant layering violation in the architecture.
Editors meeting: will wait 24hours for reviews, with merger if no objections.
Per the editors meeting, I've merged the discussed changes and resolved the discussed topics. I've opened to track the MUST/Should discussion, which wasn't part of this PR.