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

I believe that if you look at the DID Use Cases document, https://w3c-ccg.github.io/did-use-cases/, in the requirements section you'll see a lot of points related to survivability, but not necessarily portability/substitutability. There are some that are close, but it isn't obvious. That's probably an oversight.

In the VC use case driven requirements https://w3c.github.io/vc-data-model/#use-cases-and-requirements, we were explicit about the need for the holder's freedom to use any agent software they like. 

> Holders <https://w3c.github.io/vc-data-model/#dfn-holders> can interact with any issuer <https://w3c.github.io/vc-data-model/#dfn-issuers> and any verifier <https://w3c.github.io/vc-data-model/#dfn-verifier> through any user agent.

The verifiability is NOT dependent on the wallet. 

We really should include that requirement in the DID work. The math and the network are what relying parties should be checking for. The truth is, you can NEVER trust the client/user-agent. That's the whole point of keys and DLTs, they provide a way around that.

So I would go further than Drummond and suggest that we advocate for interoperability requirements that prevent white-listing specific instances of software. IMO, that way lies madness.

The current approach is parallel to the data model & syntax approach of VCs, so we can't require that any given software do anything in particular, but we can require that the data model and resulting capabilities must work, regardless of which agent is performing the related step.

Kim-- we should figure out how to integrate this into the use case document.

-j

On Tue, Apr 16, 2019, at 7:13 PM, =Drummond Reed wrote:
> 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/

--
Joe Andrieu, PMP
joe@joeandrieu.com
+1(805)705-8651
http://blog.joeandrieu.com