jiebi/CodeConvo huggingface dataset:
Code change:
, which are unfit for security applications). Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed <del> fundamental weaknesses and they MUST NOT be used. </del> <ins> fundamental weaknesses and MUST NOT be used. </ins> 11.6.

Related discussion:
text: 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.
Hi Brian, Apologies for the late reply. I think we’re closing in on agreement here. Comments and some wording suggestions inline below. How about the following? — To ensure privacy of claims that are not being selectively disclosed in a given presentation, the hash function MUST ensure that it is infeasible to calculate the salt and claim name and value (or any portion thereof) that results in a particular digest. This implies the hash function MUST be preimage resistant, but should also not allow an observer to infer any partial information about the undisclosed content. In the terminology of cryptographic commitment schemes, the hash function MUST be computationally hiding. The hash function MUST be second-preimage resistant. For any salt and claim value pair, it is infeasible to find a different salt and claim value pair that result in the same digest. The hash function SHOULD also be collision resistant. Although not essential to the anticipated uses of SD-JWT, without collision resistance an Issuer may be able to find multiple disclosures that have the same hash value. The signature over the SD-JWT would not then commit the Issuer to the contents of the JWT, which is surprising. Where this is a concern, the collision resistance of the hash function SHOULD match the collision resistance of the hash function used by the signature scheme. For example, use of the ES512 signature algorithm would require a disclosure hash function with at least 256-bit collision resistance, such as SHA-512. — (I’d like to add an informational reference defining these terms, but I can’t find a good one - even the NIST/FIPS standards seem to just take terms like “collision resistance” for granted, so maybe we can too?)
Code change:
, which are unfit for security applications). Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed <del> fundamental weaknesses and they MUST NOT be used. </del> <ins> fundamental weaknesses and MUST NOT be used. </ins> 11.6.

Related discussion:
text: The current wording of section 11.6 says: “Verifiers MUST NOT take into account […] whether Key Binding data is present in the SD-JWT or not[…]” While 11.8 says: "Verifiers therefore MUST ensure that all claims they deem necessary for checking the validity of the SD-JWT are present (or disclosed, respectively) before checking the validity and accepting the SD-JWT" I think these constraints do rule out the migration path that I described. I don’t see how a service could incrementally and securely roll-out support for Key Binding (for example) over time—starting from a base ecosystem that isn’t using Key Binding. Either they would have to suddenly require Key Binding, and therefore start rejecting clients that haven’t updated yet, or they may have the situation where a stolen key-bound SD-JWT can be treated as a simple bearer token by not selectively-disclosing the cnf claim. Concretely, I think these phrases and section 8.4 should be removed/re-written. How about the following: — An Issuer MUST NOT allow any security-critical claim to be selectively disclosable. The exact list of “security-critical” claims will depend on the application, and SHOULD be listed by any application-specific profile of SD-JWT. The following is a list of standard claim names that SHOULD be considered as security-critical by any SD-JWT Issuer: “iss” (Issuer) “aud” (Audience), although issuers may want to allow individual entries in the array to be selectively-disclosable “exp” (Expiration Time) “nbf” (Not Before) “iat” (Issued At) “jti” (JWT ID) In addition, the “cnf” (Confirmation Key) claim MUST NOT be selectively disclosable. Best wishes, Neil
I’ve had a look through this new draft and I have some comments and questions. Some of which are similar to comments I already raised [1], but haven’t been addressed. Are we concerned about Holders and Issuers colluding? For example, now that claim names are blinded an Issuer can add the same claim multiple times with different, potentially contradictory, values and then the Holder can selectively release one disclosure to one Verifier and a completely different one to another Verifier.
Code change:
, which are unfit for security applications). Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed <del> fundamental weaknesses and they MUST NOT be used. </del> <ins> fundamental weaknesses and MUST NOT be used. </ins> 11.6.

Related discussion:
text: This seems problematic at least, that the “same” credential could be interpreted differently by different parties. A more sophisticated version of this “attack” illustrates the need for collision resistance in the hash function, not just preimage resistance as stated in the draft (and already raised by me in [1]). If the hash is not CR then a malicious Issuer can find colliding [salt, key, value] triplets that have the same hash value, give one to the Holder and then later claim that they actually signed the other one. (This is not just theoretical, similar attacks have been used to create fraudulent SSL certificates [2]). This also indicates that the security strength of the signature scheme is bounded by the collision resistance of the hash function - e.g. there’s little point using ES512 with SHA-256, for example. Probably the security considerations should suggest matching hash functions to signature algorithms. Furthermore, preimage resistance is not a sufficient property to ensure confidentiality of withheld claims. Preimage resistance holds if the attacker cannot recover the exact input that produced a given hash value, but it doesn’t preclude the attacker being able to recover partial information about that value. For example, consider the hash function H(x) = SHA-256(x) is concatenation). This hash function when applied to SD-JWT is preimage resistant (assuming the salt is strong), but leaks the last 10 bytes of the claim value. The appropriate security definition for SD-JWT is some form of cryptographic commitment scheme [3], with the associated security notions of hiding and binding. Honestly, I still think that this WG is not an appropriate venue for this kind of novel (in the OAuth world) cryptographic scheme and external review by experts would be helpful. All of this suggests that simply referring the the IANA hash function registry is not sufficient, as probably most of the entries there are not actually suitable for use in SD-JWT for one reason or another. Some other comments: The original JWT RFC [4] has this to say about the order of encryption and signatures: signatures over encrypted text are not considered valid in many jurisdictions. Presumably the same argument holds about signatures over blinded values? That should perhaps be noted at least. The draft repeatedly says that a symmetric signature algorithm (MAC) must not be used. Perhaps I’m missing something here, but why not?
Code change:
, which are unfit for security applications). Furthermore, the hash algorithms MD2, MD4, MD5, and SHA-1 revealed <del> fundamental weaknesses and they MUST NOT be used. </del> <ins> fundamental weaknesses and MUST NOT be used. </ins> 11.6.

Related discussion:
text: It doesn’t seem like it compromises any of the intended security properties. Use of a symmetric MAC may also limit the privacy impacts on users as it provides some measure of deniability (similar to that mentioned in section 12.1), as any Verifier in possession of the secret key could also have produced any claims that are subsequently leaked, allowing the user to deny that they were produced by the supposed Issuer. (This deniability property holds even without subsequent leaking of old signing keys). The security considerations about salt entropy should probably reference RFC 4086 (BCP 106) or something more up to date (maybe RFC 8937 too). I think section 11.8 about selectively disclosing contraints on the use of a SD-JWT is completely inadequate and will almost certainly lead to attacks. Requiring Verifiers to hard-wire the set of constraints they enforce is likely to be damaging to future evolution of the standard as new security constraints are added. It would seem especially problematic to allow selective disclosure of a “cnf” claim for example, and yet nothing forbids it and the history of JWT usage suggests that anything not forbidden will at some point happen (and even some things that are forbidden). I suggest establishing a registry of claims that are really usage constraints and forbidding issuers from allowing anything in that list to be selectively-disclosed. (There are perhaps some exceptions here, e.g. “aud” is a constraint in this sense but it probably does make sense for it to be selectively disclosed, but only on a per-array-item basis: that way a Holder cannot remove the constraint entirely but can still hide other “recipients”). On a related note, section 11.6 says that to avoid this kind of attack, Verifiers MUST NOT take into account whether a Key Binding is present or not to decide whether to require Key Binding. This seems to preclude Verifiers that can handle different levels of access with different security requirements and is the sort of requirement that makes it near impossible to incrementally evolve tougher security requirements over time. It effectively becomes an all-or-nothing switch that will have the likely effect of making the use of Key Binding less attractive. Security hardening should be the easy path if we want to see it adopted. Best wishes, Neil [1]: URL [2]: URL [3]: URL
Code change:
3.2. <del> A server in receipt of a larger header block than it is willing to </del> <ins> A server in receipt of a larger message header than it is willing to </ins> handle can send an HTTP 431 (Request Header Fields Too Large) status code per RFC6585.  Due to the typical size of the field values containing certificate data, recipients may need to be configured to <del> allow for a larger maximum header block size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header block size (e.g. HTTP/2 RFC9113 or HTTP/3 RFC9114) should account for the additional size of the header block of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. </del> <ins> allow for a larger maximum header size.  An intermediary generating client certificate header fields on connections that allow for advertising the maximum acceptable header size (e.g.  HTTP/2 RFC9113 or HTTP/3 RFC9114) should account for the additional size of the header of the requests it sends vs. requests it receives by advertising a value to its clients that is sufficiently smaller so as to allow for the addition of certificate data. </ins> 3.3.

Related discussion:
text: Attempt to reword the 'Header Block Size' section to use more HTTP version neutral terms (for )
Is this a hangover from terminology changes elsewhere? URL says
Very possible that it's a hangover from terminology changes elsewhere. Very possible. But I'm not quite sure how to update it. HTTP/3 talks about the "size of the message header" (from your reference) while HTTP/2 talks about block size but now uses field block size URL rather than header block size URL How about the following though? Assuming I'm even adjusting the terminology you're suggesting needs adjusting. Message header seems more neutral and appropriate.
Thanks for the suggestion and PR. I think we're best off holding for NAME review since he had to do a similar renaming exercise for HTTP/3 and is an expert now
Makes sense. I, for one, would welcome such expertise.
URL Mike okayed it
Yes, this looks reasonable.
Code change:
environments is discussed in Section 12 of RFC3649 (HighSpeed TCP) and Section 9.7 of RFC4782 (Quick-Start). <del> Protection Against Congestion Collaps </del> <ins> Protection Against Congestion Collapse </ins> The alternate congestion control mechanism should either stop sending when the packet drop rate exceeds some threshold RFC3714,

Related discussion:
text: Addresses issue
NAME You wrote "Some comments on Bufferbloat" and I am pretty sure these are interesting comments, but I cannot see any. I am afraid something went wrong and they were not published.
A good improvement. I wonder if framing it like "use the full bandwidth and nothing more" would be a more holistic approach that covers a few different requirements at once, but I have no actual text to propose.
This looks like reasonable first text pin this topic, thanks Christian (my previous comments appear already to be resolved - so happy to approve this)
Code change:
for the semantics of repeated field names and rules for combining values. <ins> Messages are invalid (invalid) if they contain fields named ":method", ":scheme", ":authority", ":path", or ":status".  Other pseudo-fields that are defined by protocol extensions MAY be included; pseudo-fields cannot be included in trailers (see H2). Field lines containing pseudo-fields MUST precede other field lines. A message that contains a pseudo-field after any other field is invalid; see invalid. </ins> Fields that relate to connections (HTTP) cannot be used to produce the effect on a connection in this context.  These fields SHOULD be removed when constructing a binary message.  However, they do not cause a message to be invalid (invalid); permitting these fields <del> allows a binary message to capture the content of a messages that are exchanged in a protocol context. </del> <ins> allows a binary message to capture messages that are exchanged in a protocol context. </ins> <del> Like HTTP/2, this format has an exception for the combination of multiple instances of the "Cookie" field.  Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon octet (0x3b) rather than a comma; see H2. </del> <ins> Like HTTP/2 or HTTP/3, this format has an exception for the combination of multiple instances of the "Cookie" field.  Instances of fields with the ASCII-encoded value of "cookie" are combined using a semicolon octet (0x3b) rather than a comma; see H2. </ins> 3.7.

Related discussion:
text: Moving normative language from Section 6 is the most useful, but there are a bunch of other stuff I noticed as I was reading through trying to implement James' other suggestion.
lgtm
Code change:
4.1. The urgency parameter ("u") takes an integer between 0 and 7, in <del> descending order of priority.  This range provides sufficient granularity for prioritizing responses for ordinary web browsing, at minimal complexity. </del> <ins> descending order of priority. </ins> The value is encoded as an sf-integer.  The default value is 3.

Related discussion:
text: by taking MT's suggestion. This is the right thing to do editorially even if it might make NAME a little sad
It is not necessary to make this claim, or any claim, about the range of values. Such a claim would need to be supported with evidence. I don't think we have such evidence. Internal documentation I have lists about 30 different types of requests that a web browser might make that were put into about 11 different categories; you could make arguments that 30 or 11 is sufficient on that basis. And you might still be wrong. The good thing here is that you don't need to justify the choice of 8 different urgencies. Strike this sentence.
Code change:
TBD <ins> 7.7. Issuers that chose to blind claim names MUST ensure not to inadvertently leak information about the blinded claim names to verifiers.  In particular, issuers MUST choose placeholder claim names accordingly.  It is RECOMMENDED to use cryptographically random values with at least 128 bits of entropy as placeholder claim names. The order of elements in JSON-encoded objects is not relevant to applications, but the order may reveal information about the blinded claim name to the verifier.  It is therefore RECOMMENDED to ensure that the order is shuffled or otherwise hidden (e.g., alphabetically ordered using the blinded claim names). </ins> 8. 8.1. <del> Claim names are not hashed in the SD-JWT and are used as keys in a key-value pair, where the value is the hash.  This is because SD-JWT already reveals information about the issuer and the schema, and revealing the claim names does not provide any additional information. </del> <ins> By default, claim names are not blinded in an SD-JWT.  In this case, even when the claim's value is not known to a verifier, the claim name can disclose some information to the verifier.  For example, if the SD-JWT contains a claim named , the verifier might assume that the end-user is a member of the Super Secret Club. Blinding claim names can help to avoid this potential privacy issue. In many cases, however, verifiers can already deduce this or similar information just from the identification of the issuer and the schema used for the SD-JWT.  Blinding claim names might not provide additional privacy if this is the case. </ins> 8.2.

Related discussion:
text: Spec text updated, please review!
George during OAuth side mtg pointed out that it is important for the verifier not to change anything in the JSON object in the Release (ie SVC )that is being hashed so that the hash output is the same from the one in SD-JWT
Code change:
consider the stored response to be stale. If a cache updates a stored response with the metadata provided in a <del> HEAD response, the cache MUST: delete any header fields in the stored response with warn-code 1xx (see header.warning); retain any </del> <ins> HEAD response, the cache MUST use the header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored response and append new header fields to the stored response's header section unless otherwise restricted by the </ins> <del> header fields in the stored response with warn-code 2xx; and, use other header fields provided in the HEAD response to replace all instances of the corresponding header fields in the stored response and append new header fields to the stored response's header section unless otherwise restricted by the header field. </del> <ins> header field. </ins> 4.4.

Related discussion:
text: I'll have to update extract-header-URL so that it can generate entries with status "obsoleted".
NAME Go ahead and merge after you update extract-header-URL
Isn't implemented, generated, used or surfaced to users; can we deprecate?
Proposal: Replace 5.5 Warning with a section noting that the Warning header is deprecated, and should be ignored. Remove all requirements to generate Remove Warning-specific requirements in 3.3 Combining Partial Content Remove Warning-specific requirements in 4.3.4 Freshening Stored Responses upon Validation Remove Warning-specific requirements in 4.3.5 Freshening Responses via HEAD
+1, with big notes in the Changes section.
Just curious if anyone has any background, what would be a good alternative to the Warning header for cache limit warnings?
This isn't a good place for general discussion. You might want to ask the mailing list, though I am not aware of any cache limit warnings within HTTP because they are only relevant to the cache admin (who typically has an email or phone number stored for such notifications).
Code change:
The server can alter the default scope of the cookie using the Path and Domain attributes.  For example, the server can instruct the user agent to return the cookie to every path and every subdomain of <del> example.com. </del> <ins> site.example. </ins> As shown in the next example, the server can store multiple cookies at the user agent.  For example, the server can store a session

Related discussion:
text: This patch replaces with , and corrects inadvertant usage of non-example domains in the hopes of avoiding confusion. Closes httpwg/http-extensions.
NAME mind taking a look?
Landing this. NAME if you object, let me know.
There are still com TLD remaining: and
is real domain. (currently not owned) seems better to use example domain in rfc.
Should we use the .example TLD or stay with URL It's easier to contextualize with .example, in this case webmail.example and projects.example.
SGTM in projects.example, webmail.example etc also URL are fine too.
Code change:
This document uses the Augmented BNF defined in RFC5234 and updated by RFC7405 along with the "#rule" extension defined in Section 4 of <del> I-D.ietf-httpbis-semantics. </del> <ins> SEMANTICS. </ins> The definitions "representation", "selected representation", "representation data", "representation metadata", and "payload body" <del> in this document are to be interpreted as described in I-D.ietf- httpbis-semantics. </del> <ins> in this document are to be interpreted as described in SEMANTICS. </ins> The definition "validator fields" in this document is to be <del> interpreted as described in Section 10.2 of I-D.ietf-httpbis- semantics. </del> <ins> interpreted as described in Section 10.2 of SEMANTICS. </ins> 2. The representation digest is an integrity mechanism for HTTP resources which uses a checksum that is calculated independently of the payload body and message body.  It uses the representation data <del> (see Section 6.1 of I-D.ietf-httpbis-semantics), that can be fully or partially contained in the message body, or not contained at all: </del> <ins> (see Section 6.1 of SEMANTICS), that can be fully or partially contained in the message body, or not contained at all: </ins> This takes into account the effect of the HTTP semantics on the messages; for example the payload body can be affected by Range

Related discussion:
text: References I-D.httpbis-semantics using an inline referece to {{SEMANTICS}}. This will ease the transition once SEMANTICS is updated to RFC.
Code change:
TCP connections can be used in comparison to HTTP/1.x.  This means less competition with other flows and longer-lived connections, which in turn lead to better utilization of available network capacity. <ins> Note, however, that TCP head-of-line blocking is not addressed by this protocol. </ins> Finally, HTTP/2 also enables more efficient processing of messages through use of binary message framing.

Related discussion:
text: thanks both, good suggestions
... and HTTP/2's positives too! protocol. However, the way HTTP/1.1 uses the underlying transport ([RFC7230], Section 6) has several characteristics that have a negative overall effect on application performance today. a time on a given TCP connection. HTTP/1.1 added request pipelining, but this only partially addressed request concurrency and still suffers from head-of-line blocking. Therefore, HTTP/1.0 and HTTP/1.1 clients that need to make many requests use multiple connections to a server in order to achieve concurrency and thereby reduce latency. I think time has shown these claims to not be great. How about cutting cruft and saying and then a tweak to a later paragraph in the intro to state that no one is perfect
It looks like you have a pull request that is dressed up as an issue :)
If you're receptive to change, I am willing to try and edit horrible XML
One change and I'm happy