5K/ When Do We Need a Ledger? (KERI, ORB, DID:WEB, IPFS)

When Do We Need a Ledger? (KERI, ORB, DID:WEB, IPFS)

Session Convener: Richard Esplin

Notes-taker(s): Benjamin Goering

Tags / links to resources / technology discussed, related to this session:

KERI https://github.com/decentralized-identity/keri Orb https://github.com/trustbloc/orb did:web https://w3c-ccg.github.io/did-method-web/ did:key https://w3c-ccg.github.io/did-method-key/

Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:

Summary Ledgers are needed when:

• The DID Controller should not be able to change what they said about their DID Doc
• Non-repudiable history is needed.
  • Key was rotated, but the cred wasn’t revoked.
• Provable certainty of the current state is needed (as opposed to KERI’s probabilistic statements about state).
• A common understanding of state, not based on a specific selection of peers
  • Governance framework
  • A schema attached to a framework
• Censorship resistant data availability
• Publicly auditable history

Also had a discussion about ORB vs KERI

• Orb: consensus set consists of peers in the checkpoint blockchain
• KERI: consensus set consists of peers that have your event log

Detailed Notes

• Attendee intros
• Aaron: dweb projects use consensus more than is required. Only maybe needed for namespace mgmt
• So, time travel: How do you verify credentials that may or may not be revoked
• Richard: Proving a did doc is true at some point in time, censorship resistant, nonrepudiable is hard. (Time matters). Revocation registries might make more sense on a ledger.
• CharlesCunningham: I agree
• Richard: Starting with a use case where a ledger/consensus is required. 1 is time travel. (Verifying credential when issuer is down)?
• Rouven: Do we have consensus of the latest state of my DID document
• Chris: You can make a probabilistic argument, not a million percent certain.
• Rouven: How do I know that my friend didn’t get hacked, rotate keys, and someone comes later. Including key recovery use cases.
• Aaron: How do we define the consensus group.
  • One option is authoritative. e.g. the UN. Or you could say that the object creator decides what the consensus group is.
• Charles: This is how KERI works
• Rouven: If you have network of friends that are my witnesses, can power this. But you still then have to trust your friends.
• Shannon: I’m saying the same thing. If you don’t trust, then there is a use case for consensus.
• bengo: got it
• Richard: keri/orb aren’t as much for distributed consensus as much as a ledger
• Charles: If you want to update your DID doc, then you need a ledger or other mechanism of linked signed events that provide atomic updates
• bengo: like sidetone
• Charles: Even if the person that owns the did document could lie to me. You could have an issuer that just lies to you.
• Steve: Duplicity game. Alice is communicating with Bob and Charlie. Alice is consistent with each of them, but not the same.
• Rouven: There are other ways that can happen, e.g. software updates across multiple devices
• bengo: The software update supply chain problem
• Steve: Watchers watching the watchers.
• Bengo: but who’s watching the watchers
• Steve: different kinds of events in KERI are given more credence
• Charles: It depends on what we mean by sovereignty. It’s a matter of sovereignty. Is it ok for an issuer to ‘lie’ about the did doc? In ETH, the scarce resource is Did Documents. In KERI, the public keys are the scarce resource. You can either have one set or a different set. You could have two separate logs for the same identifier. They started with the same private keys. But they wouldn’t be a ‘good issuer’. Verifiers wouldn’t like.
• Richard: Does ORB help with this?
• Dmitry: ORB is fairly simple, and I don’t know KERI. ORB does atomic updates by writing a record into whatever database it’s relying on.
• Richard: IPFS?
• Dmitry: There is still a database, it’s up to each node, or a distributed database
• Dmitry: Does that have an inherent risk: yes
• Dmitry: Network of issuers is a network of trust issuers. They’re all reputable issuers that don’t want to do evil.
• bengo: It makes trust nonbinary, but instead asymptotic
• Richard: And you’re saying orb publishes those events using ActivityPub?
• bengo: /thumbsup
• Rouven: If I now need to make sense of ‘can I trust this’?
• Rouven: Passports are an important use case. And we want to make it easier and more standardized for countries to verify them, and global consensus is kinda like that
• Rouven: Don’t want everyone to use the universal resolver
• Aaron: Like Metamask
• Rouven: We need to narrow down the number of DID methods so it’s less likely for people to centralize the verifier
• Dmitry: One of the reasons we made ORB. A Verified network. We launched it 3 years ago with banks and govt starting 4.5 years ago. Uses JWT for VC. Uses Anonymous identifiers. Use blockchain. Uses hyper ledger fabric. 7 years ago that was a very decent project. There weren’t so many back then. Solid enough, lots of contributions. Then we figured out that sovereign place, they’re skeptical of using Fabric/IBM. Maybe we can use bitcoin? All banks and governments say “We’re not touching that”. We have to design something that has two options. You have either have the blockchain independence, meaning you can use whatever blockchain you want. If you are completely against the blockchain, you could survive without it.
• bengo: (or if it’s not accessible to you)
• Richard: Use case where you need to have a list of trusted issuers. You don’t want to go to the whole world. You want a narrow list. That’s one example I had for wanting a ledger. Government frameworks that don’t allow for repudiation. And I don’t think KERI has that property.
• Charles: KERI people would say that that’s a problem for another layer, like an automated governance network.
• Rouven: Register machine readable government network which has policy. Then one ledger.
• bengo: heirarchical consensus
• Aaron: like the olympics logo
• Rouven: It requires a lot of effort to keep the network going. If someone withholds an event, it’s really hard to survive that.
• bengo: Eclipse attack.
• bengo: Gossipsub?
• Dmitry: Does not solve the problem all the way, for example the ‘cost of computation’ issue.
• Rouven: You have timestamping, execution. KERI is simple. Anything more complicated reduction rules after that get way harder. The third problem is data availability.
• Rouven: With zero-knowledge rollups, we can do computation off chain, which helps a lot with cost of computation.
• Aaron: Then you need the whole blockchain though off chain
• Bengo: not with recursive zk proofs
• Rouven: yeah
• Rouven: In a recovery network. I can configure a way of doing recovery anchored on-chain. Only revealed later (via ZK) when recovery is strictly needed
• Charles: Can you have divergent state?
• Richard: One goal we had in indy was to replay the ledger from the beginning. It was useful because we wanted to rewrite history to preserve trust
• bengo: that’s not what most people think is trust.
• charles: something insightful (sorry)
• Dmitry: That was insightful. One question. For many operations, classic schema is issuer issues to holder. Credential is shared many times. One other reason we created ORB was that in the business world we had situations where issuers wanted to issue credentials on the spot based on the RP wanting to know how much is in your bank account. e.g. how many points you have on your drivers license. How does KERI work in this ‘just in time’ context.
• Charles: Verifier would need to get data from you or one of your witnesses
• bengo: The blockchain project shouldn’t decide what the policy is, the end-user should.
• Aaron: How can I verify with ‘finality’ within 5min
• Rouven: Isn’t that user-centric if just my witnesses need to have consensus as to the data that helps verify.