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

On Tue, Apr 16, 2019 at 5:36 PM Adrian Gropper <agropper@healthurl.com>
wrote:

> I’m a bit confused.
> - Is the DID method always tied to a wallet or other holder agent in any
> particular way?
>

While it would be possible to build a wallet and agent/hub that only
generated or accepted DIDs (or credentials based on those DIDs) from
specific DID methods, IMHO that would be like building a browser that only
worked with certain websites. The whole goal of "one wallet one experience"
(credit to Adam Gunther of IBM) is that your wallet is never tied to any
specific DID method or any specific credential type—any more than your
physical wallet would be restricted to a particular credential type or
currency type.


> If not then do verifiers get to consider both separately?
>

From an assurance point of view, yes, that was what Luca's message pointed
out. When needed, a verifier might want to separately assess:

   1. The wallet/agent/hub you are using—so the verifier can assess its
   level of assurance (LOA) in that component.
   2. The DID method used for a credential of which you are presenting a
   proof—so the verifier can assess its LOA in that DID method.
   3. The issuer of the credential—so the verifier can assess its LOA in
   that issuer's identity.
   4. The trust/governance framework for the issued credential—so the
   verifier can assess its LOA in the claims it needs.



> - I can understand a verifier refusing to accept a DID method they
> consider insecure no matter the issuer but, can an issuer refuse to use my
> DID because they don’t like my method or my wallet?
>

So first, let me stress again that, assuming you are using a universal
wallet, your wallet would not be tied to a specific DID method. However a
verifier *could* decide not to accept a credential proof because its
assessment of the LOA of your wallet/agent/hub was not high enough (#1 in
the list above). Or #2, #3, or #4 for that matter.

=D


> Adrian
>
> On Tue, Apr 16, 2019 at 1:14 PM Avesta Hojjati <
> avesta.hojjati@digicert.com> wrote:
>
>> It is important to understand that the platform is decentralized,
>> therefore it enables other components (DIDs, Keys, etc) to be decentralized
>> as well. If we are specially discussing about the private keys, then the
>> terminology will differ, for example are we talking about MPC when it comes
>> to decentralized private keys or multiple copies of the same private key
>> being distributed.
>>
>>
>>
>> Im sure Drummond has some content in regards to this in the trust
>> framework.
>>
>>
>>
>> -Avesta
>>
>>
>>
>> *From: *Christopher Allen <ChristopherA@lifewithalacrity.com>
>> *Date: *Tuesday, April 16, 2019 at 12:08 PM
>> *To: *=Drummond Reed <drummond.reed@evernym.com>
>> *Cc: *Adrian Gropper <agropper@healthurl.com>, Avesta Hojjati <
>> avesta.hojjati@digicert.com>, Credentials Community Group <
>> public-credentials@w3.org>, David Chadwick <D.W.Chadwick@kent.ac.uk>,
>> Luca Boldrin <luca.boldrin@infocert.it>
>> *Subject: *Re: Materials from 2019-04-11 combined DID Spec and DID
>> Resolution Spec meeting
>>
>>
>>
>> I wonder if in trying to define requirements for what is or isn’t
>> decentralized, that maybe we are missing the most important thing:
>> decentralized keys. If “proper” DIDs were restricted in some way to only
>> support those systems where the keys are self-administrative with full
>> CRUD. In some ways, the rest of the “decentralized” items can be wishlist,
>> but necessary a requirement.
>>
>>
>>
>> — Christopher Allen [via iPhone]
>>
> --
>
> 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/
>