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>
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
>
>