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

Adrian has a great point. As a founding board member of the OpenID
Foundation, I watched the same thing happen—a technology designed to
"democratize login" was subject to the same forces that will apply to DIDs,
i.e., verifiers defaulting to wanting DIDs from OpenID providers that could
offer the highest assurance. With OpenID, it turned out that was very large
commercial providers of OpenID service.

But I would argue that defaulting to the largest service providers for high
trust assurance was in fact the only choice with OpenID since it is an IDP
(identity provider) model. With DIDs and SSI, we are moving from an IDP
model to a digital credential model. Now the root of trust is not an IDP,
it is the network in which a DID is rooted. And in that model,
decentralized networks provide a much stronger root of trust than any
centralized network.

So if the same market forces apply—verifiers seeking the highest trust
assurance—they will prefer DIDs from the strongest decentralized networks.


On Mon, Apr 15, 2019 at 4:44 AM Adrian Gropper <agropper@healthurl.com>
wrote:

> I see an analogy with OpenID Connect. Many years ago, I had an OpenID from
> a security company. It was occasionally useful. Today, the only OIDC I see
> is facebook, google, and increasingly twitter. Open OIDC is never an option
> any more.
>
> DIDs must be different. If a service accepts LogIn with Google (DID) and I
> enter the Facebook method, on what basis does Google fail? Is this the same
> fail as if I try to use a weak DID method to cross a border?
>
> Adrian
>
> On Mon, Apr 15, 2019 at 4:04 AM =Drummond Reed <drummond.reed@evernym.com>
> wrote:
>
>> 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
>>>>
>>>>
>>> --
>
> Adrian Gropper MD
>
> PROTECT YOUR FUTURE - RESTORE Health Privacy!
> HELP us fight for the right to control personal health data.
> DONATE: https://patientprivacyrights.org/donate-3/
>