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

I agree; created an issue against the use cases repo:
https://github.com/w3c-ccg/did-use-cases/issues/10

On Wed, Apr 17, 2019 at 3:21 PM Joe Andrieu <joe@joeandrieu.com> wrote:

> 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
>
>