I sent this from my phone earlier today, but meant to reply all. ---------- Forwarded message --------- From: Orie Steele <[email protected]> Date: Wed, Jul 27, 2022 at 3:49 PM Subject: Re: [jose] JWP To: Tobias Looker <[email protected]>
Thanks for your comments Tobias. I've been working though similar use cases using merkle proofs. A major reason I find JWP or CWP attractive is not overloading existing serialization formats. For example, conflating alg none, with alg ES256. These are pretty different, and making them look similar raises a number of challenges. Similarly, while a secret signature and derived proofs might look similar at first, there are important differences. There comes a point where bending an existing serialization, can start to weaken it's meaning and introduce security issues. I think the use cases for JWP demand a unique representation separate from JWS/JWE to be done safely. Regards, OS On Wed, Jul 27, 2022, 12:23 PM Tobias Looker <[email protected]> wrote: > Hi Richard, > > See below for some thoughts on your feedback > > > It seems like the two problems people are proposing to addressed relative > to base JWT are (1) selective disclosure of claims and (2) unlinkability, > in the sense of being able to derive unlinkable "presentations" from an > issued "credential" (using those terms in the sense of W3C VC). > > > On the selective disclosure side: The objective here seems clear and > uncontroversial to me, but it also seems like it doesn't require any > changes to JWS/JWT. The SD-JWT work [1] seems to validate this. What > selective disclosure property is not provided by SD-JWT that JWP would > provide? > > While I agree with you that these are separate properties (selective > disclosure and un-linkability), how they are realized is different across > different cryptographic algorithms. > > SD-JWT is designed for a single specific cryptographic approach to realize > selective disclosure, its a simple and effective scheme. However, the > notable limitation to this approach is that you cannot use it to achieve > un-linkability (if your usecase requires this) you instead need a > fundamentally different approach from a cryptographic perspective. For > instance a scheme such as BBS signatures does not hash each claim value > with a unique salt as is the case with SD-JWT, instead it requires no > per-claim salt at all. This means the `_sd` style structure that SD-JWT > uses inside the JWT payload > does not fit. > > JWP accounts for this in its design by encoding each claim value that is > to be selectively disclose-able separately so it can then be appropriately > handled at the cryptographic layer by different algorithms. > > > On the unlinkability side: I assume the underlying presumption here is > that > the credential from which presentations are being generated is a JWT, and > that the JWP is something that someone other than the issuer would generate > from that JWT such that different JWPs derived from the same JWT are not > linkable with each other or with the source JWT. It seems like there are a > few threshold questions to be addressed before chartering work here: > > JWP is more akin to an alternative to JWS that supports a wider range of > cryptographic algorithms capable of selective disclosure and or > un-linkability, I'd also offer proof of possession as a third property > here. Within JWP there are two forms, the issued form and the presented > form. > > > 1. What transformations are necessary for unlinkability? Clearly the > Issuer's signature has to change. In cases where the credential is > associated to a public key for the Holder (e.g., a "did:jwk" identifier), > it would be necessary for different presentations to have different > associated public keys. > > It differs across cryptographic algorithms, i've attached a picture that > might help to explain a scheme like BBS, fundamentally there are two key > structures, signatures and proofs. Signatures are produced by issuers, > proofs are produced by provers. > > > 2. What transformations can the Holder make? The Holder is creating > statements that the Issuer has never seen, which the Verifier will trust as > if they came from the Issuer. The framework here needs to assure that any > statement the Holder can generate is one that the Issuer would have made > themselves. > > > 3. In what sense is the Holder a privileged role? For example, if a > credential were to leak to a their party, could that third party perform > the same transformations as the intended Holder? If there is a separation > between the Holder and any other party, how is it enforced? > > Speaking for a scheme like BBS specifically, a generated proof proves > cryptographic integrity over: > > 1. The header: Defined by the issuer/signer when the signature is created, > the holder when generating a proof is unable to modify this in anyway nor > choose > about whether to disclose it, it must be disclosed in any generated proof. > 2. The set of issuer signed messages: Defined by the issuer/signer when > the signature is created, the holder when generating a proof is only able > to select (not modify) which of the issuer signed messages to disclose to a > verifier with the generated proof. > 3. Presentation header: Set by the holder during proof generation, is > integrity protected by the generated proof > > Beyond proving integrity of the revealed messages and header back to the > original issuer/signer via their public key, the proof also confirms to a > verifier that the party who generated the proof is in possession of the > signature, which remains secret to the holder (un-revealed in the proof), > if this were to leak to another party then they too could generate valid > proofs. > > > 4. To what extent are those constraints dependent on the ciphers used? > It > would not be good to create a generic container format that requires deep > analysis to determine whether an algorithm is safe to use. JWS has "alg: > none" vulnerabilities, but if you use a real signature algorithm, you get > the properties you expect. > > Different ciphers will have different properties here. As is the case with > any cryptographic representation format the trick is to try and generalize > the right amount to accommodate these different algorithms safely. > > > 5. Why are these transformations not possible within the bounds of > JWS/JWT? > > Do the above explanations I've provided help? > > Something else to add, is that JWP also allows for the same cryptographic > algorithm approach to selective disclosure as SD-JWT, its just the > representation layer is different and therefore the relationship the > algorithm has to the representation layer is such. See > https://github.com/json-web-proofs/json-web-proofs/blob/main/draft-jmiller-jose-json-proof-algorithms.md#message-authentication-code > for > more details. Note there are some subtle differences to this description > (e.g the usages of HMAC instead of just hashing a salted value) but it is > fundamentally an equivalent cryptographic approach. > > Thanks, > Tobias > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose > -- *ORIE STEELE* Chief Technical Officer www.transmute.industries <https://www.transmute.industries>
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
