RE: Discussion w/ Google about their DID Core Formal Objection

(Warning: philosophical discussion ahead)

Manu, all,

Thank you for the very clarifying summary!

One concern that Google is addressing, is that a DID method can be seen as a “brand” identifier for the associated “SSI infrastructure assurance community”.

  *   Some “DID brands” are well established, and have a reliable assurance community that addresses any issues like non-compliant implementations, breaches or forgeries
  *   Some “DID brands” are upcoming, and may have some serious issues with security, privacy, environment, key-recovery and other
  *   Some “DID brands” may not comply to the decentralization spirit of the SSI Community, but otherwise be completely sound
  *   Some “DID brands” may have a too-immature or malfunctioning assurance community
  *   Some “DID brands” may be opportunistic or even become evil
Unlike medicine brands with their medicine-safety authorities, there does not exist something equivalent for a “DID brand”.

I read the analysis below partly as an urge to establish “DID-brand safety authorities”, one of which could be W3C itself.

Oskar


From: Drummond Reed <drummond.reed@evernym.com>
Sent: 19 October 2021 06:58
To: Manu Sporny <msporny@digitalbazaar.com>
Cc: public-did-wg <public-did-wg@w3.org>
Subject: Re: Discussion w/ Google about their DID Core Formal Objection

Manu, thanks very much for posting this summary. I agree with you that I find some aspects of Google's position quite understandable and reflective of the kind of market feedback I would expect on DID 1.0.

However I remain completely unconvinced that any of it is a reason to formally object to the DID 1.0 spec.

I look forward to discussing it on the DID WG call tomorrow.

=Drummond

On Mon, Oct 18, 2021 at 6:43 PM Manu Sporny <msporny@digitalbazaar.com<mailto:msporny@digitalbazaar.com>> wrote:
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

This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.