- From: Markus Sabadello <markus@danubetech.com>
- Date: Mon, 15 Apr 2019 09:56:26 +0200
- To: =Drummond Reed <drummond.reed@evernym.com>, "Michael Herman (Parallelspace)" <mwherman@parallelspace.net>
- Cc: Tim Bouma <trbouma@gmail.com>, Steven Rowat <steven_rowat@sunshine.net>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <a7aee55e-c387-5e17-f831-01dd0b0fae50@danubetech.com>
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.
Markus
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 <mailto: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
> <http://meetup.com> member will likely have their own meetup.com
> <http://meetup.com> DID in their wallet. Why would meetup.com
> <http://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 <http://hyperonomy.com/>
>
> C: +1 416 524-7702
>
>
>
>
>
> *From:* Tim Bouma <trbouma@gmail.com <mailto:trbouma@gmail.com>>
> *Sent:* April 13, 2019 5:28 PM
> *To:* Steven Rowat <steven_rowat@sunshine.net
> <mailto:steven_rowat@sunshine.net>>
> *Cc:* Markus Sabadello <markus@danubetech.com
> <mailto:markus@danubetech.com>>; W3C Credentials CG (Public List)
> <public-credentials@w3.org <mailto: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 <mailto: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 <mailto: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
>
Received on Monday, 15 April 2019 07:56:57 UTC