DIF Did’s In-Depth (w/Review of Contentious Bits)
Decentralized Identity Foundation (DIF) technical/org recap & roadmap discussion … followed by DIDs in depth (with review of contentious bits)
Tuesday 1F & 2F
Convener: David Buchner followed by Drummond Reed
Notes-taker(s): Scott Mace
Discussion notes, key understandings, outstanding questions, observations, and, if appropriate to this discussion: action items, next steps:
Daniel Buchner on Decentralized Identity Foundation
Done quite a bit of work in the five months since founded.
Engineering-driven organization, not like a SDO like W3C.
Instead, focusing on developer tools, interoperable specs and implementations.
The goal is to pave the cow paths of decentralized identity.
Right now it’s disparate, a lot of interest, but people want to pick one of these systems, not hitch wagon to something that won’t work with anything else in the future.
Full disclosure I work at Microsoft.
The ecosystem building is the goal with DIF.
If you’re a contributor, just sign an agreement saying code will be Apache 2, W3C agreement, Creative Commons.
We’ve added 20 new members. Microsoft helped envision this but we have other competitors, such as an blockchain. IBM. Also Hyperledger. Not like we don’t talk to each other, but there is competition in the market. Both have now joined DIF. A signal to the market that we may be competing, but we are agreeing there should be a shared vision for this thing. Inherently, no one owns decentralized identity. For this segment of blockchain-based ID systems, we have to align.
Identified 4 key deliverables.
- Decentralized identifiers
- Universal resolver, a DID might be rooted in one system or another is still resolvable.
- Universal registrar, a separate server. Modules to create DIDs on various systems.
- Identity hubs. DID-based personal data stores. Not a blockchain type system.
Marcus … landed an actual implementation of the Universal Resolver. Something you can use today to resolve DIDs today. Truly one thing as an oracle to find DID information.
Roadmap
What do we want to target in next six months. To show the market they can trust the tech.
By 1/1/18, land core properties and features of the DID spec. A few contentious bits.
3/1/18, universal resolver in two major languages; 1 already is Java. with client libraries for all mobile environments. And support for 3+ DIOD drivers.
4/15/18: Identity hubs, reference implementation
Show it 5/14/18 at Consensus main stage in New York. Presentation and demo showing the interoperable layers working together.
We want at least 3 DID methods being used between two entities and a user, to issue/verify attestations that drive a real world use case.
We want you to submit 1 page with desire for inclusion in this demo. And what resources you are willing to allocate.
Want to participate? Commit key dev resources. Help produce the demo and manage execution on the demo.
Q: DIF have an opinion on user experience?
A: We’re trying not to do that. We’re not trying to build a product. Making sure underlying fundamental bits are there, table stakes. A reference implementation.
Q: This is all new stuff. If there’s no exemplar usage scenarios, how do you know functionally it is what the market needs?
A: We’ve worked on use case scenarios. Some data we keep; lots we’re willing to share. I.e. one type of claim may be something a bank has a big need for. At the same time, we’re also building low level enough stuff, we’re not excluding new use cases.
Q: Part of Indy?
A: DIF is its own thing under the Joint Developer Foundation. We are technically a nonprofit LLC under JDF.
Q: What kinds of identity are you thinking of? IoT devices? AIs? No assumptions whatsoever?
A: More than half skew toward human identity. We would help they support devices and objects.
Q: What are you resolving to?
A: Go to the Universal Registrar server package. Creates decentralized identifiers. Each driver corresponds to a method that corresponds to a chain. It has its own way of inspecting the chain and coming up with the answers; here are the keys. You can challenge them. We want to encourage lots of systems, Etherium 745, standardish way on Etherium to do DID, if that gets accepted. Finding data off-chain. Drivers. I.e. replace ICANN or other centralized naming systems. The resolver is what you would run. DID document, control document has service pointers in it. It’s a way you can find IDs, challenge them using keys that are there, find where data resides.
Q: SOBs?
A: We look at the community, says I’m SOB. Who has the most adoption. We will sign a bundle that SOB is this driver. It’s market adoption, not an international standard.
Q: What is wrong with the ICANN approach?
A: If they don’t like your blog, you’re gone. To have your identity turned off, we’re talking about claims that could get you into hospitals. I think it’s a human right.
Q: Denial of service concerns.
A: There’s a way to do qualitative assessments based on attestations. You can run trust scoring. If it’s all empty shell identities. To discern who’s real and who’s not.
Q: A list of not just use cases but also abuse cases. A detailed threat analysis.
A: That’s something we want to do. Verifying the methods.
Q: Right now we have the concept of levels of assurance and auditors. Seems to me like different methods are going to possibly need different levels of assurance or auditability practices. What’s the scope of DIF relative to this ability to meet the requirements of regulatory agencies?
A: DIF doesn’t want to be involved in that analysis. We might encourage constraints. Such as proof of stake. We are not going to say we’re only going to accept this or that. We might keep a log of good feedback to play into your DID acceptable scenarios.
Q: Dive in more on the identity hub. Related, is it assumed all identity hubs are in a public access as opposed to private? The name resolvers resolve to public things?
A: I’ll show you an actual diagram of how they map together. May have multiple hubs for redundancy’s sake.
Q: Are claims part of the identity hubs?
A: They’re not super smart. They’re untrusted. The likelihood is they can’t issue claims, sign keys. If a government wanted to attest that someone was 25 years old, that DID, they would sign an attestation with their DID, now you have an object, go to the resolver, get both DIDs and the keys related to them and check the objects to see the signatures are tied the way they claim to be.
Q: Can the identity hubs run code?
A: I don’t think scaled implementations would run it; it’s a large attack surface. Go to Spideroak, secure storage, boutique hub providers.
Q: This could end up being a complicated mess for users.
A: What proof points are you looking for?
Q: What will the reference implementation be able to do?
A: Some storage, facilitate some messaging. You might want to present someone a document. Sign with your DID. How? You need an endpoint where you look it up.
Q: Scalable to billions of identities? Hubs, local stores?
A: No different than Dropbox on your phone or OneDrive on your phone. Microsoft may have much replicated.
Q: Why not use Dropbox?
A: It’s more about the API and the permissioning flow, having the hub resolve and check the ID request. Acclimating piece of storage.
Q: Dropbox, I can provision a piece of data.
A: Dropbox owns your data.
Adrian Gropper: Public blockchains, private UMA.
A: Many economic reasons why large companies would give away free account, like they give away free storage or email. High traffic users would have to pay. You’re still syncing to your own devices. I will have all my claims on phone. I might want large volume going to the cloud. It’s for availability and scale.
Q: What is the value add of your switching, the first two boxes. If I have co-equal providers (i.e. email) different APIs, you’ve provided a way to smooth over that.
A: Yes we need to speak the same data language. Find me everyone in the world who wants to offer me a red car to buy. I need to be able to ask the same question. The hub says lets not create new APIs. Let’s make the API not 1 to 1. Say you’re Craigslist. We could recreate Craigslist.
Q: Craigslist doesn’t need all that stuff.
A: I think the world will find it’s very challenging for them in the next 10 years. It’s a crawler.
Q: All the different personal data store providers, there could still be leakage of identity across platforms. We want storage to retain anonymity. We’re building this on top of an imperfect backplane.
A: Why we’re not creating a new API. The data is the schema. It’s deterministic. We’re saying reuse the APIs the world is already giving us.
Q: Email hacking scenarios. If they hack your email they own you. This creates appropriate segregation. An inflection point, figure out what is critical mass.
NOON SESSION CONVENED BY DRUMMOND REED
We define specific DID method: Defines structure & method of generation for the method-specific identifier. Globally unique among other method names.
DID method specs … IPIB not IPDB
Not all of those are blockchains.
Globally centralized key value store.
Each DID method will define its own access control.
Agents - do key management to establish trust, verifiable claims exchange
A method of implementing GDPR
Revocation is method specific.
This is a JSON alternative to Web ID (& SoLiD?)
GDPR authorities considering this workable.
Working with OASIS on key management protocols.
Q: How do you avoid name collisions in methods?
A (Buchner): Attestation, DIF believes you should link these two.
Drummond: A method that doesn’t have a community behind it won’t be viable. You’re starting the Web of trust with communities.
Q: We don’t have an example at scale yet.
Q: I have an example. Well-known ports.
Q: The registry came first.
A: We’ve developed a template for ID methods.
Q: Letters vs. numbers.
A: The goal is to provide a list of well-known services. And ways to create cryptographic proof.
