> > > 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? > > Three additional points on the drawbacks to this type of single-use pattern:
1. You're informing the issuer when you need new tokens, and in the subset case which types of tokens you're using. This weakens the privacy goals here which include protecting the holder/verifier relationships and activity from being tracked by the issuer (unlinkability). 2. The single-use pattern (fetch on-demand or pre-fetch batches) requires an ongoing authenticated relationship with the issuer. While in common cases that may be low friction, it is not universally true and any fetch could trigger a new or step-up authentication challenge and interrupt whatever presentation was in progress. It'd be very annoying if my online banking auth process randomly kicked in while using Apple Pay, for example. 3. Returning to the issuer is not always possible or may be high friction. Issuers should not be required to have highly-available cloud services with authentication infrastructure just to be able to support a privacy-preserving token experience. This also limits the P2P use-cases, where one person is issuing a token to another person, the issuing person shouldn't be required to have centralized cloud infrastructure to refresh that token. While the initial JWP drafts include two single-use algorithm definitions that do have the above limitations, the thought on the approach was to create an easier path to adoption with a compatible container syntax. Brian Campbell asked a good question directly relating to this at the BoF that I've asked myself before and am quite interested in thoughts on either way: should one of the foundational security assumptions of using a JWP be this support for unlinkability, and therefore we only focus on algorithms that can support it without the above single-use drawbacks? I'm currently tilted towards having the more easily adoptable NIST-approved algorithms with the single-use restrictions. Jer
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
