jiebi/CodeConvo huggingface dataset:
Code change:
MUST be created in such a manner that it is cryptographically random, long enough, and has high entropy that it is not practical for the attacker to guess.  A new salt MUST be chosen for each claim <del> independently from other salts. </del> <ins> independently from other salts.  See Randomness Requirements for Security RFC4086 for considerations on generating random values. </ins> 11.4.

Related discussion:
text: And maybe qualify that text a bit more too with something like “infeasible to calculate the salt and claim value (or any portion thereof) that results in a particular digest”. current venue. And as the end of the draft’s intro states, “this specification aims to be easy to implement and to leverage established and widely used data formats and cryptographic algorithms” which is why a regular old secure hash function is being used - SHA-256 specifically and as the default, which I believe is completely suitable for the purpose. It seems like some tightening up or changes around the approach provided for hash algorithm agility might be in order. But I think the overall salted hash based approach is okay/appropriate/sufficient. “inclusion in the [...] registry alone does not indicate a hash algorithm's suitability for use in SD-JWT” after attempting to describe what makes a hash algorithm suitable for use with SD-JWT. We wanted to allow for some hash algorithm agility but really didn’t want to create yet another hash algorithm registry. That "Named Information Hash Algorithm Registry" isn’t an ideal fit but was the best one we were able to find. Pointing to that registry and having the associated security considerations seemed like a reasonably reasonable approach. originally) and I’m very reluctant to make any such statements that venture into legal territory. model implies/assumes that an Issuer issues a token with no idea of where it’ll be presented and having a shared symmetric key seemed really weird in that situation. Also had to explain why or how a shared symmetric key would work in that situation too. That said, there’s been some talk about loosening that restriction - largely around the same reasoning on deniability that you cite - I guess your comment here should be taken as supportive of that prospective change? hard-wired set of claims/constraints enforced/required by verifiers is appropriate and necessary even when selective disclosure isn’t at play. It’s how regular JWT works (or should work) in practice already. And don’t think it harms future evolution because any new security constraints would necessarily need updates all around because they won’t be understood otherwise. The 11.8 section could perhaps be stronger in saying that claims controlling the validity of the token shouldn’t be made selectively disclosable. But what exactly constitutes such a claim is actually rather murky and there are undoubtedly exceptions like you point out with “aud”.
Code change:
MUST be created in such a manner that it is cryptographically random, long enough, and has high entropy that it is not practical for the attacker to guess.  A new salt MUST be chosen for each claim <del> independently from other salts. </del> <ins> independently from other salts.  See Randomness Requirements for Security RFC4086 for considerations on generating random values. </ins> 11.4.

Related discussion:
text: And I know some have expressed the need/desire to have key/holder binding type claims (such as “cnf” but not only that) be made selectively disclosable for privacy reasons. I also don’t think a new registry would really help the situation. At this level we're describing a generic mechanism and don’t necessarily even have a list of all claims that could be interpreted as constraints in a particular context or application. Note, for example though, that URL does say that certain claims must be included directly and not made selectively disclosable. Which leads back to ultimately needing that requirement that Verifiers ensure that all the claims they deem necessary are present (in the clear or disclosed) when checking the validity and accepting the token. It’s not meant to preclude that kind of thing (and reading it again, I don’t think it does preclude it). But rather to just say that whatever the Verifier’s requirements on key binding are have to be based on its policy and not on the content of the token (some of which could be manipulated by the holder). A Verifier’s policy could, as you describe, afford different levels of access based on different security characteristics of the presented token/credential. Or the Verifier’s requirements could, for example, say that for credential type A, Key Binding is always required, while for credentials of type B, it is only required when the credential was issued by an issuer that is known to issue credentials supporting Key Binding. 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.
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:
MUST be created in such a manner that it is cryptographically random, long enough, and has high entropy that it is not practical for the attacker to guess.  A new salt MUST be chosen for each claim <del> independently from other salts. </del> <ins> independently from other salts.  See Randomness Requirements for Security RFC4086 for considerations on generating random values. </ins> 11.4.

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:
MUST be created in such a manner that it is cryptographically random, long enough, and has high entropy that it is not practical for the attacker to guess.  A new salt MUST be chosen for each claim <del> independently from other salts. </del> <ins> independently from other salts.  See Randomness Requirements for Security RFC4086 for considerations on generating random values. </ins> 11.4.

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:
5.2.3. If an endpoint cannot ensure that its peer always has available flow <del> control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.  This will result in degraded performance. </del> <ins> control window space that is greater than the peer's bandwidth * delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.  This will result in degraded performance. </ins> Sending timely WINDOW_UPDATE frames can improve performance. Endpoints will want to balance the need to improve receive throughput

Related discussion:
text: This looks terrible, but it's the form that the RFC we cite uses (also, RFC 1323).
: We changed "Flow Control Performance" to "Flow-Control Performance" per the title of ("Flow-Control Principles"). Please let us know any concerns. Original: 5.2.3. Flow Control Performance Currently: 5.2.3. Flow-Control Performance
and 5.2.3: Should "bandwidth-delay product" be written as "bandwidth * delay product" per RFC 7323? Original: Note, however, that this can lead to suboptimal use of available network resources if flow control is enabled without knowledge of the bandwidth-delay product (see [RFC7323]). Even with full awareness of the current bandwidth-delay product, implementation of flow control can be difficult. ... If an endpoint cannot ensure that its peer always has available flow control window space that is greater than the peer's bandwidth-delay product on this connection, its receive throughput will be limited by HTTP/2 flow control.
I think "bandwidth-delay product" is the standard representation of the term. It's not a term specific to this document but a broader term of art. I recommend not taking this suggestion.
Thanks, I hate it.
Code change:
contains a short hypertext note with a hyperlink to the different URI(s). <ins> 9.4.9. The status code indicates that the has been assigned a new permanent URI and any future references to this resource ought to use one of the enclosed URIs.  Clients with link editing capabilities ought to automatically re-link references to the effective request URI to one or more of the new references sent by the server, where possible. The server SHOULD generate a header field in the response containing a preferred URI reference for the new permanent URI.  The user agent MAY use the Location field value for automatic redirection.  The server's response payload usually contains a short hypertext note with a hyperlink to the new URI(s). A 308 response is cacheable by default; i.e., unless otherwise indicated by the method definition or explicit cache controls (see heuristic.freshness). </ins> 9.5. The

Related discussion:
text: Good catch.
...currently defined in RFC 7538.
This would obsolete 7538?
Yes. Now the good question is how much of RFC 7538 include. My proposal would be just to include parts of URL, but to point back to RFC 7538 for additional information (non-normatively).
Seems reasonable to me.
Maybe we should also add the table from URL somewhere.
Possibly at the top of the 3xx section.
Code change:
A server decides whether or not to offer a client the ability to send early data on future connections when sending the TLS session ticket. <ins> TLS TLS13 mandates the use of replay detection strategies that reduce the ability of an attacker to successfully replay early data.  These anti-replay techniques reduce but don't completely eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. </ins> When a server enables early data, there are a number of techniques it can use to mitigate the risks of replay: <del> TLS TLS13 mandates the use of replay detection strategies that reduce the ability of an attacker to successfully replay early data.  These anti-replay techniques reduce but don't completely eliminate the chance of data being replayed and ensure a fixed upper limit to the number of replays. </del> The server can reject early data at the TLS layer.  A server cannot selectively reject early data, so this results in all requests sent in early data being discarded.

Related discussion:
text: This will conflict with the changes ekr suggested, but I integrated them, so merging shouldn't lose the important changes.
For "sent in early data on another connection", I think Spencer's proposal "sent in early data on a previous hop" would make it even clearer regarding the hop chain so as not to confuse this with another connection from the same user-agent. OK for the rest.
Code change:
NAT traversal, a QUIC protocol extention would be required to support those use cases today. <del> 6.2. </del> <ins> 7.2. </ins> The creation of new media transport protocols should be avoided, and instead we should make use of RTP RFC3550 and the existing ecosystem

Related discussion:
text: This is just a starting point, but brings the document closer to alignment with our spreadsheet. I've also added some additional details which should cover themes raised in the current BoF agenda.
Code change:
5. This specification defines the following authentication parameters. <del> These parameters use structured fields (STRUCTURED-FIELDS) in their definition, even though the Authorization field itself does not use structured fields.  Due to the syntax requirements for authentication parameters, the byte sequences defined below SHALL be enclosed in double-quotes (the base64-encoded data and colon delimeters are enclosed in double-quotes, see example in example). </del> <ins> All of the byte sequences below are encoded using base64url (see BASE64) without quotes and without padding.  In other words, these byte sequence authentication parameters values MUST NOT include any characters other then ASCII letters, digits, dash and underscore. The integer below is encoded without a minus and without leading zeroes.  In other words, the integer authentication parameters value MUST NOT include any characters other than digits, and MUST NOT start with a zero unless the full value is "0". Using the syntax from ABNF: </ins> 5.1.

Related discussion:
text: This nags at me a bit. I think you want to be crystal clear are what parts of Stuctured Fields you are and what you aren't. As far as I see, you want to use the aspect in order to reuse the serialization/deserialization, legal characters, legal range, etc., for the auth parameter values. But you don't need the aspect, which would allow you to parameterise the parameters. Does that sound accurate?
We added this sentence based on a URL from NAME Martin, do you have thoughts here? I think the intent was just to point out that we're in the new structured fields world even though Authorization hasn't been retrofitted yet
In , NAME pointed out that we can't simply use byte sequences from structured fields because authentication parameter values need to be which doesn't allow non-quoted colons. So I switched to double-quotes in dcc520544cf98cf634c9ca0a24119256fd18d58e, but that makes the usage of structured fields somewhat messy. Thoughts?
Copying my comment from the change
Good call. I now added both colons and double-quotes via 690ee072bb450ab631db5b32a23b457cec9bb6be
From Ilari Liusvaara on the : I renamed this issue to track whether we want to keep structured fields or not. Personally, I don't have a strong opinion either way.
I could live without structured fields here, presumably there are servers that already have to handle Authorization fields using the more-traditional encodings
I'll note however that if we go with we'll need to either double-quote it or explicitly ban padding, because is not allowed as part of
While base64 proper is often padded, it is more common for base64url to be unpadded (indeed, I think that the string "base64url" specifically refers to the unpadded version if you follow it to its origin, which I think is URL).
dates back at least as far as and that spec explicitly : None of which is a problem, we just need to be explicit. We know how to do that.
Right, the 7515 thing was what we ended up using in another context, where padding was explicitly not included. Clearly, we shouldn't use it here either[^1].
Code change:
5. This specification defines the following authentication parameters. <del> These parameters use structured fields (STRUCTURED-FIELDS) in their definition, even though the Authorization field itself does not use structured fields.  Due to the syntax requirements for authentication parameters, the byte sequences defined below SHALL be enclosed in double-quotes (the base64-encoded data and colon delimeters are enclosed in double-quotes, see example in example). </del> <ins> All of the byte sequences below are encoded using base64url (see BASE64) without quotes and without padding.  In other words, these byte sequence authentication parameters values MUST NOT include any characters other then ASCII letters, digits, dash and underscore. The integer below is encoded without a minus and without leading zeroes.  In other words, the integer authentication parameters value MUST NOT include any characters other than digits, and MUST NOT start with a zero unless the full value is "0". Using the syntax from ABNF: </ins> 5.1.

Related discussion:
text: [^1]: I hold the view that it shouldn't be used in any situation, because if knowing the length is important, you would have a length prefix or delimiter, rendering padding pointless for anything other than protection against traffic analysis. And you can't arbitrarily pad with base64 padding, so that's no good.
I'd ideally want to align with draft-ietf-privacypass-auth-scheme. We reviewed this a lot with NAME and went back and forth and ended up with: So from a syntax standpoint, this is "base64url and you don't need quotes, but do include quotes if you have padding". If you define that you don't use padding, then you don't need quotes. So I think things can be consistent here.
Based on the conversation in the room at IETF 117, I'm inclined to make these no longer structured headers, and to use base64url without padding, without quotes, and without colons.
Code change:
The status-code element is a 3-digit integer code describing the result of the server's attempt to understand and satisfy the client's <del> corresponding request.  The rest of the response message is to be interpreted in light of the semantics defined for that status code. See status.codes for information about the semantics of status codes, including the classes of status code (indicated by the first digit), the status codes defined by this specification, considerations for the definition of new status codes, and the IANA registry. </del> <ins> corresponding request.  A recipient parses and interprets the remainder of the response message in light of the semantics defined for that status code, if it is understood, or in accordance with the class of that status code indicated by its first digit if it is not. HTTP's core status codes are defined in status.codes, along with the classes of status codes, considerations for the definition of new status codes, and the IANA registry for collecting such definitions. </ins> The reason-phrase element exists for the sole purpose of providing a textual description associated with the numeric status code, mostly

Related discussion:
text: "Highest ordered" implies some numerical rank-list of ordering, but we don't seem to clearly indicate whether older or newer requests receive higher numerical indices. It seems simples to just say "oldest" (or "newest", if that was the intent) rather than applying numerical ranking. Editors:
closure alert is received, an implementation can be assured that no further data will be received on that connection. TLS implementations MUST initiate an exchange of closure alerts before closing a connection. A TLS implementation MAY, after sending a closure alert, close the connection without waiting for the peer to send its closure alert, generating an "incomplete close". [...] TLS implementations (not placing restrictions on what TLS implementations are suitable for HTTPS). Fortunately, these "MUST initiate" and "MAY close without waiting" requirements seem to already be present in RFC 8446... I'm not a TLS expert. That said, if this is correct, would be lowercasing the two keywords be sufficient?
URL is for section 9.8
Change for 9.8 LGTM (as what might pass for a TLS expert).
suggestion