> On 28 Jul 2022, at 13:13, Tobias Looker <[email protected]> wrote: > > > (Can the holder choose to selectively not disclose that “cnf” claim? If so, > > yikes). > > No, to prevent this the issuer simply puts these sorts of claims in the > header, which is not subject to selective disclosure, e.g the prover cannot > create a valid proof/presentation without disclosing the original un-modified > header.
That is a very non-standard use of the header. AFAICT such usage is not compatible with RFC 7800, and I would guess that it may well lead to security issues as implementations won’t be looking for these claims in the header but rather in the claims set. (You can duplicate JWT claims into headers, but making the header itself the source of truth is a big change to how things are today). > > > In current usage, PoP is usually applied and linked to clients (apps) not > > individual users, so one simple approach would be to take the FIDO/WebAuthn > > approach and require the client to reuse the same key for at least 10,000 > > users to prevent linkability. That’s obviously not a universally applicable > > approach, and I would be in favour of new privacy-preserving PoP schemes. > > Yes and to be clear cryptographic schemes like BBS are IMO an example of what > you describe as a privacy-preserving PoP scheme, they just also support > selective disclosure. I would be quite happy to see a proposal for an RFC 7800 confirmation method based on BBS signatures. (Assuming BBS signatures get through CFRG). — Neil _______________________________________________ jose mailing list [email protected] https://www.ietf.org/mailman/listinfo/jose
