Re: Ideas about DID explanation

On 12/5/18 5:39 AM, Daniel Hardman wrote:
> I like this list. It's a good summary. I just wanted to comment on
> nuances of 3 of them.
>  
>
>     5) includes the associated DID Document, which may contain
>     material used to authenticate the DID, the DID Document, and the
>     DID 'owner/controller' 
>
>
> I have run into this sort of verbiage before, that a DID "includes" a
> DID Document. I think the phrase "is associated with" or "may be
> associated with" is more accurate. A DID that has been created but not
> yet written to anywhere that associates it with a DID Document is
> still a DID, is it not?

I'd say that:

- The DID is the identifier; anything that's valid syntax according to
the DID spec and a DID method spec can be called a DID.
- All DID methods must support a "Register" operation; after it is
successfully executed, the DID that has now been registered must support
a "Resolve" operation that returns a DID document.
- Steps such as creating wallets, generating cryptographic materials,
etc. may constitute preparatory steps for the "Register" operation, but
unless you complete the full "Register" operation as defined by the DID
method spec, this is pretty much irrelevant for the state of the DID itself.

So I think your way of putting it, "A DID that has been created but not
yet written anywhere that associates it with a DID Document" is incorrect.

Either you have performed the DID method's "Register" operation, or
haven't. There is no such thing a DID that has been "created" but not
"registered". Generation of a key pair in wallet alone without
completing the "Register" operation may be a preparatory step, but
ultimately irrelevant for the DID's lifecycle.

>
>     a) DID authentication may use cryptographic proofs to demonstrate
>     which entity is the 'owner/controller'. 
>
>
> Using the "owner" metaphor for DIDs has some interesting legal
> baggage; we might be better served to favor "controller."
> See https://medium.com/@hackylawyER/do-we-really-want-to-sell-ourselves-the-risks-of-a-property-law-paradigm-for-data-ownership-b217e42edffa
>  

Important point, thanks Daniel. Also see Joe Andrieu's reasoning on this
topic:
https://github.com/WebOfTrustInfo/rebooting-the-web-of-trust-spring2018/issues/96

>     b) When cryptographic proofs for DID authentication are used, this
>     enables special properties associated with zero knowledge proofs
>     such as selective disclosure, <<what is this list?>>
>
>
> I don't think ZKPs have anything inherent to do with DIDs or DID
> authentication, or that DIDs do anything special to enable selective
> disclosure--unless you're talking pairwise DIDs to manage correlation.
> DIDs may be used in conjunction with ZKPs and selective disclosure,
> but I don't think either requires the other. Is there some connection
> here that I'm not considering?
>  
>
This is the Sovrin way of thinking, to consider DID authentication and
exchange of credentials/proofs to be separate and happening on different
layers of a stack (or along the different "relationship" / "attribute"
dimensions). Personally I also like this way of thinking, to have a
rather narrow definition of "DID Auth" (= prove control of a DID).

But it's not the only way of thinking about this. There are also
approaches to decentralized identity protocols out there where those two
things are not so separate, and where "proving control of a DID" and
"proving something else" could happen as part of a single protocol on a
single layer of a stack. In such an approach, "DID Auth" and ZKPs could
be more closely intertwined than it is in Sovrin.