Discussion w/ Google about their DID Core Formal Objection

Hi DID WG,

I had a chance to engage with a few individuals at Google concerning
their Formal Objection to the DID Core 1.0 Recommendation. The goal of
the meeting was to reflect what I interpreted their position to be, have
them correct any misinterpretation I had, and then explore concrete
actions the DID WG could take to address their concerns. The goal was
not to litigate their position or negotiate a timeline, but rather to
understand the formal objection at depth and focus on concrete
solutions. They have read this email to ensure that I am summarizing
what was discussed accurately.

The core of Google's argument is that it is difficult to understand how
the DID Core specification improves practical interoperability with no
standardized DID Methods. That is, understanding the ecosystem requires
a few DID Methods that the DID WG believes is a good reflection of
"ideal DID Methods" that achieve the mission of the DID Working Group.

Secondary concerns include whether or not a DID Method violates the
W3C's Ethical Web Principles[1], such as environmental
sustainability[2], or security and privacy[3]. For example, if a DID
Method is expected to be used as a pervasive tracking identifier, the
browser team at Google might file a future objection for that particular
DID Method.

They were also interested in how a particular DID Method addresses
account recovery when someone loses a private key, the private key is
compromised, and so on. That is, how do you get your identifier back in
those scenarios?

We also explored if did:key and did:web would be "good enough" as two of
the three methods Google would like to see standardized, and the concern
there was that they don't achieve the levels of decentralization that
they were expecting the group to achieve. Ideally, Google would like to
see three decentralized methods that go beyond what did:key (no key
rotation) and did:web (requires DNS and hosting files on a web server)
provide. We also discussed the DID WG's strategy of not suggesting that
we are "picking a winner" when it came to decentralized methods, but
again, the purpose of the call was not to litigate who is right/wrong.
The proposal was to standardize multiple decentralized methods that were
of most benefit to people. Effectively, yes, standardize did:key and
did:web, but those are not in the set of the three decentralized methods
Google would like to see.

There were two other items that came up during the call that were
notable. The first item was related to documentation and how it's hard
to understand how the macro ecosystem is expected to operate. For
example, when a DID is included in a Verifiable Credential, there is no
protocol diagram on how DIDs, DID resolvers, Verifiable Data Registries,
DID Documents, and other components interact when cryptographic
verification happens. It is also not clear in the DID Method registry
what the implementation status of any of the DID Methods are, or if any
of them are more mature than the others. The request was more
documentation around how this "verifiable web ecosystem" is intended to
fit together.

The second item was related to what the DID WG Charter intended to
standardize. We discussed that the DID Core specification is a data
model specification and the suggestion was that if the DID WG had just
stuck to a pure data model specification there might not have been an
objection. The three items that seemed to go beyond a pure data model
specification was the definition of the DID identifier format, the
specification of requirements on DID Methods, and the specification of
an abstract interface for DID Resolution. I found this perspective
particularly interesting as a thought exercise.

-- manu

[1]https://www.w3.org/2001/tag/doc/ethical-web-principles/
[2]https://www.w3.org/2001/tag/doc/ethical-web-principles/#sustainable
[3]https://www.w3.org/2001/tag/doc/ethical-web-principles/#privacy

-- 
Manu Sporny
Founder/CEO - Digital Bazaar, Inc.
Our Verifiable Credential Deployments
https://www.digitalbazaar.com/case-studies

Received on Tuesday, 19 October 2021 01:42:06 UTC