jiebi/CodeConvo huggingface dataset:
Code change:
The authorization server MUST include the HTTP "Cache-Control" response header field RFC7234 with a value of "no-store" in any response containing tokens, credentials, or other sensitive <del> information, as well as the "Pragma" response header field RFC7234 with a value of "no-cache". </del> <ins> information. </ins> For example:

Related discussion:
text: More detail is in this thread URL URL "Other Authorization Methods" should be "Other Authentication Methods" It's probably worthwhile to note or reference the other client authentication methods that have been specified since this text was written in 6749 and/or point to the OAuth Token Endpoint Authentication Methods registry URL for them and also maybe mention that, despite the Token Endpoint in the name, they are general methods of client auth to the AS when making direct requests. URL "The means through which the client obtains the location of the authorization endpoint are beyond the scope of this specification, but the location is typically provided in the service documentation." Maybe add something like "or in the authorization server's metadata document [RFC8414]." "Request and response parameters MUST NOT be included more than once." please clarify that sentence to say: "Request and response parameters defined by this specification MUST NOT be included more than once." URL " The authorization server MUST compare the two URIs using simple string comparison as defined in [RFC3986], Section 6.2.1." There's absolutely no context here for understanding what two URIs are being compared. Mandating full redirecturi comparison is maybe more appropriate in 4.1.1 with the redirecturi parameter somewhere. And 3.1.2.3. and 3.1.2.2 needs some attention with respect to this too. But also an exception (for the port part) to full redirecturi comparison is needed for loopback redirecturis on native clients as in URL and URL and URL URL As Michael Peck noted in his review, it's probably okay now to just mandate TLS for HTTP redirect URIs. Although custom scheme or loopback redirect URIs for native apps wouldn't use or require TLS. URL and URL Seem to still allow for registration of partial redirection URIs. Which isn't gonna work with an exact match requirement. URL "Request and response parameters MUST NOT be included more than once." please clarify that sentence to say: "Request and response parameters defined by this specification MUST NOT be included more than once." " The means through which the client obtains the location of the token endpoint are beyond the scope of this specification, but the location is typically provided in the service documentation." Maybe add something like "or in the authorization server's metadata document [RFC8414]."
Code change:
The authorization server MUST include the HTTP "Cache-Control" response header field RFC7234 with a value of "no-store" in any response containing tokens, credentials, or other sensitive <del> information, as well as the "Pragma" response header field RFC7234 with a value of "no-cache". </del> <ins> information. </ins> For example:

Related discussion:
text: URL "Client authentication is critical when an authorization code is transmitted to the redirection endpoint over an insecure channel or when the redirection URI has not been registered in full." Isn't full registration of redirection URI now required (other than maybe the port for native apps) by virtue of requiring a full comparison be done when validating the authz request? And other than a native app using the loopback, maybe it's time to move to require that redirection URIs be accessed via secure channel? URL "Clients are permitted to use "plain" only if they cannot support "S256" for some technical reason and know via out-of-band configuration that the server supports "plain"." With codechallengemethodssupported from Authorization Server Metadata / RFC 8414 it doesn't have to be out-of-band anymore. URL " Typically, the "codechallenge" and "codechallengemethod" values are stored in encrypted form in the "code" itself but could alternatively " 'Typically' - really? URL " ensure that the "redirecturi" parameter is present if the "redirecturi" parameter was included in the initial authorization request as described in Section 4.1.1, and if included ensure that their values are identical." The reference should be to 4.1.1.3. URL " An example successful response: HTTP/1.1 200 OK Content-Type: application/json;charset=UTF-8 Cache-Control: no-store Pragma: no-cache" Pretty sure application/json shouldn't have a charset (see note at end of section URL) and I've long thought that "Pragma: no-cache" shouldn't be there (see URL ) Note that these apply to most of the example responses in the draft. URL " specifying the grant type using an absolute URI (defined by the authorization server) as the value of the "granttype" parameter" The words in the parenthetical have led to questions in AD review of documents making use of the grant type extension point (see https://mozphab-URL) and I think "understood by the authorization server" might be better phrasing or even removing the parenthetical all together. RFC7522 is mentioned here as an example extension grant but maybe worth also including mention of others like RFC7523, RFC8628, RFC8693, and maybe even non IETF ones.
Code change:
The authorization server MUST include the HTTP "Cache-Control" response header field RFC7234 with a value of "no-store" in any response containing tokens, credentials, or other sensitive <del> information, as well as the "Pragma" response header field RFC7234 with a value of "no-cache". </del> <ins> information. </ins> For example:

Related discussion:
text: URL " Sender-constrained refresh tokens: the authorization server cryptographically binds the refresh token to a certain client instance by utilizing [I-D.ietf-oauth-token-binding] or [RFC8705]." Given the relative immaturity of ways to do this, maybe something more open ended would be appropriate? This reads like token-binding or MTLS are the only ways allowed. I'd think wording that would allow for DPoP or some yet-to-be-defined method would be better here. Also maybe drop the token-binding reference all together (it's long expired and doesn't look like that's gonna change). URL The SHOULDs/RECOMMENDEDs in this section seem a little overzealous and/or too specific. URL Seems to be a lot of overlap and duplication between 9.4. Access Tokens (under 9. Security Considerations) and section 7.4. Access Token Security Considerations, which could/should maybe be reconciled. "(#poptokens)" hints that some text was copied from elsewhere but the markdown references weren't fixed/updated URL "(#refreshtokenprotection)" same thing about markdown references not fixed/updated URL "(#insufficienturivalidation)", "(#mixup)", "(#openredirectoronclient)","(#csrfcountermeasures)", again "(#mixup)", and "(#redirect307)" URL "Attacker A4 in (#secmodel)" "The use of PKCE is RECOMMENDED to this end." PKCE is required elsewhere so this doesn't seem quite right. Similar comments about text ijn URL that talks as though PKCE might not be there. URL "(#rediruriopenredir)" URL "(#clientimpersonating)" URL " * Redirect URIs must be compared using exact string matching as per Section 4.1.3 of [I-D.ietf-oauth-security-topics]" Should that maybe be qualified to cover dynamic ports on ephemeral local http servers used for redirect URI with native clients? BTW, does [I-D.ietf-oauth-security-topics] need to make a similar allowance? URL "TBD" Given the potentially high visibility of an OAuth 2.1 effort, I think it'd be worthwhile to list organizational affiliations of individuals here in the acknowledgements along with their names.
Code change:
The authorization server MUST include the HTTP "Cache-Control" response header field RFC7234 with a value of "no-store" in any response containing tokens, credentials, or other sensitive <del> information, as well as the "Pragma" response header field RFC7234 with a value of "no-cache". </del> <ins> information. </ins> For example:

Related discussion:
text: Something like what was done in the first part of URL This can help with visibility and justification of (sometimes not insignificant) time spent on the work by non-authors/editors. 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:
And the following signature base line: <del> If the query string is absent from the request message, the value is the leading "?" character alone: </del> <ins> Just like including an empty path component, the signer can include an empty query component to indicate that this component is not used in the message.  If the query string is absent from the request message, the component value is the leading "?" character alone: </ins> Resulting in the following signature base line:

Related discussion:
text: Clarify method case requirements. Add justification for use of empty query string.
Comment by NAME : >If the query string is absent from the request message, the value is the leading ? character alone: When would it make sense to sign this component although empty? Might be good to add some clarification for the reader.
URL I would drop the "and conventionally standardized method names are uppercase US-ASCII". Method names are case-sensitive, that's what is relevant. The second part somewhat weakens that statement.
This is a note to implementors and doesn't change the normative requirements or behaviors -- I think we should leave it in. Note that the text in question appears in section 9.1 as referenced:
Good catch, and I should have objected to that. Anyway; I don't think it makes sense to note it here. It doesn't help at all - the method name is what appears in the request message. The note doesn't add anything useful, but might cause confusion. Take this ticket as proof.
Having seen people try to normalize things by lowercasing because "it made sense", I disagree that the note doesn't add anything useful. I'd like to leave it in.
Just to clarify: my concern is that implementers will take that as a suggestion to uppercase.
Code change:
clear persisted opt-in preferences when any one of site data, browsing history, browsing cache, cookies, or similar, are cleared. <del> 5. While HTTP header compression schemes reduce the cost of adding HTTP header fields, sending Client Hints to the server incurs an increase in request byte size.  Servers SHOULD take that into account when opting in to receive Client Hints, and SHOULD NOT opt-in to receive hints unless they are to be used for content adaptation purposes. Due to request byte size increase, features relying on this document to define Client Hints MAY consider restricting sending those hints to certain request destinations FETCH, where they are more likely to be useful. 5.1. </del> <ins> 4.2. </ins> Deployment of new request headers requires several considerations:

Related discussion:
text: When merging the different PRs, the "Cost of adding hints" section was misplaced and it wound up in the middle of the security section. This fixes that (and bumps the revision number).
Code change:
Reference: Where the algorithm is defined Initial contents: Provided in <ins> 9.  References 9.1.  URIs [1] https://github.com/ietf-scitt/draft-steele-cose-merkle-tree- proofs/issues/21 [2] https://github.com/ietf-scitt/draft-steele-cose-merkle-tree- proofs/issues/21 </ins>

Related discussion:
text: This PR build on and attempts to clarify what is generic vc what is specific to RFC9162 encodings
Mostly improves on the earlier version, I like the generality it allows for. A couple of larger questions in here amongst the suggestions
Code change:
The QUERY method provides a solution that spans the gap between the use of GET and POST.  As with POST, the input to the query operation <del> is passed along within the payload of the request rather than as part </del> <ins> is passed along within the content of the request rather than as part </ins> of the request URI.  Unlike POST, however, the method is explicitly safe and idempotent, allowing functions like caching and automatic retries to operate.

Related discussion:
text: This spec uses 'body' and 'payload' a lot; I think most should be 'content'.
Code change:
be ignored. <ins> The ALTSVC frame type is 0xa (decimal 10). </ins> The ALTSVC frame contains the following fields: An unsigned, 32-bit integer indicating the freshness lifetime of

Related discussion:
text: Two minor things here: more strongly recommend the use of the frame type in HTTP/2 over the header field add a frame type number (no need to defer the choice now, this lets people build code based on this)
Code change:
A client that makes a request to an "https" URI uses TLS12 with the TLS-ALPN. <del> HTTP/2 over TLS uses the "h2" application token.  The "h2c" token MUST NOT be sent by a client or selected by a server. </del> <ins> HTTP/2 over TLS uses the "h2" protocol identifier.  The "h2c" protocol identifier MUST NOT be sent by a client or selected by a server; the "h2c" protocol identifier describes a protocol that does not use TLS. </ins> Once TLS negotiation is complete, both the client and the server MUST send a ConnectionHeader.

Related discussion:
text: Moves considerations of defining an ALPN token for a non-TLS-based protocol to 3.1. Changes "token" to "protocol identifier" in 3.3.
Code change:
only be used by an authorized workload and that the context information originated from an authorized workload. <del> 3.6. </del> <ins> 3.8. </ins> TBD. <del> 3.7. </del> <ins> 3.9. </ins> TBD. <del> 3.8. </del> <ins> 3.10. </ins> As workloads often need to communicate across administrative boundaries, extra care needs to be taken when it comes to identity communication to ensure scalability and privacy. <del> 3.8.1. </del> <ins> 3.10.1. </ins> A workload communicating with a service, or another workload provided by an external organization may need to provide more generic identity

Related discussion:
text: added Attestation as a function performed within the Server box. defined Agent. defined Attestation.
Thanks I think this helps my understanding, I'm sure we'll have more refining to do, but thanks for providing the text to get started.
Code change:
upload append (upload-appending), and upload cancellation (upload- cancellation). <del> Once the upload resource is available, the target resource MAY send an informational response with a "104 (Upload Resumption Supported)" status code to the client while the request content is being uploaded.  In this informational response, the "Location" header field MUST be set to the upload resource. </del> <ins> Once the upload resource is available and while the request content is being uploaded, the target resource MAY send one or more informational responses with a "104 (Upload Resumption Supported)" status code to the client.  In the first informational response, the "Location" header field MUST be set to the URL pointing to the upload resource.  In subsequent informational responses, the "Location" header field MUST NOT be set.  An informational response MAY contain the "Upload-Offset" header field with the current upload offset as the value to inform the client about the upload progress.  In subsequent informational responses, the upload offset MUST NOT be smaller than in previous informational responses.  In addition, later offset retrievals (offset-retrieving) MUST NOT receive an upload offset that is less than the offset reported in the latest informational response, allowing the client to free associated resources. </ins> The server MUST send the "Upload-Offset" header field in the response if it considers the upload active, either when the response is a

Related discussion:
text: switching network and losing one or more of the 104 response (think spotty Wi-Fi moving over to 4G). Another input here would be consistency, especially if we add the header to the first 104. I agree that the benefit might not be huge but it's not zero either. It does however seem like the consensus in Prague was that this is not needed and I can get behind that.
One or more of the 104 responses could be dropped, along with the final response, due to the connection being interrupted, but selective 104s can't be dropped due to network issues. Clients need to deal with failed connections no matter what, so I don't see how this is an issue.
NAME Right, then this is a non-issue that can be skipped. I just wanted to bring it up so that we do not miss aspects. :)
Thanks for the feedback! I adjusted URL to clarify what header fields can be present in 104 responses.
Code change:
given pathname.  This original protocol is now referred to as HTTP/0.9 (see HTTP09). <del> HTTP's version number consists of two decimal digits separated by a "." (period or decimal point).  The first digit ("major version") indicates the messaging syntax, whereas the second digit ("minor version") indicates the highest minor version within that major version to which the sender is conformant (able to understand for future communication). </del> As the Web grew, HTTP was extended to enclose requests and responses within messages, transfer arbitrary data formats using MIME-like media types, and route requests through intermediaries, eventually

Related discussion:
text: and only define the versioning there; leave message version requirements in control data. (no content changes)
Code change:
single value, then "req_wl" will be prepresented by an array of StringOrURIs. <del> 5.2.2. </del> <ins> 5.2.3. </ins> The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token:

Related discussion:
text: Added a section to clarify the intent of the claim and how it is different from scope values addressing issue .
From Yaron's : need a lot more discussion of this claim, also it may be OPTIONAL too. Also, why not call it "scope" if that's what it is?
From NAME In an external to internal flow, the scopes tend to be broad. The TraT can be set to a more specific to narrow the use of the TraT. We could call it scope, but it could be confused with the OAuth scope One could set the value to the actual API that was called to be very specific We should add a sub-section to describe the above in the draft.
Code change:
single value, then "req_wl" will be prepresented by an array of StringOrURIs. <del> 5.2.2. </del> <ins> 5.2.3. </ins> The figure below figleaftxtokenbody shows a non-normative example of the JWT body of a Txn-Token:

Related discussion:
text: To address issue
From Yaron's : how is "azd" different from "rctx"? There's a whole section about "rctx" and nothing about "azd".
Discussed in meeting on 06/14/2024: Add a subsection for azd, like we agreed to add a section for purp.
Looks good
Code change:
9.1. The "Connection" header field allows the sender to list desired <del> control options for the current connection.  In order to avoid confusing downstream recipients, a proxy or gateway MUST remove or replace any received connection options before forwarding the message. </del> <ins> control options for the current connection. </ins> When a field aside from Connection is used to supply control information for or about the current connection, the sender MUST list <del> the corresponding field name within the Connection header field.  A proxy or gateway MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, </del> <ins> the corresponding field name within the Connection header field. Intermediaries MUST parse a received Connection header field before a message is forwarded and, for each connection-option in this field, </ins> remove any header or trailer field(s) from the message with the same name as the connection-option, and then remove the Connection header field itself (or replace it with the intermediary's own connection

Related discussion:
text: Chrome and Safari treat it as LF in those places, but they do not allow two CRs to end the header block (network error in Safari, empty body in Chrome). It does seem that a stricter stance is possible here, given the intersection of the results. cc NAME NAME
If we can be stricter here and just fail on CRs in headers, that sounds good to me. That having been said, I think changing behavior to anything but just rejecting the response would be worse than the status quo (Treating CRs as part of header values, for instance).
Yeah, it seems like CR CR could be treated as a network error at least. CR "after" reason phrase or individual header is less clear. But I agree that making CR part of the value isn't good.
Regarding at the end of the line, we currently say?
Code change:
Status Method Value: "status_list" Status Method Description: A status list containing up-to-date <del> status information on multiple other JWTs encoded as a bitarray. </del> <ins> status information on multiple tokens. </ins> Change Controller: IETF

Related discussion:
text: fixes the list rendering (missing newline) clarifies IANA text to just reference other tokens Rendered version: URL
I did further fixes on media types
Code change:
This document describes a format for JWTs that support selective disclosure (SD-JWT), enabling sharing only a subset of the claims included in the original JWT instead of releasing all the claims to <del> every verifier.  This document also defines a format for so-called SD-JWT Releases (SD-JWT-R). </del> <ins> every verifier.  During issuance, an SD-JWT is sent from the issuer to the holder alongside an SD-JWT Salt/Value Container (SVC), a JSON object that contains the mapping between raw claim values contained in the SD-JWT and the salts for each claim value. This document also defines a format for SD-JWT Releases (SD-JWT-R), which conveys a subset of the claim values of an SD-JWT that the holder is selectively releasing to the verifier.  During presentation, SD-JWT-R and SD-JWT are both sent to the verifier from the holder.  To verify claim values received in SD-JWT-R, verifier uses salts in SD-JWT-R to compute the hashes of the claim values and compare them to the hashes in SD-JWT. </ins> One of the common use cases of a signed JWT is representing a user's identity created by an issuer.  In such a use case, there has been no

Related discussion:
text: Based on the feedback from NAME
This review identifies three minor syntax issues. Once they are addressed, I'll approve.
Code change:
"Digest" may expose information details of encrypted payload when the checksum is computed on the unencrypted data.  An example of that is <del> the use of the "id-sha-256" digest-algorithm in conjuction with the </del> <ins> the use of the "id-sha-256" digest-algorithm in conjunction with the </ins> encrypted content-coding RFC8188. <ins> The representation-data-digest of an encrypted payload can change between different messages depending on the encryption algorithm used; in those cases its value could not be used to provide a proof of integrity "at rest" unless the whole (e.g. encoded) payload body is persisted. </ins> 11.9. ...

Related discussion:
text: details encryption quirks: encryption functions may produce different results with the same data this means that if I GET an encrypted resource twice, I could get two different digest values so the digest value is just good to validate the ongoing message and not for further processing of the data at rest, unless I store the encrypted data or use an algorithm which in turn might disclose information. This
looks good, just some nits.