10A/ Don't use DIDs, DIDs, nor DIDs: Change My Mind (a.k.a. Oh no he DIDn't)

From IIW

Don’t Use DIDs, DIDs, nor DIDs: Change My Mind (a.k.a. Oh No He DIDn’t!)

Wednesday 10A

Convener: Dave Huseby

Notes-taker(s):  Dave Huseby

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

This session was to talk about the topics I put in a recent article that created a huge fire in our community where I lay out the case for completely abandoning the W3C DID standards.

https://dwhuseby.medium.com/dont-use-dids-58759823378c

Joe came and fervently disagreed with my assertions. Lots of people had reasonable counter arguments. My main arguments are 1. DID Documents don't have history when old keys are always relevant and 2. having 94 different DID methods that aren't compatible nor replaceable and don't function the same way is a HUGE problem.

There was no conclusion other than Sam Smith and I came to the conclusion that we have more in common than we thought.

Terasing out the details of DIDs

ZOOM CHAT:

Rouven Heck115:14 Oh no, no fighting here today? ;)

Steve McCown18:27 There have been demonstrations of re-writing GitHub history, so it’s not entirely immutable.

Oliver Terbu21:21 DID Docs are time oriented now; DID Docs have old keys available; -> versionId query param; -> nextVersion, nextUpdate etc

Markus Sabadello22:13 +1

Rouven Heck122:17 DID methods - usually with a blockchain for timing :)

Balazs Nemethi24:58 “College Students Make First-Ever Successful Flight And Landing Of A Concrete Airplane”https://www.popsci.com/technology/article/2013-05/these-college-students-flew-tiny-airplane-made-concrete-because-why-not/

Windley25:08 Haha

Steve McCown25:18 @Balazas, I was just posting that! :-)

John Court25:22 How many others were searching for that I wonder

Markus Sabadello25:47 You can "transfer" a DID by updating the controller's key.

Tobias Looker26:04 Yeah +1 ^

Brent Zundel26:06

yeah, I'm not following

Joe Andrieu26:48

Actually you could add whatever you want to the DID Documet

Tobias Looker26:49

So you think the data model should expose a commitment scheme?

Joe Andrieu27:06

So, please add the property to the DID Spec Registries and you're done

Markus Sabadello27:38

ya this could be added as an extension property.

Michael Lodder27:50

but then its only specific to that method

Oliver Terbu28:46

i think you just pick the did methods that address your requirements

Michael Lodder31:27

but then how do you move if you want

Darrell O'Donnell31:33

93 DID Methods - will resolve down to a power law distribution. No different than API proliferation - but better.

Tobias Looker31:59

The DID spec is really bug light for innovation

Paul Bastian32:00

a few DID methods will survive after few years

Tobias Looker32:00

IMO

Darrell O'Donnell32:08

Agreed Joe - DIDs are early - we’re in a Premature Standardization phase

Markus Sabadello32:16

I don't think it's accurate to call DID methods "silos". This is an oversimplification and one of the reasons why the DID Rubric was created

Darrell O'Donnell32:18

We’re learning,

Paul Bastian32:18

http, ftp were not the only protocols, but the ones that survived

Joe Andrieu32:31

+1 to Brent's notion that this is "what email looks like"

Darrell O'Donnell32:42

“gonna take my marbles and go home”?

Kerri Lemoie33:53

Right now it seems very hard for individuals to choose which DID they’d like to use. Vendors make that decision for them.

Paul Bastian35:41

Email uses like 3 dozen RFCs under the hood and still its pretty interoperable

Andreas Freitag35:50

@DB Thats the reason why you are “locked” in when you decide for a DB…

Dave Huseby36:05

But those RFCs cover each aspect, not multiple RFCs for the same thing

Andreas Freitag36:08

And only can migrate with a certain pain :)

Darrell O'Donnell36:27

@Kerri - agreed, to me the companies that are using DIDs well, are isolating the DID churn from the user.

Kerri Lemoie38:52

+1 @Darrell

Joe Andrieu39:40

+1 to layer innovation.

Darrell O'Donnell39:52

We are in EARLY days - the churn here is high and will continue to be high. Throwing a standard into play that folks think is more advanced (i.e. mature) than it really is.

Joe Andrieu39:56

that's right.

PhilWolff40:04

control as an emergent property of the architecture?

Darrell O'Donnell40:21

@Sam - 100% - “hey DID:method, do you KERI or am I on my own here?”

Dave Huseby40:55

@Darrel “hey KERI can I have my data back?”

Dave Huseby40:58

)

Darrell O'Donnell41:33

@Dave - yeah, and “Hey DID:method - where else do you anchor KERI”

Darrell O'Donnell41:44

wait - someone is making $$$ here?

Rouven Heck142:01

haha - yeah, for sure not with DID methods :)

RickC42:02

that was going to be my question;)

David Waite42:02

Mostly on side bets, sure

Lynn Bendixsen42:29

Maybe his money comment was "tongue-in-cheek"?

Joe Andrieu42:36

LOL. http is also a silo

Kerri Lemoie42:47

In education credentials, there’s common thought to use methods that aren’t blockchain (vendor) related.

Darrell O'Donnell42:55

“I do wonder whether at this point, Bitcoin should also be thought [of] in part as a Chinese financial weapon against the U.S.,” - Peter Thiel

Joe Andrieu43:17

That's right. Blockchain fixes this.

SamSmith43:20

Hourglass theorem stack of thin layers wins over stack of thick layers

Joe Andrieu43:20

  • snort*

Rouven Heck144:01

Sam - agreed. The question is - what is the thinnest part of the hourglass?

Steve McCown44:15

Why is it not possible to “take your data and go home”? If it’s a problem, then why not create a way…

Darrell O'Donnell44:17

@Sam - +100 - we’re discovering the natural thin layer delineation, but we aren’t done that learning. Your KERI work is a seminal piece that helps.

PhilWolff44:25

So, what are the alternatives? A fork of DIDs/VCs? Or something new?

SamSmith44:31

Control security should be lower thin layer than namespace layer.

Darrell O'Donnell45:53

@Sam - lower layer for sure. We may need a GetCapabilities() at the namespace layer that allows me to know what that DID:method does -from most basic, to advanced.

Tobias Looker45:57

Well its a standard to construct namespaces

Tobias Looker46:06

URN that is

Tobias Looker46:07

Syntax

PhilWolff47:41

Identity of Things requires offline operation.

Joe Andrieu48:23

Your term "identity" is under defined, Dave

Joe Andrieu50:58

As anyone can do, to assert that same ownership, of that same image

Joe Andrieu51:09

NFTs != DRM

Tobias Looker52:40

How do you communicate which places you have anchored too?

Tobias Looker52:49

And which anchors you are keeping up to date?

Rouven Heck153:20

yeah, why cross ledger?

Tobias Looker53:26

Yeah +1 Sam

Rouven Heck154:02

NFTs require double spend protection -> so it cannot live at 2 ledgers at the same time.

Dave Huseby55:38

Sam’s assertion is wrong

Dave Huseby55:46

Because the provenance log commits to registrars

Joe Andrieu55:55

@rouven There are some ways to achieve some semblance of cross-chain NFT operation, but generally its lock at source chain, play on second chain, and return to first by releasing second. With that pattern, you can get "on-chain" activity on different chains, although I agree that it isn't really active on both chains at the same time.

Rouven Heck156:08

Duplicity detection -> detection that the NFT has an unclear owner now? How would solve the conflict?

Dave Huseby56:24

So even if a stale key is compromised they don’t automatically compromise even older keys

Dave Huseby56:44

Also KERI doesn’t have a way of committing to the requirements for validity of the next event

Dave Huseby56:59

Which prevents stale key compromise from creating a fork

Rouven Heck157:08

@joe - yes, bridges to switch between ledgers. So it’s usually locked on all ledgers, beside one

Joe Andrieu58:08

@rouven yep. eventually we'll get cross-chain state changes, but that requires shared semantics, which is, IMO, a bespoke research project for some future utopia

Brent Zundel58:35

now that this has turned into ADS vs KERI, I'm going to check out

Riley Hughes59:00

Dumb question, are we still talking about why we shouldn’t use DIDs?

Balazs Nemethi59:07

nope

Joe Andrieu59:07

LOL

camparra59:11

Is this the KERI session?

Joe Andrieu59:45

Sort of. This is about some missing features that DID-based applications really wish were solved, but DIDs don't solve on their own

Steve Todd59:48

I'd enjoy a KERI vs ADS slug fest, but I want the DID one first. :)

Michael Lodder01:00:17

I'm happy to have the KERI arg in the KERI session

Michael Lodder01:00:23

I'm interested in DIDs for this one

PhilWolff01:01:01

My biggest takeaway is that the standards processes that lead to the current state of VCs, DIDs, etc. did not hear from Dave (and his concerns) and others that had Dave's concerns. This discussion would have been better a few years' ago so the functional concerns could have been fed into the design stream.

Riley Hughes01:01:13

Markus asked my question

Tobias Looker01:01:14

Exactly my point markus

Riley Hughes01:01:25

Sounds like Dave has created option #94

Tobias Looker01:01:26

Haha and Riley!

Jace Hensley01:01:45

^^

Tobias Looker01:01:53

Yeah I’m going to spawn another IETF called ADS-2

Michael Lodder01:01:54

I'm failing to see how this is option #94

Tobias Looker01:02:12

Which uses a diff serialisation tech than BARE and other crypto instead of BLS

SamSmith01:02:15

@philWolff I have been arguing the layering change for years in the w3c discussions but one year too late

Tobias Looker01:02:27

Ala another standard and silo

camparra01:02:51

I would like Dave to be able to tell us his solution without being interrupted and being stopped every other word to define it

Rouven Heck101:02:54

@Sam - how do you solve duplicity events?

Tobias Looker01:02:54

  • another IETF draft

Rouven Heck101:03:01

(once detected)

Michael Lodder01:03:05

My main takeaway is that the current standard is too silo'd and needs to change

Joe Andrieu01:03:29

that's not entire true. servers often favor IMAP over POP or vice versa

Jace Hensley01:03:39

But isn’t that just because everyone adopted the same standard?

Tobias Looker01:03:46

+1 ^

Joe Andrieu01:03:50

@Jace that's right

Steve Todd01:03:50

Why should I build applications on DID if I still have to adapt to every method? What is the standard buying me?

Michael Lodder01:04:15

Exactly @SteveTodd

Kerri Lemoie01:04:17

It’s important keep in mind that email addresses are not always used by one individual.

Michael Jones01:04:18

E-mail uses domain names that are issued through a centralized, hierarchical system

Jace Hensley01:04:19

I do feel that pain point Steve ^^

Joe Andrieu01:04:24

@steve it's standardizing how ANY method represents verification methods & relationships and service endpoitns

Darrell O'Donnell01:04:32

@SteveTodd - you won’t, some will fall into the “not touching that with a 10 foot pole” for whatever reasons (lack of features, problematic governance, etc.)

camparra01:04:43

Steve has a point

Joe Andrieu01:04:50

it is NOT about standardizing how the information represented in a DID Document is managed in any kind of storage system or network

Rouven Heck101:05:09

At least the interface is same/similar - but agreed, you don’t want to trust 94 methods, read from 94 sources/blockchains

SamSmith01:05:34

@rouven Immutable append only first seen policy of any watcher means that the first seen version is the only seen version for that watcher. Distributed consensus amount the set of watchers that any validator trusts provides the authoritative provenance log for that validator.

Joe Andrieu01:05:42

Really, what we've standardized is like the context of a DNS record, while allowing how you read & update those records to be defined at another layer

Andreas Freitag01:05:43

Maybe an idea for an TimeBlockchain, which timestamps all others

Darrell O'Donnell01:05:48

@Rouven +1 - good enough to start exploring and learning - to see where we need to go.

Tobias Looker01:05:52

I don’t understand how you can migrate registrars without the duplicity problem sam spoke of

Darrell O'Donnell01:06:16

@Joe - exactly - look at the loose use of DNS TXT, SPF, MX, etc. records

Steve McCown01:06:29

Another question is how will users / services know whether they should trust a particular DID method? Interoperability is important, but trust (given divergent implementations) is also a problem in need of solving.

Darrell O'Donnell01:06:34

DNS is a place to put your tailored thingamajigger

Darrell O'Donnell01:06:47

@Steve McCown - governance

Darrell O'Donnell01:07:12

“We support X, Y, Z for our health records in our jurisdiction” - you can petition to add more.

Joe Andrieu01:07:30

FWIW, I think Dave's bringing interesting challenges to the DID architecture, just like KERI brought forth interesting challenges to the blockchain-based assumptions behind much DID thinking.

Darrell O'Donnell01:07:56

@Joe - agreed. There are nuggets of goodness here.

Rouven Heck101:08:02

@Sam - so Consensus across watchers. Isn’t that like a blockchain?

Joe Andrieu01:08:22

And like Keri, I expect the best way to leverage the ADS work is to integrate parts into new or existing DID methods.

Wayne Chang 01:08:34

team `did:adi`!

Tobias Looker01:08:41

haha

Rouven Heck101:08:57

@Tobias - I think with an ‘exit’ event on chain / registar, you could move to a new chain

SamSmith01:09:01

@Tobias The incepting event commits to the first registrar if its a different registrar then the identifier because its derived from the contents of the incepting event would be different so even compromising keys doesn't allow one to use a different initial restitrar so the root of trust is inviolable. So one can then hop to hop from that unique root.

Darrell O'Donnell01:09:51

@SamSmith - like the post office will be forwarding my mail when I move until everyone figures out my new address - except its better.

Tobias Looker01:10:12

Yes so the initial state of the identifier has to nominate that registrar right?

Darrell O'Donnell01:10:15

@Rouven “he’s not here now - he’s over _____”

Rouven Heck101:10:26

@Darrel - yes

Rouven Heck101:10:42

like I can forward emails, or DNS :)

Joe Andrieu01:12:35

Wayne, I missed that handoff.

Riley Hughes01:15:04

https://xkcd.com/927/

SamSmith01:15:45

@Rouven yes its a form of distributed consensus but its a much simpler form. It only guarantees safety but not liveness or global total ordering. The stellar protocol uses something similar. Each user gets to pick which subset of stellar nodes its trusts. This allows an open network of validator nodes for Stellar. But a stellar use can select validator nodes in such a way that they do not get liveness. In fact Stellar has a different safety margin from its liveness margin. This has resulted in Stellar having two episodes where liveness stopped. I.e. the ledger stopped coming to consensus for a couple of hours. The ledger was safe, no erroneous transactions were entered but no new ones were either. Once the problem was fixed (in one case is was poor node selection in the other it was a code bug) then consensus resumed on the next proposed transaction. The nodes were not dead but could not come to consensus because the faults exceeded the liveness margin but not the safety marging.

Berend Sliedrecht01:15:47

Great comic!

Tobias Looker01:16:23

Sidetree methods are pretty scalable

Riley Hughes01:16:32

If I’m just dumb, then I’d love someone to explain this to me. But I don’t see how this solves the portability problem - unless EVERYONE adopts the single approach (which is not realistic) - but that same thing could happen if everyone adopted a specific DID method.

Tobias Looker01:16:44

But it depends on what you mean by scalable?

Jace Hensley01:16:53

I agree riley

Drummond Reed01:17:07

DIDs are not a Web technology

Tobias Looker01:17:24

DIDs has an ADM though?

SamSmith01:17:26

Cryptographic accumulators are cool and provide some scalability advantages. But any DID method can use crypto accumulators. They are not necessarily tied to ADS. Certainly KERI can use them.

Markus Sabadello01:17:30

JSON LD isn't a requirement for DID methods

Drummond Reed01:17:37

DIDs do not require JSON-LD. It uses an abstract data model - at Dave’s strong suggestion ;-)

Lynn Bendixsen01:17:39

millions of issuers is a lot more realistic...not billions

SamSmith01:18:43

@tobias Yes. The incepting state crypto commits to the first registrar of the indentifer derived from the crypto commitment.

Darrell O'Donnell01:18:53

NETBEUI we miss you

Markus Sabadello01:19:43

I think there's a bright future for did:ads :)

Hunter Cain 01:19:55

haha

Darrell O'Donnell01:19:57

but @Markus - we’re allowing advertising?

Tobias Looker01:20:46

Agree sam wasn’t clear with ADS if that was the same situation

SamSmith01:21:53

So an NFT using that identifier is locked to the first registrar. A subsequent event that changes registrars will have to be first registered on the first registrar. It will be first. You still need duplicity detection for stale later attacks in the future but its trivialized due to the priority of the first seen policy.

Riley Hughes01:22:05

Dave how is this a user sovereign if a user can’t “take their data and go home” to another system that uses DIDs?

Drummond Reed01:22:14

And it has a patent pending component, yes?

Michael Lodder01:22:23

@Riley you're missing the point, you can with ADS

Michael Lodder01:22:46

No @drummond, he's recommending RSA accumulators, no patent there

Riley Hughes01:23:03

Any DID method can use RSA accumulators too though no?

Michael Lodder01:23:08

Correct

Michael Jones01:23:11

Thanks for the session, Dave, and for the discussions, Joe, Sam, etc.

Michael Jones01:23:13

Demo time now

SamSmith01:23:35

@Tobias currently AFAIK ADS is incomplete. It needs duplicity detection like KERI in order to solve the security issue I described. Should ADS add that then is will be essentially a variant of KERI.

Brent Shambaugh01:24:01

+1 did:key

Brent Shambaugh01:24:21

horrible security though :: grin ::

SamSmith01:24:28

Crypto accumulators operate at the VC layer not the keystate layer

Tobias Looker01:24:41

Yeah +1 this is a great conversation none the less

Tobias Looker01:24:55

Understand @Sam

Tobias Looker01:25:11

Thanks dave