Re: [jose] JWP

[David Waite <[e-mail]>]

On Jul 27, 2022, at 5:16 PM, Neil Madden <[e-mail]> wrote:
>> On 27 Jul 2022, at 17:20, Tobias Looker <[e-mail]> wrote:
<snip>
>> 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.
> 
> 
> If you’re going to do this, why not just ask the issuer to give you multiple tokens in the first place, each containing some subset of claims you want to disclose? In the limit you could issue a separate JWT for each claim. Is there a fundamental reason this doesn’t work?

If I understand, the question is if you could do selective disclosure by signing a number of JWTs (each perhaps with all the mandatory claims and parameters, and a new correlation parameter marked as critical) could verify all of the JWTs were meant to represent a single identity credential and do not conflict, and release some subset of them at once, then discard them to to get unlinkability through single-use.

This could be defined on top of existing algorithms, although it would incur data size, system logic and cryptographic processing penalties. Indeed, this is similar to what the JWS-based algorithm (section 6.1) in JPA starts to define. However, that proposes additional steps to optimize data size in transit by operating on a hierarchy of documents as well as reducing the protected headers conveyed in transit.

Trying to optimize the cryptographic processing might lead you to use salted hashes or MACs, similar to what is described in section 6.3 of that document.

To hopefully both summarize and to answer the question: when constrained to the realm of existing cryptographic primitives in the JOSE family, JWP does attempt to apply and compose those algorithms to define ways to meet a minimal set of cryptographic properties for presentation in a consistent set of serializations. 

There are obviously a number of trade-offs to consider in these new composed algorithms, and improvements to them would be welcomed.

I however want to talk some about the use of the word “just” in the original question. I would posit that use case still has lots of complexity to describe. The processing steps still need to be defined on how to issue and confirm the credentials whether it is a new format or a collection of JWTs. It still needs to define how to present and verify the credentials, with subject confirmation and with the claims being re-consistituted or otherwise interpreted in a meaningful way after being selectively reduced. There would still be security considerations on how to make sure security claims which limit usage such as audience and expiry are not capable of being omitted. There would still be privacy considerations on how to keep the subject claims or other security properties from the credential from turning into vectors for unintended linkability.

Finally, newer cryptographic algorithms with provide more properties (such as multi-use unlinkability and integrated subject confirmation proofs) would not have separate signatures but rather a single proof covering the multiple messages, and thus would not support being decomposed into a "multiple JWT” representation with valid signatures.

-DW