10A/ Don't use DIDs, DIDs, nor DIDs: Change My Mind (a.k.a. Oh no he DIDn't)
Don’t Use DIDs, DIDs, nor DIDs: Change My Mind (a.k.a. Oh No He DIDn’t!)
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.
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
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/
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 ^
yeah, I'm not following
Actually you could add whatever you want to the DID Documet
So you think the data model should expose a commitment scheme?
So, please add the property to the DID Spec Registries and you're done
ya this could be added as an extension property.
but then its only specific to that method
i think you just pick the did methods that address your requirements
but then how do you move if you want
93 DID Methods - will resolve down to a power law distribution. No different than API proliferation - but better.
The DID spec is really bug light for innovation
a few DID methods will survive after few years
Agreed Joe - DIDs are early - we’re in a Premature Standardization phase
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
http, ftp were not the only protocols, but the ones that survived
+1 to Brent's notion that this is "what email looks like"
“gonna take my marbles and go home”?
Right now it seems very hard for individuals to choose which DID they’d like to use. Vendors make that decision for them.
Email uses like 3 dozen RFCs under the hood and still its pretty interoperable
@DB Thats the reason why you are “locked” in when you decide for a DB…
But those RFCs cover each aspect, not multiple RFCs for the same thing
And only can migrate with a certain pain :)
@Kerri - agreed, to me the companies that are using DIDs well, are isolating the DID churn from the user.
+1 to layer innovation.
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.
control as an emergent property of the architecture?
@Sam - 100% - “hey DID:method, do you KERI or am I on my own here?”
@Darrel “hey KERI can I have my data back?”
@Dave - yeah, and “Hey DID:method - where else do you anchor KERI”
wait - someone is making $$$ here?
haha - yeah, for sure not with DID methods :)
that was going to be my question;)
Mostly on side bets, sure
Maybe his money comment was "tongue-in-cheek"?
LOL. http is also a silo
In education credentials, there’s common thought to use methods that aren’t blockchain (vendor) related.
“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
That's right. Blockchain fixes this.
Hourglass theorem stack of thin layers wins over stack of thick layers
Sam - agreed. The question is - what is the thinnest part of the hourglass?
Why is it not possible to “take your data and go home”? If it’s a problem, then why not create a way…
@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.
So, what are the alternatives? A fork of DIDs/VCs? Or something new?
Control security should be lower thin layer than namespace layer.
@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.
Well its a standard to construct namespaces
URN that is
Identity of Things requires offline operation.
Your term "identity" is under defined, Dave
As anyone can do, to assert that same ownership, of that same image
NFTs != DRM
How do you communicate which places you have anchored too?
And which anchors you are keeping up to date?
yeah, why cross ledger?
Yeah +1 Sam
NFTs require double spend protection -> so it cannot live at 2 ledgers at the same time.
Sam’s assertion is wrong
Because the provenance log commits to registrars
@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.
Duplicity detection -> detection that the NFT has an unclear owner now? How would solve the conflict?
So even if a stale key is compromised they don’t automatically compromise even older keys
Also KERI doesn’t have a way of committing to the requirements for validity of the next event
Which prevents stale key compromise from creating a fork
@joe - yes, bridges to switch between ledgers. So it’s usually locked on all ledgers, beside one
@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
now that this has turned into ADS vs KERI, I'm going to check out
Dumb question, are we still talking about why we shouldn’t use DIDs?
Is this the KERI session?
Sort of. This is about some missing features that DID-based applications really wish were solved, but DIDs don't solve on their own
I'd enjoy a KERI vs ADS slug fest, but I want the DID one first. :)
I'm happy to have the KERI arg in the KERI session
I'm interested in DIDs for this one
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.
Markus asked my question
Exactly my point markus
Sounds like Dave has created option #94
Haha and Riley!
Yeah I’m going to spawn another IETF called ADS-2
I'm failing to see how this is option #94
Which uses a diff serialisation tech than BARE and other crypto instead of BLS
@philWolff I have been arguing the layering change for years in the w3c discussions but one year too late
Ala another standard and silo
I would like Dave to be able to tell us his solution without being interrupted and being stopped every other word to define it
@Sam - how do you solve duplicity events?
- another IETF draft
My main takeaway is that the current standard is too silo'd and needs to change
that's not entire true. servers often favor IMAP over POP or vice versa
But isn’t that just because everyone adopted the same standard?
@Jace that's right
Why should I build applications on DID if I still have to adapt to every method? What is the standard buying me?
It’s important keep in mind that email addresses are not always used by one individual.
E-mail uses domain names that are issued through a centralized, hierarchical system
I do feel that pain point Steve ^^
@steve it's standardizing how ANY method represents verification methods & relationships and service endpoitns
@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.)
Steve has a point
it is NOT about standardizing how the information represented in a DID Document is managed in any kind of storage system or network
At least the interface is same/similar - but agreed, you don’t want to trust 94 methods, read from 94 sources/blockchains
@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.
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
Maybe an idea for an TimeBlockchain, which timestamps all others
@Rouven +1 - good enough to start exploring and learning - to see where we need to go.
I don’t understand how you can migrate registrars without the duplicity problem sam spoke of
@Joe - exactly - look at the loose use of DNS TXT, SPF, MX, etc. records
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.
DNS is a place to put your tailored thingamajigger
@Steve McCown - governance
“We support X, Y, Z for our health records in our jurisdiction” - you can petition to add more.
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.
@Joe - agreed. There are nuggets of goodness here.
@Sam - so Consensus across watchers. Isn’t that like a blockchain?
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
@Tobias - I think with an ‘exit’ event on chain / registar, you could move to a new chain
@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.
@SamSmith - like the post office will be forwarding my mail when I move until everyone figures out my new address - except its better.
Yes so the initial state of the identifier has to nominate that registrar right?
@Rouven “he’s not here now - he’s over _____”
@Darrel - yes
like I can forward emails, or DNS :)
Wayne, I missed that handoff.
@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.
Sidetree methods are pretty scalable
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.
But it depends on what you mean by scalable?
I agree riley
DIDs are not a Web technology
DIDs has an ADM though?
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.
JSON LD isn't a requirement for DID methods
DIDs do not require JSON-LD. It uses an abstract data model - at Dave’s strong suggestion ;-)
millions of issuers is a lot more realistic...not billions
@tobias Yes. The incepting state crypto commits to the first registrar of the indentifer derived from the crypto commitment.
NETBEUI we miss you
I think there's a bright future for did:ads :)
Hunter Cain 01:19:55
but @Markus - we’re allowing advertising?
Agree sam wasn’t clear with ADS if that was the same situation
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.
Dave how is this a user sovereign if a user can’t “take their data and go home” to another system that uses DIDs?
And it has a patent pending component, yes?
@Riley you're missing the point, you can with ADS
No @drummond, he's recommending RSA accumulators, no patent there
Any DID method can use RSA accumulators too though no?
Thanks for the session, Dave, and for the discussions, Joe, Sam, etc.
Demo time now
@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.
horrible security though :: grin ::
Crypto accumulators operate at the VC layer not the keystate layer
Yeah +1 this is a great conversation none the less