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

Oskar's list is helpful by analogy to decentralization in blockchains:

   - BTC, ETH
   - DOGE
   - DIEM (ex Facebook Libra)
   - ETH2
   - Petro (Venezuela)

It's natural for sovereigns like DHS to want to establish centralized
"safety authorities" like W3C.

There's nothing wrong with having a Federal Reserve or an FDA but
decentralization, blockchains have taught us, does not depend on many
standards beyond TCP/IP. If W3C can't handle DID then it's the wrong place
to pursue standards essential to decentralization.

- Adrian

On Tue, Oct 19, 2021 at 6:22 AM Deventer, M.O. (Oskar) van <
oskar.vandeventer@tno.nl> wrote:

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