RE: Multi-signature Verifiable Credentials

Manu -- Just to be clear that if I knew HOW to implement WHAT I was looking for, I would be an Implementor and not a Customer :-)

Anil > A mechanism for the Verifier to signal to the Holder/Wallet about the 
Anil > proof formats it supports
Manu >> What's the use case here?

It is less of a use case and more of trying to think out loud around what the art of the possible is now and downstream.

USG Agencies, like my professional home, require that the technologies we use conform to relevant federal government standards and requirements, including the Federal Information Security Management Act (FISMA) and National Institute of Technology (NIST) standards for use of cryptography. Federal Information Processing Standards Publications (FIPS PUBS) are the official series of publications relating to standards and guidelines adopted and promulgated under the provisions of FISMA.

Which is why SVIP funded the independent cryptography review of W3C VCs and W3C DIDs by SRI (http://www.csl.sri.com/papers/vcdm-did-crypto-recs/crypto-review-and-recs-for-VCDM-and-DIDs-implems-FINAL-20211015.pdf ).

So the default, immovable, baseline for us is the use of FIPS compliant cryptography primitives in our implementation of VCs and DIDs. So once that hard, legally mandated compliance requirement is met (which just so happens also provide security/privacy benefits beyond simple compliance), and based on individual agency goals as well as appetite, acceptance, and understanding of risk/rewards, there are additional options that are ... possible.

In particular we have some specific privacy requirements in our personal credential workstream (driven by U.S. Citizenship and Immigration Services) around selective disclosure and non-correlation to which the BBS Signature Scheme could provide solutions. We appreciate that it is on a legitimate and formal standards-track (https://datatracker.ietf.org/doc/draft-irtf-cfrg-bbs-signatures/ ) in a forum (the IETF CFRG) that has international credibility and expertise -- at which the USG Technical Authority on Cryptography (NIST) participates. 

This has an impact on our internal risk/reward calculus on pre-standard use of this tech as our thinking is that there exists measurable and very real privacy benefits to individuals *in this particular case* and we may be willing to incur and accept additional risk to ensure that those benefits are realized by our customers on a faster time-line than is usual. We also acknowledge that private sector implementations may also exist at the pre-standard level.

So, in order for our customers to realize this benefit, I think some mechanism needs to exist for a Verifier/RP to say the following to a Customer/Holder when they show up at the front door >> "You don't need to send us all the attributes in your credential since we support BBS signatures .. If you support it as well, we just want attributes A and B for this is purpose, we will use and manage that information in the following manner X. Do you understand and consent to the release of A and B?"

Happy to explore other ways of reaching the same outcome as nothing is fixed/decided. But we do need more information in order to make thoughtful and informed decisions in this area.

Best Regards,

Anil

Received on Tuesday, 25 October 2022 21:10:45 UTC