Re: What is a DID? Was: Call for Focal DID Use Cases

Personally, I don't see why *self-sovereign* *necessarily* implies not
being tied to a particular institution, jurisdiction, or federation, as
long as the identity owner is still in control of her identifier by means
of being able to create, update and revoke. But maybe I'm missing something
about the fundamentals of self-sovereignty... Any thoughts?

On Wed, Jun 6, 2018 at 8:22 AM, Adrian Gropper <agropper@healthurl.com>
wrote:

> Everything in the DID document is public and hence in category *iii*. The
> spec for what's actually in the DID doc is still somewhat in flux. Category
> *ii* could be a service endpoint pointing to a public document such as a
> website.
>
> As far as I'm concerned (I could be wrong) everything that is not public
> should be behind an authorization barrier such as OAuth. This controls
> access via an object capabilities model mediated by tokens rather than an
> access control list https://github.com/WebOfTrustInfo/rebooting-the-
> web-of-trust-fall2017/blob/master/final-documents/
> identity-hubs-capabilities-perspective.pdf
>
> Adrian
>
> On Tue, Jun 5, 2018 at 7:30 PM, Chris Boscolo <chris@boscolo.net> wrote:
>
>> +1 (Clarifying emails like this are like a warm blanket on a cold winter
>> night.)
>>
>> I have one question, or possibly just a further clarification. Is the
>> following statement true:
>>
>> Items *i* and *ii* can be found in the DID Document, while item "*iii*"
>> (public claims) are not in the DID Document.
>>
>>    -chrisb
>>
>> On Tue, Jun 5, 2018 at 2:53 PM, Adrian Gropper <agropper@healthurl.com>
>> wrote:
>>
>>> (I'm starting this thread because I'm having a hard time following the
>>> "Focal" DID Use Cases)
>>>
>>> A Decentralized IDentifier (DID) is a self-issued IDENTIFIER that is
>>> globally unique within a governance domain called a Method. A DID is
>>> self-sovereign if it is not tied to any particular institution,
>>> jurisdiction, or federation and if the issuer can substitute or choose
>>> among multiple Methods of governance without loss of control of the DID. An
>>> IPFS address is an example of a DID.
>>>
>>> To be practical, a DID associates three essential components:
>>> (i) Zero or more public keys to be used for authentication, digital
>>> signatures, etc...
>>> (ii) Zero or more service endpoints to receive messages or issue access
>>> authorization tokens.
>>> (iii) Zero or more public claims.
>>>
>>> A DID that has neither public keys or service endpoints is merely a
>>> persistent tag with some public claims and with the potential to add public
>>> keys or service endpoints at some point in the future. From a privacy
>>> perspective, it is safe to assume that the public claims will be cataloged
>>> by others and will persist, along with the tag, forever.
>>>
>>> DIDs are de-duplicated (unique) within their Method. They are not a
>>> de-duplicated IDENTITY.  A DID can be associated with a de-duplicated
>>> identity at any time just as it can be associated with any other claim or
>>> credential.
>>>
>>> As defined above, the privacy footprint of a DID is negligible.
>>> Self-issuance means that they can be issued at negligible cost. Public keys
>>> can also be self-issued at negligible cost.  Service endpoints can be
>>> self-issued to some extent (e.g. .onion and ?maybe? IPv6 addresses) Because
>>> service endpoints are routable, they do have some privacy footprint and
>>> this should be considered as part of any use-case.
>>>
>>> Adrian
>>>
>>>
>>>
>>>
>>>
>>> On Tue, Jun 5, 2018 at 5:13 PM, Liam R. E. Quin <liam@w3.org> wrote:
>>>
>>>> On Tue, 2018-06-05 at 17:57 +0000, Christoph Dorn wrote:
>>>> > I have serious concerns that DIDs will be used to bring online, in a
>>>> > central/correlating fashion, what was in the past spread around many
>>>> > parties which by law or inconvenience could not correlate/share
>>>> > information.
>>>>
>>>> These are valid concerns and i'm glad that you are raising them.
>>>>
>>>> A possible mitigation is that an individual can choose to have multiple
>>>> sets of identifiers and multiple third-party repositories as well as
>>>> self-held identifiers. The same applies to Verifiable Credentials.
>>>>
>>>> > I find that this group is skewed towards technology for government
>>>> > and big business (understandably so since it is a W3C group)
>>>>
>>>> One of the unusual aspects of W3C is that individuals can have as loud
>>>> a voice in most respects as governments and large companies.
>>>>
>>>> > I have decided not to contribute individual-empowering use-cases as
>>>> > I
>>>> > think the problem does not lie with DIDs but how they are leveraged
>>>> > by
>>>> > authorities and corporations which is completely out of our hands. I
>>>> > feel like this group is the wrong venue to discuss the layers of
>>>> > abstraction that need to be built on top of DIDs to realize self
>>>> > sovereign identity as it is not purely a technical problem. I don't
>>>> > know if there is a venue for such discussions and if such a venue
>>>> > can
>>>> > actually effectively affect anything.
>>>>
>>>> I think you *should*, if you are willing, contribute them.
>>>>
>>>> We don't do enough at W3C to discuss, think about, encourage discussion
>>>> of wider implications of the technologies we crare, nor contextualize
>>>> them socially. That we could do more doesn't mean we should do nothing.
>>>>
>>>> Liam
>>>>
>>>> --
>>>> Liam Quin, W3C, http://www.w3.org/People/Quin/
>>>> Staff contact for Verifiable Claims WG, SVG WG, XQuery WG
>>>> Improving Web Advertising: https://www.w3.org/community/web-adv/
>>>> Personal: Web-slave for https://www.FromOldBooks.Org/
>>>>
>>>>
>>>
>>>
>>> --
>>>
>>> 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/
>>>
>>
>>
>
>
> --
>
> 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/
>

Received on Wednesday, 6 June 2018 03:36:31 UTC