jiebi/CodeConvo huggingface dataset:
Code change:
This specification introduces a new error code value for the <del> parameter of RFC6750 or authentication schemes, such as I-D.ietf- oauth-dpop, which use the </del> <ins> parameter of the challenge of the authentication scheme from RFC6750 and other OAuth authentication schemes, such as I-D.ietf-oauth-dpop, which use the same </ins> parameter:

Related discussion:
text: changes/clarifications from Httpdir telechat review URL Thank you for the review Mark. I've replied inline below with some context or explanation as best I can. And I'll put together a PR with corresponding changes/clarifications. mechanism. Rather the intent is to provide a new error code and two new parameters for the "Bearer" authentication scheme challenge from RFC6750 (and other OAuth schemes like "DPoP" that use the RFC6750 challenge params). for the Bearer authentication scheme challenge defined by [RFC6750] not the WWW-Authenticate response header in general. RFC6749 and used throughout the OAuth family of specs providing useful context and disambiguation for OAuth roles and functionality etc. I agree with Aaron about adding a terminology paragraph to the draft to make it more explicit. 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:
as used by those applications.  For instance, if the Example application uses an OAuth protected resource in an Example-specific way, and there are Example-specific metadata values that it needs to <del> publish, then it might register and use the "example-resource- configuration" URI path suffix and publish the metadata document at the path formed by concatenating "/.well-known/example-resource- configuration" to the protected resource's resource identifier. </del> <ins> publish, then it might register and use the "example-protected- resource" URI path suffix and publish the metadata document at the path formed by inserting "/.well-known/example-protected-resource" between the host and path components of the protected resource's resource identifier.  Alternatively, many such applications will use the default well-known URI string "/.well-known/oauth-protected- resource", which is the right choice for general-purpose OAuth protected resources, and not register an application-specific one. </ins> An OAuth 2.0 application using this specification MUST specify what well-known URI string it will use for this purpose.  The same protected resource MAY choose to publish its metadata at multiple <del> well-known locations relative to its resource identifier, for example, publishing metadata at both "/.well-known/example-resource- configuration" and "/.well-known/oauth-protected-resource". </del> <ins> well-known locations derived from its resource identifier, for example, publishing metadata at both "/.well-known/example-protected- resource" and "/.well-known/oauth-protected-resource". </ins> 3.1.

Related discussion:
text: As discussed during IETF 118.
The draft (and the examples in it) follow this language This means (taken from an example in the draft): This is inconsistent with RFC8414 (and its normative dependencies) which says This means (taken from an example in RFC8414): The RFC8414 way kind of hampers the ability to host these documents in multi-tenant system on certain deployments but i'm unsure if we can justify not doing it this way.
Thanks NAME this was the subject of my comments in . I do think that the way it's done in the draft currently makes sense for the context and is preferable. But it might raise some objections in IESG etc. review. I don't honestly know what the best course of action is. But wanted to bring it up earlier rather than later. Perhaps Roman's suggestion of asking the HTTP directorate for an early review in hope of avoiding surprise down the line?
The draft does say the following , which maybe provides sufficient justification. Maybe.
Code change:
Security considerations related to the JPEG 2000 codestream contained in the payload are discussed at RFC3745. <del> 13.  References 13.1.  URIs [1] http://www.iana.org/assignments/rtp-parameters </del>

Related discussion:
text: In regards to not requesting registration in the RTP payload registry, please remove the following sentence in Section 11: The motivation and removal of the registry the above sentence request are in: URL (from Magnus Westerlund)
Code change:
header in HTTP2, Section 8.1.2.3.  The resulting string is the canonicalized value. <del> 2.4.1.1. </del> <ins> 2.3.1.1. </ins> The following table contains non-normative example HTTP messages and their canonicalized "@request-target" values. <del> 2.4.2. </del> <ins> 2.3.2. </ins> HTTP Message Signatures have metadata properties that provide information regarding the signature's generation and/or verification.

Related discussion:
text: Remove the list prefix parameter operation on structured headers. This was previously added to allow for signing of a subset of combined headers, but since the combined header value cannot be considered a structured header value, the prefix functionality did not ultimately serve this purpose. However, common cases such as adding additional headers to a request could still be covered by a different mechanism. Note that dictionary key indexing is still allowed and facilitates multi-signature use cases.
(emphasis added by me) That sounds as if a subset of a list is not a valid list? How so?
Code change:
Application of additional restrictions and policy are at the discretion of the verifying party. <del> The following is a non-normative example for a decoded payload of a Referenced Token: </del> <ins> The following is a non-normative example for an IssuerAuth as specified in ISO mDL (also referred to as signed MSO) in Hex: </ins> <del> TBD: example </del> <ins> The following is the CBOR Diagnostic Notation of the example above: </ins> 7.

Related discussion:
text: Rendered version: URL We need to fix width - otherwise the datatracker will refuse the document. I will make suggestions
NAME please approve
Editors Call: rename 6.2 -> Referenced Token in JOSE add SD-JWT example is it possible to merge 6.3 and 6.4 and make some specifics for CWT? include both cwt and mdoc example
Looks good imho
Code change:
16.3.2. <ins> HTTP header and trailer fields are a widely-used extension point for the protocol.  While they can be (and often are) used in an ad hoc fashion, fields that are widely used need to be more carefully documented, to ensure interoperability. In particular, authors of specifications defining new fields are advised to consider and, where appropriate, document the following aspects: Request header fields have additional considerations that need to be documented if the default behaviour is not appropriate: 16.3.2.1. </ins> Authors of specifications defining new fields are advised to choose a short but descriptive field name.  Short names avoid needless data transmission; descriptive names avoid confusion and "squatting" on

Related discussion:
text: Including a re-org of Considerations for New Fields
I think it should be mentioned as an aside in the section on common rules for defining field values.
maybe wait until RFC is out...
Code change:
RFC3230 has been added to the HTTP Digest Algorithm Values Registry with the "obsoleted" status. <del> All digest-algorithms defined in RFC3230 are now "deprecated". </del> <ins> All digest-algorithms defined in RFC3230 are now "insecure". </ins> 9.4. The digest-algorithm tokens for "MD5", "SHA", "SHA-256", "SHA-512" have been updated to lowercase. <del> The status of "MD5" and "SHA" has been updated to "deprecated", and </del> <ins> The status of "MD5" and "SHA" has been updated to "insecure", and </ins> their description has been modified accordingly. The "id-sha-256" and "id-sha-512" algorithms have been added to the

Related discussion:
text: Thanks, nice solution.
The latest draft of the Digest Fields RFC [0] deprecates all non-cryptographically secure algorithms (notably, MD5 and CRC32c). Given that the RFC is "not intended to be a general protection against malicious tampering with HTTP messages," I'd like to propose not deprecating at least these two algorithms, or changing "deprecated digest algorithms MUST NOT be used" to "should be used with caution" or similar. CRC32c is a very useful algorithm because it is composable (crc(A+B) == combine(crc(A), crc(B))). See [1] for an explainer and [2] for an implementation of combine() in zlib. MD5 is ubiquitous. AWS S3 and Google Cloud Storage both use it (see [3], which has similar syntax to this RFC except that the crc32c is base64 instead of hex). [0] URL [1] URL [2] URL [3] URL Sorry if this is the wrong forum. I saw some links from the w3c mailing list archive that looked like more discussions were happening here than there.
Hi NAME this is the right place, thanks for opening the issue. Do you have a use case where you'd like to use these algorithms with the Digest or Content-Digest header? They are pretty old and pretty bad at their intended purpose - what caution can we offer? The statement comes from URL, which is really about making it clear that applications do care about protecting messages also need to apply signatures that protect HTTP header or trailer sections. Otherwise, an attacker could just change the header at the same time as changing the representation.
Thanks for the fast reply. My use case is for detecting file corruption in internal HTTP communication, where we trust the network/server/client. Since it's internal, we don't have to obey a standard, but I was hoping to provide the CRC32C and MD5 that we already store to our end users -- provide something instead of nothing. Those algorithms provide an adequate level of error detection by our rough calculation (considering that TCP and other layers also checksum). Intel's implementation of CRC32C [0] runs at >19 GB/s, whereas SHA256 runs at only ~360 MB/s.
Code change:
RFC3230 has been added to the HTTP Digest Algorithm Values Registry with the "obsoleted" status. <del> All digest-algorithms defined in RFC3230 are now "deprecated". </del> <ins> All digest-algorithms defined in RFC3230 are now "insecure". </ins> 9.4. The digest-algorithm tokens for "MD5", "SHA", "SHA-256", "SHA-512" have been updated to lowercase. <del> The status of "MD5" and "SHA" has been updated to "deprecated", and </del> <ins> The status of "MD5" and "SHA" has been updated to "insecure", and </ins> their description has been modified accordingly. The "id-sha-256" and "id-sha-512" algorithms have been added to the

Related discussion:
text: We also take advantage of the ability of CRC32C to be combined, so we can concatenate files in O(1) time and get their CRC32C without calculating a SHA256/512 or MD5 over the whole content. We serve some millions of files. Google Cloud Storage and AWS S3 probably store many trillions of files and provide CRC32C+MD5 and MD5, respectively.1 It would be pretty impactful for servers to be able to pass along these digests and might make it worthwhile for browsers to start verifying digests for downloads (e.g. revive [1]). I might be under-appreciating the security intents of this RFC, but there is clear mention of the other benefits of the RFC (below), which are ones that non-cryptographically secure hashes are often good enough for. [0] URL [1] URL Edit: 1 Clarification: The S3 object is an MD5 in many scenarios, and S3 uses for integrity checks during uploads. They do not explicitly store the MD5 for all objects though.
Corruption in the network does happen, but HTTPS is a far better way of managing that risk. I know that you say that you trust them, but I would be worried about the network/server/client being - or becoming - untrustworthy. Obviously, if you are into high-volume transfers of bulk data, you are going to do what you need to do; specialized applications have specialized constraints. But that doesn't make unsecured transfers any less inadvisable; I'd stand by the deprecation here as a general statement.
Hi NAME Thanks for joining the discussion! Let me clarify one point: This just means that the part protected by Digest (the representation) is only a subset of an HTTP message. For the rest, while I agree on some of your considerations, eg. we had a very long discussion on that URL Maybe, since crc32 & co - while deprecated - are still defined in the digest algorithm table, I think that you wouldn't have particular interoperability issues if you need to use them in a specific environment.
Thanks NAME for the pointers to the earlier discussions. I'd thought I'd searched but somehow missed those.
Code change:
RFC3230 has been added to the HTTP Digest Algorithm Values Registry with the "obsoleted" status. <del> All digest-algorithms defined in RFC3230 are now "deprecated". </del> <ins> All digest-algorithms defined in RFC3230 are now "insecure". </ins> 9.4. The digest-algorithm tokens for "MD5", "SHA", "SHA-256", "SHA-512" have been updated to lowercase. <del> The status of "MD5" and "SHA" has been updated to "deprecated", and </del> <ins> The status of "MD5" and "SHA" has been updated to "insecure", and </ins> their description has been modified accordingly. The "id-sha-256" and "id-sha-512" algorithms have been added to the

Related discussion:
text: I'll yield, although I remain in favor of saying these "SHOULD NOT" instead of "MUST NOT" be used at least because of their ubiquity, performance and the composability of CRCs. One last question: does the Digest header provide better security than, or any additional beyond, what TLS provides? My reading of the RFC is that TLS is the typical primary protection layer (since doesn't protect headers; indeed, itself could be altered) and is primarily useful for finding ~bugs. (PS: I really like the digests, nice idea.)
NAME you've made some good points. Adding accommodation for these algorithms, given the proliferation of e.g. MD5 for this kind of integrity checking could be better than nothing, or hoping that everyone would run a SHA-algo over all of their existing assets. The thorny part is how to square the circle on relaxing the rule and providing clear, meaningful guidance to implementers. The MUSTNOT helps set a clear bar, this means its unambiguous what the spec thinks about the relationship of Digest to secure usage scenarios. Anything else needs careful wording and is hard to get right. The current MUSTNOT is slightly odd in so far as we don't state the ramifications if it is used. Part of that is a product of how Digest has been defined and how apps use it
NAME The actual work on digest was driven by its usage in signing http messages (eg URL and URL ) This is at a different layer wrt TLS. So you can see Digest as a building block for creating non-repudiable HTTP exchanges without altering the payload (since signatures are conveyed via http headers). Hth, R.
Personally -- I think there's something here worth considering. AIUI the primary use case for headers is not adversarial -- it's end-to-end (i.e., through various intermediaries, toolkits, perhaps a data store) integrity. If someone has lots of content they've calculated CRC or MD5 for, it seems reasonable to allow them to use it in ; not only is it more efficient, but it saves them recalculating a value for all of that content (and possibly getting it wrong -- that's effectively "end-to-end over time"). OTOH, there are adversarial use cases for too -- mostly, signing the digest as a proxy for signing the content.
Code change:
RFC3230 has been added to the HTTP Digest Algorithm Values Registry with the "obsoleted" status. <del> All digest-algorithms defined in RFC3230 are now "deprecated". </del> <ins> All digest-algorithms defined in RFC3230 are now "insecure". </ins> 9.4. The digest-algorithm tokens for "MD5", "SHA", "SHA-256", "SHA-512" have been updated to lowercase. <del> The status of "MD5" and "SHA" has been updated to "deprecated", and </del> <ins> The status of "MD5" and "SHA" has been updated to "insecure", and </ins> their description has been modified accordingly. The "id-sha-256" and "id-sha-512" algorithms have been added to the

Related discussion:
text: Here, using CRC or MD5 can be bad, and shouldn't be encouraged (or perhaps allowed) by the spec. This leads me to think that deprecating them isn't the right thing to do; instead, what about marking them as insecure in the registry, and putting language into the spec to explain how to use that? If folks think that's a good idea, I can do a PR.
Thanks for the background NAME . NAME NAME I think that sounds reasonable to state something like "insecure digests {MUST NOT be used|are not suitable} for protection against malicious actors." The final part of this I think would be allowing for the insecure digests.
I like NAME idea of introducing "insecure". It's not trivial how to state that insecure algorithms must not be used in signatures/adversarial use cases. I'm waiting for Mark's proposal :)
Maybe "Checksum Only" to imply a more narrow purpose. "Insecure" is not the opposite of "secure".
LGTMA pragmatic approach.
Code change:
Expert, that Expert should defer to the judgment of the other Experts. <ins> The reason for the use of the mailing list is to enable public review of registration requests, enabling both Designated Experts and other interested parties to provide feedback on proposed registrations. The reason to allow the Designated Experts to allocate values prior to publication as a final specification is to enable giving authors of specifications proposing registrations the benefit of review by the Designated Experts before the specification is completely done, so that if problems are identified, the authors can iterate and fix them before publication of the final specification. </ins> 8.1. This specification establishes the IANA "OAuth Protected Resource

Related discussion:
text: ... per additional feedback by NAME Cc: NAME
I'm checking with IANA.... will reply once they respond. Thanks for the work!
Code change:
STUB_PROVIDED_PREFIX_LIFETIME seconds.  The stub router sends a router advertisement containing this prefix.  The 'A' (autonomous configuration), 'L' (on-link) RFC4861 and the Stub Router bit (I- <del> D.hui-stub-router-ra-flag) MUST be set in the prefix header. </del> <ins> D.hui-stub-router-ra-flag) MUST be set in the Router Advertisement header flags field RFC5175. </ins> This router advertisement MUST also include a Route Information Option (RFC4191) for each routable prefix advertised on the stub

Related discussion:
text: …flag in the Prefix Information Option flags, but in fact Jonathan's document describing the flags field sets it in the Router Advertisement Flags Extension option. We discussed this in 6man and I think the general consensus was to just use one of the remaining reserved bits rather than requiring the additional extension option prematurely, so I'm updating the text to say that, and have asked Jonathan to update the stub router flags document accordingly.
Code change:
and recovery at the OAuth server, rather than making it part of the application logic. <ins> Splitting of responsibilities between authenticating a user and serving resources </ins> Using OAuth for browser-based apps in a first-party same-domain <del> scenario provides these advantages, and can be accomplished by either of the two architectural patterns described below. </del> <ins> scenario provides these advantages, and can be accomplished by any of the architectural patterns described below. </ins> 6.2. In this architecture, commonly referred to as "backend for frontend" or "BFF", the JavaScript code is loaded from a dynamic Application <del> Server (A) that also has the ability to execute code itself.  This enables the ability to keep all of the steps involved in obtaining an access token outside of the JavaScript application. Note that this application backend is not the Resource Server, it is still considered part of the OAuth client and would be accessing data at a separate resource server. In this case, the Application Server initiates the OAuth flow itself, by redirecting the browser to the authorization endpoint (B).  When the user is redirected back, the browser delivers the authorization code to the application server (C), where it can then exchange it for an access token at the token endpoint (D) using its client secret. The application server then keeps the access token and refresh token stored internally, and creates a separate session with the browser- based app via a traditional browser cookie (E). </del> <ins> Server (A) that has the ability to execute code and handle the full authentication flow itself.  This enables the ability to keep the call to actually get an access token outside the JavaScript application. Note that this BFF is not the Resource Server, it is the OAuth client and would be accessing data at a separate resource server. In this case, the BFF initiates the OAuth flow itself, by redirecting the browser to the authorization endpoint (B).  When the user is redirected back, the browser delivers the authorization code to the application server (C), where it can then exchange it for an access token at the token endpoint (D) using its client secret and PKCE code verifier.  The application server then keeps the access token and refresh token stored internally, and creates a separate session with the browser-based app via a traditional browser cookie (E). </ins> When the JavaScript application in the browser wants to make a request to the Resource Server, it instead makes the request to the

Related discussion:
text: Refactoring some architectural patterns: Single-Domain Browser-Based Apps (not using OAuth) Backend For Frontend (BFF) Proxy