BBS+ JSON-LD ZKPs and Aries & Indy Your Thoughts? Slides: https://bit.ly/BBSPlusIA --- ## BBS+ JSON-LD ZKPs - W3C verifiable credentials (pending signature scheme recognition) - Ledger-based DIDs (at least) - JSON-LD context for schema - On-the-fly "credential definition" generation - Selective disclosure (and maybe predicates in the future) - ZKP "Proof of Non-Revocation" (pending but straight forward) --- ### Aries and BBS+ Credentials - Use the protocols we have ([RFC 453 Issue Credential V2](https://github.com/hyperledger/aries-rfcs/tree/master/features/0453-issue-credential-v2)) - Lean on the "negotiation" capabilities - Add the libraries (shared/Rust or per stack) - Learning JSON-LD; notably context handling in production - Presentation Request format - Including wallet query to find credentials - Opens up the "what ledger?" discussion - Which we in the Indy world desperately need... --- ### Indy (Anoncreds 1.0) Credentials - Ledger-based Issuer DIDs, schemas and credential definitions - Issuers must be registered - Flat list of attributes and values - Implied normalization based on string format - Selective disclosure and predicate support - Ledger-based revocation registry definition, external tails file - Merkle Tree based Revocation coming Real Soon Now --- ### Discussion - With Conversation Starters - Do we [pare](https://www.thoughtco.com/pair-pare-and-pear-1689587) back the use of the Indy ledger to "just DIDs"? <!-- .element: class="fragment" data-fragment-index="1" --> - Do we keep schema and cred defs? - How? Convert to JSON-LD? - Canonicalization (which one?) with BBS+ <!-- .element: class="fragment" data-fragment-index="2" --> - Keep the revocation registry on the ledger? <!-- .element: class="fragment" data-fragment-index="3" --> - Where do we go with Rich Schema? - Just drop the explicit mapping and adopt BBS+ normalization? <!-- .element: class="fragment" data-fragment-index="4" -->