Tobias, A good example of this that we deal with is in the Agriculture space. A credential is signed and issued with complete details back to the regulatory agency or an authorized third party. At that point, depending on the results and details of the inspection they may selectively disclose portions of that inspection based on a need to know to other parties involved in the supply chain. What needs to be disclosed, and to whom, is not always known at time of issuance, and this type of operation typically occurs in areas where network connections can be quite spotty, making additional data overhead undesirable.
This is a simple case, but quite normal, and the proposed approach with BBS+ very neatly meats the requirements that we have from a technical side, while also meeting our customers' needs. Cases similar to this, but more complex as a result of having hardware in the mix, also arise with telemetry data related to pesticide and herbicide applications, etc. Mike Prorock mesur.io On Wed, Jul 27, 2022, 19:09 Tobias Looker <[email protected]> wrote: > > 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 you correctly, the biggest limitation with that approach > is that it requires the holder/prover to be online and able to contact the > issuer in realtime to get what it requires for presentation. That might be > an acceptable constraint for some use-cases but not all. > > Issuing each claim as a JWT as an approach to selective disclosure makes > the representation of every claim pretty large too (e.g claim name + > value + a base64 header + base64 signature). You'd probably want to wrap > all of these in another JWT also to establish their relationship to one > another which further bloats the overall credentials representation. > > Thanks, > Tobias > > On Wed, Jul 27, 2022 at 5:16 PM Neil Madden <[email protected]> > wrote: > >> >> On 27 Jul 2022, at 17:20, Tobias Looker <[email protected]> wrote: >> [..] >> >> 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. >> >> >> 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? >> >> — Neil >> > _______________________________________________ > jose mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/jose >
_______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
