jiebi/CodeConvo huggingface dataset:
Code change:
7.1. <del> The chunked transfer coding wraps the payload body in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer section containing trailer fields. Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to </del> <ins> The chunked transfer coding wraps payload data in order to transfer it as a series of chunks, each with its own size indicator, followed by an OPTIONAL trailer section containing trailer fields.  Chunked enables content streams of unknown size to be transferred as a sequence of length-delimited buffers, which enables the sender to </ins> retain connection persistence and the recipient to know when it has received the entire message.

Related discussion:
text: This eliminates confusion with the message body protocol element of HTTP/1.1 and other usage of multipart body parts, and should make it easier to describe HTTP/2 and HTTP/3 data frames.
except for multipart body parts or when referring specifically to HTTP/1.1 message body.
See related comment: URL
I believe this is good; but more eyes are needed :-) If we go ahead with that, we may want to call out the new terminolody in one of the "changes from 723x" sections.
Code change:
The same digest value MUST NOT appear more than once in the SD-JWT. <del> Applications of SD-JWT SHOULD be explicitly typed using the header parameter.  See explicit_typing for more details. </del> <ins> Application and profiles of SD-JWT SHOULD be explicitly typed.  See explicit_typing for more details. </ins> It is the Issuer who decides which claims are selectively disclosable and which are not.  End-User claims MAY be included as plaintext as

Related discussion:
text: From this conversation URL this PR tries to somewhat better explain that explicit typing, per JWT BCP before it, is about distinguishing different types of SD-JWTs. And also be a little more open to other ways of typing, such as cty.
Thanks, looks COMPLETELY REASONABLE to me. inline this time... On Mon, Sep 30, 2024 at 6:30 AM Dick Hardt wrote: While the use of "typ" is unnecessary. So this first choice issue didn't need to be an issue at all. That's the issue. Elevating an unnecessary and arguable flawed construct to a MUST would only further engrain the issue. that we are still talking past one another and there remains some misunderstanding as distinguishing between an sd-jwt and other tokens isn't what explicit typing is about. I'll take another look at the language in the draft around typing and see if there's anything that can reasonably be done to make it less confusing or potentially problematic. CONFIDENTIALITY NOTICE: This email may contain confidential and privileged material for the sole use of the intended recipient(s). Any review, use, distribution or disclosure by others is strictly prohibited. If you have received this communication in error, please notify the sender immediately by e-mail and delete the message and any file attachments from your computer. Thank you.
Code change:
To evaluate a received If-Match header field: An origin server MUST NOT perform the requested method if a received <del> If-Match condition evaluates to false; instead, the origin server MUST respond with either a) the status code or b) one of the status codes if the origin server has verified that a state change is being requested and the final state is already reflected in the current state of the target resource (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or a compatible change was made by some other user agent).  In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent. </del> <ins> If-Match condition evaluates to false.  Instead, the origin server MAY indicate that the conditional request failed by responding with a status code.  Alternatively, if the request is a state-changing operation that appears to have already been applied to the selected representation, the origin server MAY respond with a status code (i.e., the change requested by the user agent has already succeeded, but the user agent might not be aware of it, perhaps because the prior response was lost or an equivalent change was made by some other user agent). Allowing an origin server to send a success response when a change request appears to have already been applied is more efficient for many authoring use cases, but comes with some risk if multiple user agents are making change requests that are very similar but not cooperative.  For example, multiple user agents writing to a common resource as a semaphore (e.g., a non-atomic increment) are likely to collide and potentially lose important state transitions.  For those kinds of resources, an origin server is better off being stringent in sending 412 for every failed precondition on an unsafe method.  In other cases, excluding the ETag field from a success response might encourage the user agent to perform a GET as its next request to eliminate confusion about the resource's current state. </ins> The If-Match header field can be ignored by caches and intermediaries because it is not applicable to a stored response.

Related discussion:
text: We decided to move the version-independent parts of the definition of Content-Length to Semantics, but that calls for some new text to explain its semantics in general. For now, we have added (in crefs) the following text to the section on "Content-Length" in Semantics:
s/representation/representation data/?
Code change:
should be mindful of such pitfalls, as well, and should examine any potential security issues that may arise. <del> 6. </del> <ins> 7. </ins> This document has no IANA actions.

Related discussion:
text: I resisted the urge to resolve other issues with this, so there are a bunch of TODOs in the text. Most of the big blocks of text are moved from elsewhere in the document.
The guidelines overlap in odd ways. The first one is essentially TCP-friendliness, and I guess it's implied to be talking about "normal" wired networks. Then different guidelines say the algorithm should be evaluated with all sorts of environments and/or link parameters, presumably for friendliness. Then, in "Minimum Requirements" some of these are listed as mandatory to satisfy, and the rest as something the submitter has to report on, but the community may decide to accept even if it's bad. There are several different concepts that are being muddled here. Alternatively, we can structure it as follows: (A) Metrics to evaluate Does the new algorithm match its share of the existing bottleneck bandwith better than existing algorithms? (not underutilizing, not bufferbloating or congestion collapsing) in isolation or with multiple flows? Are flows using widely deployed algorithms not severely degraded by the introduction of the new algorithm? Is there a plausible incremental deployment plan? Something about short flows? (B) Mandatory Domains: must answer positively to (A) Wired networks, "normal" range of BDPs Wireless networks, "normal" range of BDPs (loss & jitter) Internet-scale deployment is sufficient for this? (C) Optional Domains: must evaluate (A) & report IoT Satellite Misbehaving nodes Response to sudden & transient events Tunnels for explicit-signal protocols Extreme packet reordering
I agree we need to restructure, I like the idea of A. I think defining heterogeneity in B is likely helpful - although we really ought to stop using "bandwidth" when we mean "capacity" - because it really confuses SDOs that actually do cap[acity v bandwidth tradeoffs:-) I'll fight that Internet-Scale deployment is sufficient;-). That plays to the big operators, and I do not like that. It worries me quite a lot that we target "normal BDPs" - that's not something I would welcome. It places all satellite outside normal, which again, I don't like - some satellite is definitely odd, but I'd really like to see broadband services as "normal", if nothing else, to include those people who can only use this technology.
Code change:
should be mindful of such pitfalls, as well, and should examine any potential security issues that may arise. <del> 6. </del> <ins> 7. </ins> This document has no IANA actions.

Related discussion:
text: So, main question first: can we factor the last section as different in a particular perspective, rather than "labelling" networks as optional to support? i.e. XXXX is a property, and IoT is an example, transients and abrupt capacity variation is an example of radio networks; etc.?
I agree that we need a better structure. Including having actual subsections per issue, rather than the current list format. Two points: short flows, and transient events. Short flows are pretty much the norm, with reports of 90% of connections never going out of slow start. There is an associated problem: capacity discovery algorithm like slow start will rapidly increase the amount of data sent on a path, with a high potential for disrupting current users of that path. That's not good. There are potentials solutions such as quickly evaluating the capacity (e.g., packet pair, squirting, variants), remembering past connections (careful resume), or potentially getting input from the network (maybe something like Prague/ECN). These solutions have been explored for "special" links (satellite, deep space), but the problem is not just special links. I would like to see that discussed in the "main" section (A). Transients are also the norm. Congestion control is a form of control algorithm, and control algorithms must absolutely deal with transients. For example, if we deal with wireless, we need to deal with "entering a tunnel" -- and exiting. We may want to deal with . That should belong to the core (A), not the "weird configuration" (C).
Wait to land PRs, then do this with no substantive change, then do other PRs -- this change will be editorially disruptive.
I like the flow after this refactoring!Good to merge, the text here looks good to me. There are still things to think about, but these are probably best down on the basis of the entire document.
Code change:
7.6. <ins> A workload and Transaction Token Service MUST perform mutual authentication. </ins> A Txn-Token Service MUST ensure that it authenticates any workloads requesting Txn-Tokens.  In order to do so: <del> It MUST name a limited, pre-configured set of workloads that MAY request Txn-Tokens </del> <ins> It MUST maintain a limited, pre-configured set of authorized workloads that MAY request Txn-Tokens. It MUST authenticate the requesting workload and confirm that it is included in the list of workloads authorized to request a transaction token. </ins> <del> It MUST individually authenticate the requester as being one of the named requesters </del> <ins> It SHOULD accept workload credentials such as JWTs or X.509 certificates which MAY be provisiond using mechanisms such as SPIFFE or other provisioning protocols. </ins> <del> It SHOULD rely on mechanisms, such as SPIFFE used in conjunction with MTLS RFC8446, or some other means of performing MTLS, to securely authenticate the requester </del> <ins> It SHOULD use X.509 credentials in conjunction with MTLS RFC8446, or a JWT protected by TLS at the transport layer, to securely authenticate the requesting workload. </ins> It SHOULD NOT rely on insecure mechanisms, such as long-lived <del> shared secrets to authenticate the requesters </del> <ins> shared secrets to authenticate the requesting workloads. The requesting workload MUST ensure that it authenticates the Transaction Token Service.  In order to do so: It MUST have a pre-configured location for the Transaction Token Service. </ins> <del> The requesting workload MUST have a pre-configured location for the Transaction Token Service.  It SHOULD rely on mechanisms, such as SPIFFE, to securely authenticate the Transaction Token Service before making a Txn-Token Request. </del> <ins> It SHOULD accept Transaction Token Service credentials such as JWTs or X.509 certificates which MAY be provisiond using mechanisms such as SPIFFE or other provisioning protocols. It SHOULD use X.509 credentials in conjunction with MTLS RFC8446, or a JWT protected by TLS at the transport layer, to securely authenticate the Transaction Token Service. It SHOULD NOT rely on insecure mechanisms, such as long-lived shared secrets to authenticate the Transaction Token Service. </ins> 8.

Related discussion:
text: Agreed on the security considerations for ensuring that the access token is not sent to an incorrect endpoint (I can imagine an adversary getting into a build server, modifying the TTS location for a workload, and then have the TTS send tokens to it. I can also imagine this happening by accident, especially if there are multiple TTS's in a deployment.
Regarding the second point: Yes, should there be a way for the workload to determine it can trust the TTS before sending it an external token? This isn't something that is common in OAuth specs. It is assumed that the client knows whether to send the request or not.
Regarding 1: I think we wanted to talk about it at the last IETF and ran out of time. I seem to remember a few conversations around "discovery" but nothing concrete was decided.
I found the issue it's
Code change:
subject to flow control.  Of the frame types defined in this document, this includes only <del> frame.  Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to </del> <ins> frames.  Frames that are exempt from flow control MUST be accepted and processed, unless the receiver is unable to assign resources to </ins> handling the frame.  A receiver MAY respond with a StreamErrorHandler or ConnectionErrorHandler of type

Related discussion:
text: Mostly minor stuff from a readthrough. Of particular note: Regarding headers, "name-value pair" implies only one value; either it's a pair, and collections may have multiple instances with the same name; or it's a name with a collection of associated values. Either is reasonable, but both is confusing. Adjusting phrasing in SETTINGSHEADERTABLE_SIZE to better reflect that HPACK now lets the encoder change the table size at will. Removing suggestion that a GOAWAY frame can get "lost", which can't happen in TCP; actual issue is that recipient may have acted on the previous GOAWAY and retried the requests the server says it didn't process.
Code change:
6.3. <del> Failure to provide a certificate on a stream after receiving </del> <ins> Failure to provide a certificate for a stream after receiving </ins> "CERTIFICATE_NEEDED" blocks processing, and SHOULD be subject to standard timeouts used to guard against unresponsive peers.

Related discussion:
text: and filed by NAME Given , the AUTOMATIC_USE text is entirely superfluous, and given , the correct wording would be "for a stream."
Not sure if this is an issue or not. Emphasis added in the below quote. This seems to have been left out of the change to stream 0 for all frames (URL)
Section 5.4 contains some left over text that refers to the now removed AUTOMATIC_USE flag. Cf. URL
Code change:
TODO elaborate on increased privacy if the status list is hosted by a third party instead of the issuer reducing tracking possiblities TODO evaluate deifnition of Status List Provider?  An entity that hosts <del> the Status List as a resource for potential verifiers.  The Status List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. </del> <ins> the Status List as a resource for potential Relying Parties.  The Status List Provider may be the issuer of the Status List but may also be outsourced to a trusted third party. </ins> 11.

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:
TODO add more <del> 4. </del> <ins> 5. </ins> <del> 4.1. </del> <ins> 5.1. </ins> TODO elaborate on risks of incorrect parsing/decoding leading to erroneuos status data <del> 4.2. </del> <ins> 5.2. </ins> TODO consumers/Verifiers of the status list should be aware if they fetch the up-to-date data <del> 4.3. </del> <ins> 5.3. </ins> TODO elaborate on authorization mechanisms preventing misuse and profiling as described in privacy section <del> 4.4. </del> <ins> 5.4. </ins> TODO elaborate on status list only providing the up-to date/latest status, no historical data, may be provided by the underlying hosting architecture <del> 5. </del> <ins> 6. </ins> <del> 5.1. </del> <ins> 6.1. </ins> TODO elaborate on herd privacy, size of the status list <del> 5.2. </del> <ins> 6.2. </ins> TODO elaborate on Verifiers regularly fetching the status list to create a profile, possible countermeasures with authorized access to the status list <del> 5.3. </del> <ins> 6.3. </ins> TODO elaborate on Issuer-Verifier correlation and Verifier-Verifier correlation as the status list introduces unique,trackable data TODO

Related discussion:
text: We can also call it something else like credential if we do a proper introduction of the term in the beginning?
Why call "status list token" and not "status list JWT/CWT"?
agreed on call: rename Status List to Status List Token introduce Status List for the actual bitarray rename Subject Token to Referenced Token remove Status List Provider for now and introduce it later if neccessary
btw sd-jwt vc spec mentions status provider :)
NAME NAME can you approve this PR?
Hi, thinking more about this, status list Token is being referenced in the token-whose-name-we-are-trying-to-find, so it's the status list token that is actually a "referenced token". Can we call token-whose-name-we-are-trying-to-find "a Token with reference"?
Yes, I agree and had the same thoughts when I changed the PR. I assume Referencing Token could be better. But let's accept this PR and move discussion to an issue instead...
Multiple approvals and discussions on editors calls, merging
opened issue to continue the terminology discussionok. Then please migrate the TODOs afterwards.
Code change:
The resulting string is the canonicalized component value. <ins> Note that some HTTP fields have values with multiple valid serializations that have equivalent semantics.  Applications signing and processing such fields MUST consider how to handle the values of such fields to ensure that the signer and verifier can derive the same value, as discussed in security-field-values. </ins> Following are non-normative examples of canonicalized values for header fields, given the following example HTTP message fragment:

Related discussion:
text: Includes some new text and several small cleanups.
did you forget to merge it?
Sorry, there was ice cream cake and I got distracted
Some header field values are case-insensitive, in whole or in part. The canonicalization rules do not account for this, thus a case change to a covered header field value causes verification to fail.
While I'd just put a warning on that, it would be great to have some examples/use cases for that.
Intermediaries are permitted to strip comments from the header field value, and consolidate related sequences of entries. The canonicalization rules do not account for these changes, and thus they cause signature verification to fail if the header is signed. At the very least, guidance on signing or not signing headers needs to be included.
Let's add a paragraph with some caveats and header examples.
Code change:
4.3. <del> The following is a non-normative example of an unsecured input payload of an SD-JWT VC. </del> <ins> The following is a non-normative example of an unsecured payload of an SD-JWT VC. </ins> <del> The following is a non-normative example of how the Credential above can be used in a SD-JWT where the resulting SD-JWT VC contains only claims about the Subject that are selectively disclosable: </del> <ins> The following is a non-normative example of how the unsecured payload of the SD-JWT VC above can be used in a SD-JWT where the resulting SD-JWT VC contains only claims about the Subject that are selectively disclosable: </ins> Note that a

Related discussion:
text: NAME can we merge this now?
Try to find a new term.
Introduce and use the term "unsecured payload" instead of payload or credential to refer to the input JSON document. We cannot use payload because it would lead to confusion since the payload of the SD-JWT might not even contain all the claims and only the hashes.
Code change:
If-Match is most often used with state-changing methods (e.g., POST, PUT, DELETE) to prevent accidental overwrites when multiple user agents might be acting in parallel on the same resource (i.e., to <del> prevent the "lost update" problem).  It can also be used with safe methods to abort a request if the </del> <ins> prevent the "lost update" problem).  It can also be used with any method to abort a request if the </ins> <del> does not match one already stored (or partially stored) from a prior request. </del> <ins> does not match one that the client has already stored (or partially stored) from a prior request. </ins> An origin server that receives an If-Match header field MUST evaluate the condition as per evaluation prior to performing the method.

Related discussion:
text: evaluating false on a duplicate change request sending 2xx without validator for reasons unknown.
Hmm, of course, now I found another related message in my archives that prompted me to remember why the requirement was added. I should probably rewrite the paragraph (without that requirement) and describe the edge case as a note.
RFC7232 in URL has the following clause: It doesn't really explain what security or performance considerations are leading to such a requirement, but it calls for a lot of infrastructure and design work to implement it because that logic can be implemented only if the server is stateful. The stateless server cannot comply with such a requirement. See related mail list thread: URL Either RFC should explain why such logic MUST be implemented or relax "MUST" into "SHOULD" in that clause or remove that clause completely.
Should I submit an errata proposing to remove the following clause from RFC 7232, section 3.1: " In the latter case, the origin server MUST NOT send a validator header field in the response unless it can verify that the request is a duplicate of an immediately prior change made by the same user agent" It seems like nobody can recall/explain why this clause is there.
I finally found the original commit 303b82b12a53c170f6f755aaaf8840ac1240aa77
And the discussion motivating the change is under . Certainly the intent was to remove the constraint that an error be sent when a duplicate request is made, so the extra limitations were to reduce edge cases.
It is not an errata. This is the right place to discuss it and either find a better wording or strike the text.
Thanks, NAME for finding the original commit and your response! Sending response for repeating requests makes total sense. My issue is about a sub-condition of response that is stated in the RFC7232. In the original commit that you referenced that sub-condition is stated as: I think I understand the original recommendation not to send back. It would be better to replace with there though. But in RFC7232 that sub-condition clause is changed to: The reason of not sending with back is not explained in RFC7232 and nobody can remember why it is there or explain this requirement. Complying with this requires dev effort and extra infra since we would need to track immediate previous requests from each agent.