22F/ KERI Roadmap (and how to contribute)
KERI Roadmap (and how to contribute)
Thursday 22F
Convener: Sam Smith
Notes-taker(s): Ajay Jadhav
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
https://didme.me/did:meme:1zgs8suu9h3sjfx9cl2c0pf279wk76yy8z7zwuzxwvvcurtaxc5pyj4qt76hnq
https://www.github.com/decentralized-identity/keri/
IIW! - Oct20-22 (Tu-Th)
Intros
Dave Huseby - Security Maven still? - COME ON IN, THE WATER’S FINE!
Crate builder?
Joachim (Jolocom) - contributes to admin/positioning/comms roadmap items
Charles (Jolocom) - Github contributions welcome (primary editor of /keriox repo)
Joel Hartshorn - USAid dev eng - identity first, then blockchain, then identity
Micheal Shea - stalking KERI for a while - happy to try to help with writing and business -
Use cases! PARTIC IOT
There’s already an issue open!
Michal (HCF) - /keriox contributor and also working on TDA
Robert (HCF)
Shivam (Spherity) - /kerijs primary contributor
Steve Todd (independent) - enthusiast! Jive co-founder, knows Sam from them
Been working on a Java implementation JKeriLOL
Ajay Jadhav (AyanWorks) - interested in ledgerless
WASM? or Node.JS?
Charles: React Native and Node.JS aren’t the best API; we prefer/recommend WASM wrapper from our experience
Deno.land? Consumes rust library and TS directly
Charles: Git issues for advice on ergonomics, aesthetics etc of Rust APIs welcome!
John Walker (ToIP DSWG & CCI) - Semantic Web first, identity second; PHI focus; I’m just here to understand the roadmap and see where I can contribute down the road
Mark Lizar (ToIP DSWG; Kantara; etc) - Notice and Consent as EVENT/signature log -
Sam: Georgia Law review paper on consent chaining
Mark: ISO crossborder consent paperwork (but begs the question of crossborder metadata-trackable identity)
Sam: Forensic compliance/auditability versus interactive crypto; automatic/passive signatures require less laws and regs to change
Mark: International law transfer use cases; consent ←→ surveillance is a hard circle to square without portable/standardized consent receipt semantics; we are working on
Sam: Verifiable credential proves authenticity, not veracity (doesn’t line up well to legal concepts)
Mark: Event key logs are what we need to fit to legal frameworks from CA era - don’t want to skip that step!
Unified data control vocabulary (another ToIP project)
Roadmap Report-out (on-cam)
Joachim: development and other functions in parallel (spec writing and implementation guidance as well as marketing/positioning)
Messaging / FAQs:
Robert: Align with other communities? How to be more open to other communities or prevent reduplicated efforts? Provide the library for AcaPy?
Implementations (Py & Ox first)
Last two event types
Delegating rotation and interaction events - different verification process, involved delegation seal
Delegated inception and rotation events- different verification process
Witness library
Witnessing logic for KAACE
Validator (depends on ^)
Watcher logic/calls
Networking (HTTP & UDP still pending)
Ajay: gRPC between two KERI agents? More bidirectional streaming options?
Sam: WebSockets (TCP tunnel); that can be added later for adoption purposes, but not necessary for core spec;
Sam: I’m more interested in standardizing APIs first
Steve: HTTP has lots of infrastructure
Recovery
Discoverability mechanism - for finding and getting the log anytime you have the [current? Or also historical?] key
Simpler version: Out-of-band / IP discoverability
Kademlia DHT - publication (equivalent of did resolution mechanism?) digest of service endpoint
Ledger-based discovery for DID world
Charles: as many as possible :D
Cname: KERL:: A : discoverability mechanism
Witness API → Service endpoints that can be queried multiple ways
Robert: How do you get the service endpoint from an ID if that’s all you have? <20 minutes follow>
Proposed Action Items (within the WG)
Charter of new WG
Scope should include independent discovery mechanism (will be separately donated)
But out of scope of core spec
Scope should include at least one popular ledger-based discovery mechanism (ideally today’s Indy)
But out of scope of core spec
Credential master issuance middleware/containers ; “Processing layer” (//Trinsic and Evernym’s DID issuance APIs); a KERI ID issuance API seems like the next step for scaling infrastructure and aaS models
But out of scope of core spec
Reference wallet
1: Universal wallet spec + Keri libraries from Jolo wallet → https://github.com/jolocom/rust-multi-target
SemVer protocoling (major and minor have to align for trust)
Update Py demo (lessons learned from demo)
Console options
Verbose error methods (debugging mode)
Curves needed for 1st release
secP256k1 helps with NIST compliance
DAVID: SEND ME A DELTA OF THE CURVES YOU NEED IN URSA
Workshops on architecture mapping in WG (for documentation parallel efforts)
Integrate KeriPy to AcaPy (or maybe KeriOX, with appropriate wrapper, for AriesJS)
Issuing VCs against KERI IDs
Michal: Indy is Rust-friendly
Mark Lizar: Use case pull request on international law transfer use cases or ISO informed consent receipt standards?
AriesJS - separate item, if AyanWorks or other AriesJS volunteers help-- Spherity not the best for this :D
Adoption within DID Community
Drummond & Indy Inter-op-athon: new namespace hierarchy for next V of did:indy (and Drummond is onboard to incorporate DID:Un/KERI)
DID:Indy:FINDY/etc:KERI - sub namespace
“DID: <keriID>” might require some more substantial lifting in W3C
Deadline? As yet unknown; DID Core Spec reaches Recommendation when? (2yr charter ends Sept 2021)
