I’m not entirely sure the OAuth WG is a suitable venue for this kind of document. It should at least get some review from CFRG, to get feedback on the crypto aspects.
I have some initial comments about the cryptography being used. Commitments to claim values are of the form HASH(SALT | CLAIM-VALUE), but this does not necessarily commit the sender to CLAIM-VALUE. In section 7.4, I think you need to say that HASH must be collision resistant - otherwise the user can find two (salt, claim-value) pairs that collide and get the issuer to sign one and then reveal the other pair to the downstream party. The fact that HASH(SALT | CLAIM-VALUE) is vulnerable to length extension attacks is also troubling, even if I can’t see an immediate attack. But it’s a weird property that Bob, for example, could make a commitment to some extension of one of Alice’s claims without actually knowing her claim value. You can address both of these issues by instead using a compactly committing PRF [1], such as HMAC- i.e., HMAC-HASH(SALT, CLAIM-VALUE) rather than simple prefix hash. It doesn’t seem great to say that you can use any hash algorithm in the IANA registry, but then to rule out half of them as being not suitable in the security considerations - this list may go out of date as other hash algorithms are broken. Is it possible to update the IANA registry with a Recommended Y/N column? Also, shake128 and shake256 are not collision-resistant hash functions, they are XOFs that can produce any length of output - e.g. shake128 with a 32-bit output would not be collision-resistant and thus would not be at all suitable for this usage. Given these considerations, I might be tempted to create a new IANA registry, or perhaps just pick one good hash function. (Or maybe just use the same hash algorithm as the signature?) Also, I don’t think the security considerations currently say anywhere that salt values should be distinct for each claim. Obviously that is quite a crucial requirement! [1]: https://link.springer.com/content/pdf/10.1007/978-3-319-63697-9_3.pdf <https://link.springer.com/content/pdf/10.1007/978-3-319-63697-9_3.pdf> — Neil > On 23 Jun 2022, at 17:32, Daniel Fett <mail=40danielfett...@dmarc.ietf.org> > wrote: > > All, > > Kristina and I would like to bring to your attention a new draft that we have > been working on with many others over the past weeks. "Selective Disclosure > JWT (SD-JWT)" describes a format for signed JWTs that support selective > disclosure (SD-JWT), enabling sharing only a subset of the claims included in > the original signed JWT instead of releasing all the claims to every > verifier. > > https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html > > <https://www.ietf.org/archive/id/draft-fett-oauth-selective-disclosure-jwt-01.html> > > Initial feedback we got was positive and we now would like to hear from the > working group with the eventual goal of asking for working group > adoption. > > Issues are tracked in our GitHub repository: > https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues > <https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues> > > The approach to selective disclosure described in the document is based on > salted hashes. We have discussed and explored other approaches based on > encryption as well. If you are interested in following this discussion, we > would like to invite you to read this issue: > https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30 > <https://github.com/oauthstuff/draft-selective-disclosure-jwt/issues/30> > > One main goal with this work is that the format should be easy to implement, > requiring little more than a regular JWT library. Three working > implementations show that this goal has been achieved: > https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations > <https://github.com/oauthstuff/draft-selective-disclosure-jwt#implementations> > > > We are looking forward to your feedback! > > -Daniel > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth
_______________________________________________ OAuth mailing list OAuth@ietf.org https://www.ietf.org/mailman/listinfo/oauth
