Re: Materials from 2019-04-11 combined DID Spec and DID Resolution Spec meeting

On Mon, Apr 15, 2019 at 12:56 AM Markus Sabadello <markus@danubetech.com>
wrote:

> I agree one of the strengths of the DID concept is that different DID
> methods will compete for trust while still being interoperable.
>
> Unfortunately, I am not convinced that non-decentralized DIDs (Google,
> Facebook, DNS) will end up low on the list, if we decide to "allow" them.
>
I see that danger too. Since I don't see any way to specifically "disallow"
them, I am in favor of putting strong language in the DID spec to warns
against using DID methods that rely on a central authority who cannot
provide the same trust assurances as a decentralized network. Do others
agree?


> On 4/15/19 12:59 AM, =Drummond Reed wrote:
>
> I am worried that the arguments in this thread are not based on a solid
> understanding the role of DIDs in relationship to DID methods, DID
> registries (blockchains, DLTs, DHTs, etc.), verifiable credentials, and
> governance frameworks—in other words, to the "full stack" of decentralized
> trust infrastructure.
>
> An actual DID record, i.e., the DID and the DID document it resolves
> to—which can tell you the public key(s), authentication method(s),
> and service endpoint(s) associated with the DID at a specific point in
> time)—are just one element that a verifier (aka relying party) must
> consider in making a trust decision about accepting a proof of a particular
> verifiable credential.
>
> Yes, the DID of the credential issuer is a very important element in this
> chain, because if the verifier does not trust the authenticity or integrity
> of the DID document that the verifier resolved from the DID, then prima
> fascia, the verifier cannot trust the credential.
>
> But at this level, the verifier's trust decision is not about the DID
> itself. It's about *trusting the strength of the DID method and the DID
> registry that the DID method operates against*.
>
> When looked at from that perspective, I believe it becomes easier to
> address some of the concerns raised in this thread, because market forces
> should push verifiers towards trusting DID methods and DID registries that
> provide the strongest trust assurances. Almost by definition,
> single-provider solutions (e.g., Facebook for the theoretical
> "did:facebook:" or Google for "did:google:") would be low on that list
> because single-provider solutions are under the control of a single entity
> and suffer from all the disadvantages of single points of failure (no
> matter how "distributed" their actual network).
>
> So would any other company that offered "its own" DID method.
>
> Even a government that offered its own DID method might have trouble
> building trust in that method because presumably the validator nodes
> ("stewards") in that government's network are all ultimately under the
> control of that government—so the government could decide to fork the
> entire DID registry at some point and all the nodes would comply.
>
> In the end, it comes down to a "virtuous cycle" competition between
> different DID methods and the DID registries they operate against for who
> can provide the highest trust assurances. Those DID methods will be the
> ones issuers will choose for their DIDs simply because those are the ones
> who will be trusted by verifiers.
>
> I believe this point is important enough that I'll work with the other
> editors to craft a paragraph explaining this in the Community Final Draft
> DID spec that we're trying to finish by the end of the month.
>
> On Sat, Apr 13, 2019 at 7:02 PM Michael Herman (Parallelspace) <
> mwherman@parallelspace.net> wrote:
>
>> Initially, I believe virtually every web site that supports authenticated
>> logins/sign-ins today will have their own DID Scheme …with high
>> probability.
>>
>>
>>
>> My favorite example is http://www.meetup.com.  Every meetup.com member
>> will likely have their own meetup.com DID in their wallet.  Why would
>> meetup.com risk trusting anything/anyone else’s DIDs?  What’s the
>> incentive?
>>
>>
>>
>> Another example: Mike Brown is doing a great job at the Alberta
>> provincial government owned ATB but why will anyone outside the province of
>> Alberta trust an ATB DID?
>>
>>
>>
>> Prepare to have a wallet with lots and lots of DIDs …at the beginning and
>> for a long time  afterwards: Social Evolution and Technology Adoption (
>> https://hyperonomy.com/2019/04/08/social-evolution-and-technology-adoption/
>> ).
>>
>>
>>
>> Best regards,
>>
>> Michael Herman (Toronto/Calgary/Seattle)
>>
>> Independent Blockchain Developer
>>
>> Hyperonomy Business Blockchain / Parallelspace Corporation
>>
>>
>>
>> W: http://hyperonomy.com
>>
>> C:  +1 416 524-7702
>>
>>
>>
>>
>>
>> *From:* Tim Bouma <trbouma@gmail.com>
>> *Sent:* April 13, 2019 5:28 PM
>> *To:* Steven Rowat <steven_rowat@sunshine.net>
>> *Cc:* Markus Sabadello <markus@danubetech.com>; W3C Credentials CG
>> (Public List) <public-credentials@w3.org>
>> *Subject:* Re: Materials from 2019-04-11 combined DID Spec and DID
>> Resolution Spec meeting
>>
>>
>>
>> Hi,
>>
>>
>>
>> Acceptance of DIDs will be something that the various trust frameworks
>> will determine.
>>
>>
>>
>> See section 5.6.1 on the IMSC Pan-Canadian Trust Framework Draft below
>>
>>
>>
>> https://canada-ca.github.io/PCTF-CCP/
>>
>>
>>
>> You will see Vectors of Trust as qualifiers.
>>
>>
>>
>> We could add DID methods as another qualifier; it will likely be a
>> qualifier added to conformance criteria for the credential authentication
>> trusted process. As for trusting Facebook, Microsoft, etc., we will need to
>> see how the ecosystem sorts itself out based on fair standards.
>>
>>
>>
>> Trusting a DID is only one piece as there are many other pieces that need
>> to be trusted.
>>
>>
>>
>>
>>
>> Tim
>>
>>
>>
>>
>>
>>
>>
>> On Sat, Apr 13, 2019, 6:44 PM Steven Rowat, <steven_rowat@sunshine.net>
>> wrote:
>>
>> On 2019-04-12 2:05 pm, Markus Sabadello wrote:
>> > Slides, recording and notes for the 2019-04-11 combined DID Spec and DID
>> > Resolution Spec meeting is here:
>> >
>> https://github.com/w3c-ccg/meetings/tree/gh-pages/2019-04-11-did-spec-and-resolution
>> >
>>
>> In these notes there's a fairly long discussion of the possibility of
>> "did:facebook" etc, and what those silo's methods might mean. Marcus
>> said at one point:
>>
>> > [2019-04-11T20:18:13.165Z] <dlongley> markus_sabadello: The only
>> argument I heard that I understand a little bit from Joe Andrieu is that
>> ... we could argue that the DID URL scheme as a whole would still be
>> decentralized because you can argue to use which method you want. This
>> would be a big change from how we use DIDs so far, but I could understand a
>> little bit. If you don't want to use a facebook DID you can use Sovrin or
>> Veres One. So the whole space [would be] decentralized though individual
>> methods might not be.
>>
>> As far as I can understand from reading these meeting notes, Markus
>> was pointing out what seems to be a major discrepancy between the
>> original goals (and still current via the DID .012 spec) and the
>> possibility that methods could be written for DID for did:facebook,
>> etc. that don't follow these goals.
>>
>> I'd like some clarification about this because it seems to change a
>> lot that I had assumed was happening in this group.
>>
>> Specifically, does this mean that, say, if Facebook, Google,
>> Microsoft, Apple, (etc.) each write their own DID method, and write
>> them so that they're as silo'd as possible (which they may well do),
>> then it's likely that:
>>
>> a) There is no data portability for all the people using those silo'd
>> DIDs;
>> b) There may be limited (or no) pseudonymity or privacy for the people
>> using those DIDs; and perhaps other limits.
>>
>> Is this accurate?
>>
>>
>> Steven
>>
>>
>>
>> On Sat, Apr 13, 2019, 6:44 PM Steven Rowat, <steven_rowat@sunshine.net>
>> wrote:
>>
>> On 2019-04-12 2:05 pm, Markus Sabadello wrote:
>> > Slides, recording and notes for the 2019-04-11 combined DID Spec and DID
>> > Resolution Spec meeting is here:
>> >
>> https://github.com/w3c-ccg/meetings/tree/gh-pages/2019-04-11-did-spec-and-resolution
>> >
>>
>> In these notes there's a fairly long discussion of the possibility of
>> "did:facebook" etc, and what those silo's methods might mean. Marcus
>> said at one point:
>>
>> > [2019-04-11T20:18:13.165Z] <dlongley> markus_sabadello: The only
>> argument I heard that I understand a little bit from Joe Andrieu is that
>> ... we could argue that the DID URL scheme as a whole would still be
>> decentralized because you can argue to use which method you want. This
>> would be a big change from how we use DIDs so far, but I could understand a
>> little bit. If you don't want to use a facebook DID you can use Sovrin or
>> Veres One. So the whole space [would be] decentralized though individual
>> methods might not be.
>>
>> As far as I can understand from reading these meeting notes, Markus
>> was pointing out what seems to be a major discrepancy between the
>> original goals (and still current via the DID .012 spec) and the
>> possibility that methods could be written for DID for did:facebook,
>> etc. that don't follow these goals.
>>
>> I'd like some clarification about this because it seems to change a
>> lot that I had assumed was happening in this group.
>>
>> Specifically, does this mean that, say, if Facebook, Google,
>> Microsoft, Apple, (etc.) each write their own DID method, and write
>> them so that they're as silo'd as possible (which they may well do),
>> then it's likely that:
>>
>> a) There is no data portability for all the people using those silo'd
>> DIDs;
>> b) There may be limited (or no) pseudonymity or privacy for the people
>> using those DIDs; and perhaps other limits.
>>
>> Is this accurate?
>>
>>
>> Steven
>>
>>
>