jiebi/CodeConvo huggingface dataset:
Code change:
7. <del> Being JSON, an object in an SD-JWT payload MAY contain key-value </del> <ins> Being JSON, an object in an SD-JWT payload MAY contain name-value </ins> pairs where the value is another object or objects MAY be elements in arrays.  In SD-JWT, the Issuer decides for each claim individually, on each level of the JSON, whether the claim should be selectively

Related discussion:
text: And a malicious Issuer isn't something that's in scope and could do all kinds of other bad things. This is the section of the security considerations with that: URL signature algorithm would probably be worthwhile. Furthermore, preimage resistance is not a sufficient property to ensure section-11.5 along with some text that says that it needs to be “infeasible to calculate the salt and claim value that result in a particular digest”. We are trying to say that the hash has to have the property that it can’t be reversed (or even partially reversed, to your point). There’s probably a better way to state that the hash function has to be not at all reversible. Can you perhaps suggest some text? Or could we just replace “preimage resistant” with “irreversible” in that text in 11.5? 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.
Code change:
7. <del> Being JSON, an object in an SD-JWT payload MAY contain key-value </del> <ins> Being JSON, an object in an SD-JWT payload MAY contain name-value </ins> pairs where the value is another object or objects MAY be elements in arrays.  In SD-JWT, the Issuer decides for each claim individually, on each level of the JSON, whether the claim should be selectively

Related discussion:
text: 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”. 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.
Code change:
7. <del> Being JSON, an object in an SD-JWT payload MAY contain key-value </del> <ins> Being JSON, an object in an SD-JWT payload MAY contain name-value </ins> pairs where the value is another object or objects MAY be elements in arrays.  In SD-JWT, the Issuer decides for each claim individually, on each level of the JSON, whether the claim should be selectively

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:
7. <del> Being JSON, an object in an SD-JWT payload MAY contain key-value </del> <ins> Being JSON, an object in an SD-JWT payload MAY contain name-value </ins> pairs where the value is another object or objects MAY be elements in arrays.  In SD-JWT, the Issuer decides for each claim individually, on each level of the JSON, whether the claim should be selectively

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:
7. <del> Being JSON, an object in an SD-JWT payload MAY contain key-value </del> <ins> Being JSON, an object in an SD-JWT payload MAY contain name-value </ins> pairs where the value is another object or objects MAY be elements in arrays.  In SD-JWT, the Issuer decides for each claim individually, on each level of the JSON, whether the claim should be selectively

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:
7. <del> Being JSON, an object in an SD-JWT payload MAY contain key-value </del> <ins> Being JSON, an object in an SD-JWT payload MAY contain name-value </ins> pairs where the value is another object or objects MAY be elements in arrays.  In SD-JWT, the Issuer decides for each claim individually, on each level of the JSON, whether the claim should be selectively

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:
MUST NOT attempt to recombine it with a stored representation.  A proxy that receives such a message SHOULD forward it downstream. <ins> A server MUST ignore a Content-Range header field received in a request with a method for which Content-Range support is not defined. No request method in this specification is defined to support Content-Range in a request. </ins> For byte ranges, a sender SHOULD indicate the complete length of the representation from which the range has been extracted, unless the complete length is unknown or difficult to determine.  An asterisk

Related discussion:
text: Note outstanding question on the issue regarding PUT.
NAME any thoughts about whether we should mention PUT?
I don't think we need to.
I think PUT is already covered in PUT.
Hypothetically, you could be uploading a partial representation of an object, so I'm not sure it's worth prohibiting. However, I've not dealt with any systems that allow partial PUTs. Mostly you PUT (or POST) the blocks as individual resources, then make a final call with the blocklist to assemble the object from the existing blocks. Unless anyone has seen it in action, it's worth indicating it's not common practice. Perhaps a note saying that the behavior is dependent on the method and isn't defined for any known methods?
The essential problem is that it is not interoperable in general for PUT without private agreement between client and server. Furthermore, there is a risk of bypassing content filtering for security, etc. I could see it being usable with a new method.
My understanding has always been that you couldn't have a partial request. We've discussed this extensively before; would need to dig up the references.
(it may have been in discussion of PATCH, which is the proper way to do this)
Proposal: ... to align with the language used in Range.
maybe since this case doesn't matter if the method is unrecognized.
Should we mention PUT's requirement to generate a 400 if C-R is present?
Sorry... I just overlooked this, which is related to the ongoing work with digest NAME My understanding is that with a new method, this could be possible.
Fwiw my minor survey showed that most storage oriented services actually seem to offer some variant of request with Content-Range, see URL
But most of these use PUT, for which this is explicitly called out as "MUST NOT".
I'll propose a RESUME method + Content-Range for that.
I think the simplest possible approach would be PATCH with a payload format that just describes offset, length and payload. No need for a new method.
Which brings us back to the discussion about whether we're defining restrictions or describing usage, doesn't it? Lucas's survey demonstrates that PUT with Content-Range is widely used, even if currently prohibited.
The existing restriction is that PUT means make this payload the current representation. There is no way to remove that restriction without breaking interop for PUT, which pre-existed Content-Range by several years.
Code change:
MUST NOT attempt to recombine it with a stored representation.  A proxy that receives such a message SHOULD forward it downstream. <ins> A server MUST ignore a Content-Range header field received in a request with a method for which Content-Range support is not defined. No request method in this specification is defined to support Content-Range in a request. </ins> For byte ranges, a sender SHOULD indicate the complete length of the representation from which the range has been extracted, unless the complete length is unknown or difficult to determine.  An asterisk

Related discussion:
text: We are talking about a dozen private implementations of partial PUT versus a billion deployed servers that will gleefully ignore the Content-Range or store it with the new representation (because it starts with Content-*). The only reason this isn't obvious is because almost all Internet-facing HTTP servers disable PUT, so we are left with a few private servers that don't care about Internet standards.
But if we look inside the firewall at internal servers that support WebDAV and other variants of HTTP PUT, they do not support the use of Content-Range to perform a partial PUT. They would be able to support a PATCH method.
I just checked the code and it seems mod_dav has supported partial PUT on flat files since RFC2616.
This is a very big change at the last minute. At a minimum, it needs to be discussed on list. I'm also not very happy documenting a new feature that admits it's not interoperable or backwards-compatible, based upon one implementation in the wild (so far). IMO a much better way of doing this would be to slightly loosen the requirement to generate a 400 when PUT contains a content-range, saying that it can be allowed by an extension or an out-of-band arrangement. Then, if someone wants to, they can create a separate spec for partial PUT.
Well, sure, but that's what the PR says. I don't see how removing the current requirement to generate 400 (which exists to preserve interop) is possible without documenting what should be done instead to preserve interop, even if that happens to be a "Hail Mary" pass more likely to be dropped than caught. I have no idea if this matches any specific implementation. I'd give it around a 50% chance, as opposed to the 10% that I previously assumed. It definitely needs to be discussed on list, but it seems to match the general intent if we allow Content-Range to be used at all. This doesn't prevent anyone from publishing an update in the future. In any case, I decided to propose it now since I did most of the arguing against this feature in the past.
I'm proposing that we just say something like:
In the interest of getting the spec out, I slightly prefer Mark's proposal. That said, if we can get the description of partial PUT in (and that might be possible), I'm ok with that as well.
Code change:
MUST NOT attempt to recombine it with a stored representation.  A proxy that receives such a message SHOULD forward it downstream. <ins> A server MUST ignore a Content-Range header field received in a request with a method for which Content-Range support is not defined. No request method in this specification is defined to support Content-Range in a request. </ins> For byte ranges, a sender SHOULD indicate the complete length of the representation from which the range has been extracted, unless the complete length is unknown or difficult to determine.  An asterisk

Related discussion:
text: I think the current implementation landscape suggests us to be open about partial representation in requests (and that's what is relevant WRT ). Which were the compelling reasons for forbidding ?
NAME - see URL
BTW, the Google API also uses a status code to indicate a not-ready-yet error.
They promised to get rid of the 308 years ago; maybe it's just the documentation.
NAME do you still aim for this spec to go to full Internet Standard?
Is this a trick question? Yes, I think we should try. But then, we did add other new things, and also did a lot of re-org.