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

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/