Decentralized DID’s

From IIW

Decentralized DIDs


Tuesday 1M


Convener: Joe Andreu

Notes-taker(s): Heather Vescent, Nathan Martin & Kurt Milne


Tags for the session - technology discussed/ideas considered:



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


1. Notes from Heather Vescent:

DID Background

Explain what a DID method is.
-DID
-Method
-String


Informal registry on CCG list: 22 methods registered
Lightweight requirements to list your method
- 3 for bitcoin
- 5 for Ethereum
- Various systems


History

Markus Sabadello + Oliver (uport) brought up issue
Oliver+Dmitri proposed DID:web(method):(methodspecificidentifier)
Dan Burnett: To be an easy on-ramp for people who were scared by the notion of distributed ledgers
Idea of bridging current technology and new technology
How can we connect existing technology/systems to new technology?
Fear of co-opting the technology by a large organization. (E.g. Facebook)


Questions

- What’s wrong with the URL method/path?
- Supposing I want a centralized ID?
- Can you have Sovrin method in a vertical/federated (e.g. financial industry/mobile network operator) – it is decentralized but also centralized. Could they implement Sovrin in those configurations? Would you consider that to be more centralized or decentralized?


Logistics (how Joe is running this meeting)

Will list decentralized points vs antipatterns.

Characteristics of decentralized and !decentralized.


Decentralized !Decentralized (antipatterns)
Any root of trust

Provably under

  • Controller of DID
  • Controller

Anti-censorship (censorship resistant)

Single root of trust

Required use


Notes

  • Chris A: Architectural, political, social categories of categorizing decentralization
  • Joe A: Avoiding political, focusing on the functional aspect of identity. What is the criterial for a good DID method? This isn’t about controlling what people might do. We are creating a working group to create the standard/debate that define what DIDs are.
  • Drummond: A DID is a URI. The 4 things brought up on the list
    • 1 Persistent: signed once & available forever
    • 2 Resolvable (to the DID document)
    • 3 Cryptographically verifiable
    • 4 Not under control of centralized authority
      • What is the definition of a single authority? Is a government? Nato?
      • A university? It really means, you want a good guy?
    • 3 is more important than 4.
    • This is cryptographic control (Drummond holds us phone). Look at it from the keys back, that is what we’ve designed. The DID is an identifier, for a public key that goes with a private key I control. Not always an individual, can be for a corporation. What system do you trust for the corresponding private key?
  • Q: how do you classify an identity that is assigned by a government, or university – centralized?
    • They are centralized.
  • Not talking about distributed identifier. The methods are each a root of trust (in their domain).
  • The platform level – can choose any root of trust.
  • DIDs and DID Documents should
  • DIDs feed into VCs
    • Should be able to move to DID Sovrin and DID Veres1
    • It’s gonna be a nascar sticker problem for OpenID all over again.
  • MS: Trying to get to clicks – who do you trust to get these.
    • Less Nascar, stickers, vs accept all these things
    • Move to claims vs identifiers.
  • Separate the identifiers from the credentials.
  • Drummond: 2 levels of roots of trust
    • Lower: DID level, root of trust is the decentralized network the DID method uses.
      • Issuer of the credential. University, register a DID on a certain method. Have that DID and use Private key to sign documents.
    • Other level: Verifier: the verifier has to decide 2 things – trust the university & secondary, trust the public key (the method).
      • If you don’t trust the method, you can’t trust anything from/using that method.
  • Question: Why not URLs (format)?
    • It is a URL…
    • But you said URI
    • It’s really more like a URN
  • I don’t see what is decentralized about DIDs at all. the claims might be decentralized.
  • In the way that HTTP is centralized, so is this.
  • This is a scheme for capture by a big player. Each method is an authority. We have watched repeatedly this get captured by an authority.
    • Is there something we can do to minimize/reduce this? Political, social, cultural?
    • Drive the preferential attachment to a big player
    • What would drive the preferential attachment to a big player?
    • What would make it popular?
  • The question of DIDs are centralized
    • The answer is yes, all of the above.
    • The standard can say many different subpockets of control
    • Centralized issuance control vs operation/usage of it. Dependent on peers. It seems like it’s a federation vs…
  • Governance (rules) vs operations
    • But it comes down to policy
  • There’s no one to sue for bitcoin?


  • Have you thought about the vacuum you create?
    • Where do you draw the line between anarchy and centralization?
    • FB is the largest IDP in the world, but they don’t follow
    • They aren’t good guys, they are vested interested in making this work
    • The standards are great, but how do we stop a crackpot.
  • One of the killer apps – offshoring username/pws
  • One of these did methods should be able to fail/be compromised/corruption, the system continues.
    • Andrew – this is the killer feature
    • What have we designed into a system, a user to location and reassign DIDs from a broken/failed/compromised system.
    • Dave: a mathematical truth, operational falsehood. Popular method, has access to docu…
      • This is a recovery feature
    • How are we building into the architecture for this?
      • Joe: this is a different layer
  • Identifier can’t be stolen, but it can be maliciously taken from you. But if you lose your keys, no one can give you new keys or reset.
  • Markus: what’s to prevent did:facebook
  • It has to do with community and building a tribe/individuals that know you. It’s about social recovery.


                                                        • ********************************** ************************* ****************


2. Notes from Nathan Martin:


*Glossary*:

DID: Decentralized Identifiers (https://w3c-ccg.github.io/did-spec/)

KYC: Know Your Customer

AML: Anti-Money Laundering

IPFS: Inter-planetary file system

## Intro

How many people know what DIDs are? 

*Half of room raises hand*

We live in a world where we can now reliably transfer $100M without KYC + AML, a requirement traditionally held by banks. These IDs are not tied to a “traditional ID”, e.g. driver’s license. 

DIDs record an identifier, and a means to control that identifier. There is no single root of trust. For instance, the blockchain-based IPFS with no centralized control or point of failure. Compare that with the https protocol, which ultimately resolve to a root of trust. 


## Problem Statement

What does the /decentralized/ in Decentralized ID mean? Is Bitcoin decentralized? Sovereign DID method is on a permission blockchain…is that decentralized?

What is decentralized? What do we want it to mean? Decentralization implies a requirement. 

The challenge we’re facing is that some argue…you start with a DID, you get a DID document…that’s not decentralized at all! This could all become DID Facebook, Twitter…with no real difference from today. How can we have a good set of criteria? What is a good DID method?

Specifically, we’re working to develop a specification that’s evolving, and we’re trying to make a community final version, to become an official standard. We didn’t expect to get to the point of a working group, but the W3C said it was important enough that we do it now. So we’re finishing a charter, and will be going in to vote. We need to come up with a common language for…what is decentralized? This is not about control, it’s that we’re trying to create a standard. A good set of written English statements.

## Discussion

DID is a URI. URI has been established for nearly 20 years. How to classify whether under control of a central authority? 

Want to be able to easily move from DID provider A to provider B, similar to how today we might login with our Github, Facebook.

The standard seems to be moving towards claims instead of an identifier, trying to work with claims.

It’s important to distinguish between claims vs credentials. There is a paper about verifiable claims, originally in early verifiable claims — Oasis group our research on how might replace XDI https://w3c.github.io/webpayments-ig/VCTF/charter/VCTF-final-report.html (unconfirmed report link by Verifiable Claims Task Force) . 

When looking at a proof of a credential, e.g. student getting a discount at a university, there are two questions regarding trust:

1) Do I trust the university?

2) Do I trust the (DID) method?

Who determines trust? That yes, that DID belongs to the university?

DID can be politically centralized, it’s just a protocol.

Useful to distinguish between various terms when referring to something being decentralized or not. Vitalik Buterin considers the following properties:

  • architectural
  • political
  • logical (structural)

There is nothing that can meet all the rubrics! There is no perfect decentralization. When you have a single standard, you have a logical centralization, e.g. Bitcoin. 

DID format does limit design space, but these are features.

Is http centralized? If accessible via the public web, it is centralized (under the root servers of DNS) because there is a single root of trust. The scheme isn’t centralized, but each method is under an authority. An authority oversees creation of domain names, root servers can do whatever they want, but they happen to do the nice thing. 

DIDs are centralized and they are not. You may have one taken by Microsoft, and one by Sovrin. Bridges the gap between centralized and not—a confederation of centralized environments. Issuing and complying with the protocol, the protocol is centralized, they manage but in compliance with overall standards. Yet it is not centralized, that is taxonomy. Let’s not confuse following structure. Language is necessary for a level playing field. 

Factors to consider about a name are registering, representing, using and assessing (trust for ownership). Right now, with the exception of P2P (as decentralized as it gets), all fall under decentralized network. There is no centralized registry. Are you inviting collisions? What enforces INFS servers? Convention.

What’s the syntax: did:method_name:method-specific ID

E.g. `did:ex:abcd….`

Right now there are lightweight requirements to get into the registry, you let us know and make sure you’ve published it and followed all the rules. The current registry has roughly 22 entries: 3 are Bitcoin-related, 5 are Ethereum-related, and the rest seem to be application-specific. New ones are being proposed, e.g. `did:web:...` to make it easy for those scared of distributed ledgers. We’re looking to make this bridge current + future technology, and address fears of the technology being co-opted. 

What is the definition of a single authority? Really means, I want a “good guy”. Distinction between governance, ultimately relies on institutions and others agreeing upon rules. Comes down to policy more than the rules. 

Facebook DID can change at any time, versus Sovrin ensure operationally decentralized. With Bitcoin governance is chaotic (politicized). Is it technology or policy that makes it centralized? 

Where to draw the line between centralization and anarchy? There is a vacuum. Facebook has a vested interest in getting it to work. Where is the practical application? 

Killer apps:

  • off-shoring password management
  • government grant gatekeeper
  • Getting a government grant requires going through some private company…it’s like that company is baked in the government process. 


What about resilience? If one fails, we want the whole system to be OK. If a method fails…it results in operational failure. In reality, you would lose all access to your documents. If a big system fails, you lose your documents. How to build into the architecture a way to stay operational? Let’s clarify something here, think about the IP datagram. This discussion is not about reliability. This is regarding W3C, a syntax specification. 

What if this committee fails due to being overly politicized? Can it be forked?

What is the relationship between cryptographic verifiability and “not under the control of a single authority”? Cryptographic verifiability trumps the other. All devices and sites store your private keys. What if I lose it? The point is…DIDs outward vs keys inward; a private key that I control. Ok then, what system do you trust for the address of that public key?

What if I lose my key?

Reputation management should exist. Community building tribe, in a group of 8 people, perhaps 4 needed for recovery of a lost key. 

What’s to prevent `did:facebook:   ` where the method-specific ID is empty? Killer feature: the system should be resilient. What have we designed such that a user can generate another method at their own DID. 

That DIDs are not under the control of a single authority seems to be an important point of failure. If that fails, all others fail quickly. 

One of the DID requirements, that of persistence, is not feasible nor wanted! Tattoo it [DID] on my ass? It is morally abhorrent. And it can’t be implemented. 

                                      • ******************* ****************** *****************

3. Notes from Kurt Milne:


Summary


Problem:
- What is decentralized mean in terms of decentralized identifiers?
- As DID implementer, what is a good set of criteria - what is or is not? Not about controlling outcome.


Intention:
- Bridge current and future technologies
- Fear of being co opted


Summary list generated by end of meeting:


Decentralized:
- Use Any root of trust
- Probably under control of DID controller (user?)
- Anti censorship - no one to subpoena 
- Resilience - to individual method catastrophic failure
- Portability
- Able to be forked


!Decentralized
- Single root of trust
- Required use
- Administrative layer - (please reset my key)


Notes in order of discussion


Drummond:  DID spec editor. Verifiable claims task force. Creating guidance for working group. Working towards community final version.


Discussed methods:


Start with DID, get document with keys etc.


IPFS methods


DID methods – 
- Sovereign DID method - decentralized?  
- ? Others


did:method_name:method_specific_identifier


Registry group - 20 current methods registered: 3 bitcoin, 5 Etherium
Methods for bitcoin: Create, update, deactivate etc.


Q: What about URL method?  with method:path


Paper - who wrote initial paper ? 
Term - originally in doc Manu early verifiable claim - 
Oasis group presented at IIW - replace decentralized xDI 
Rebooting web of trust


Meeting notes - add document links or reference to links


Sovereign method in vertical - federated financial industry multi-network operators


Self sovereign - 


Side bar - Aspects/categories of decentralization -  Source Vitalic Buterin (sp?)
- Architectural
- Political
- Logical


Drumond presented original spec - least to most controversial
DID - is a URI - standard has been around 20 years
Standard identifier on the web


1 - Persistent - sign 1 and forever URN 
2 - Unlike URN - all DIDs are resolvable 
- submit and get back DID document


3 - Cryptographically verifiable
- DID identified DID subject
- Whoever controls the DID - can prove the controller


4 - Not under control of centralized authority


Nothing against identified controlled by central authority


Methods are each a root of trust - within a domain - 


DIDs and DID documents - should have credentials tied to decentralized identifier.


NASCAR problem - lots of logos


Industry moving towards claims versus identifiers


Use DMV to issue drivers license, would like them to use DIDs


2 levels Roots of trust


Example: Student goes to bookstore, wants student discount. Verifier (book seller) decides 2 things  

1 - Do they trust issuer (University issues student ID)
2 - Do they trust method used (ID real or fake)


DID root of trust is centralized method used

- Register ID under some method, register, have DID, will have issuer credentials.


DID phishing?


Q: Back to question Why not URL?  

A: Discussion


Bitcoin is rigid centrally.  DID format limits design space.


Registry is not exhaustive or definitive


Scheme is decentralized to an authority

That approach gets captured historically


Real decentralization - no opportunity for that


Q: Does kill switch or other governance - reduce attractiveness?

A: Marketplace is highly decentralized - but prone to capture


Each method owned by entity - if it becomes popular 


Opportunities of control

- Create/register the name
- Represent the name
- Using the name
- Reputation/trust of the name


Example decentralized name creation - odds of naming collision diminishingly small. This is not that.


Publicly available identifier - cryptographically verifiable


22 example methods registered.


Decentralized identifiers - not rely on single root of trust - for use with decentralized networks


If not centralized registry - invite name collision

What enforces use of INF(?) convention


Creation of domain names - 


Q: re ask - Why not URL? More like URN?


Centralized issuance controls

Use of DIDs - between peers


If use environment

Confederation of centrally controlled 


Issuance, protocol definition - centralized

Use  of protocol in various environments (MS Google etc) - decentralized 


Diffusing of centralization

- To enable decentralized nature - must agree on protocols
- Centralized - language needed to operate
- Decentralized - DID method, who can, who can’t


Q: what does it mean to have a central authority.


Distinction - Governance (relies on humans) and operationally decentralized.  

Comes down to policy more than rules.


Q: where does idealistic vision define practical application?

- People build and sovereign state caring about it e.g. offshoring password management


Phone - cryptographic control

What if loose it - what happens if loose phone

Design from user key back.  Not DID out.


Q: what system do you trust - public key assigned?


Resilliance - Killer feature - if DID fails - system stays functional

Individual - relocate and regenerate DID on another method

If move off bad actor - still work


Q:  What happens if catastrophic failure?


Operationally failure - popular Documents

Killer feature - 

Moving a document is equivalent of regenerating

Recovery feature


Social recovery  - Multiple people vouch for DID 

Community - build tribe people that know you


IP datagram - not describe how to maintain 

Retrieved from "https://iiw.idcommons.net/index.php?title=Decentralized_DID’s&oldid=22140"