W3C home > Mailing lists > Public > public-credentials@w3.org > December 2017

Re: Worldview conflicts on the purpose of DID documents

From: =Drummond Reed <drummond.reed@evernym.com>
Date: Thu, 14 Dec 2017 12:03:59 -0500
Message-ID: <CAAjunnYYtfNMtCwOuW5eW3ygt3kyL36LkyT7KJdqaO_cyjdCGw@mail.gmail.com>
To: Dave Longley <dlongley@digitalbazaar.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>, Credentials Community Group <public-credentials@w3.org>
On Thu, Dec 14, 2017 at 10:52 AM, Dave Longley <dlongley@digitalbazaar.com>
wrote:

> On 12/13/2017 11:57 PM, Manu Sporny wrote:
>
>> On 12/13/2017 01:38 PM, =Drummond Reed wrote:
>>
>> This necessarily includes specifying how that DID document can be changed.
>>>
>>
>> Dave may be being quoted out of context here, but (like Markus) I
>> disagree with the statement above. This is true for Veres One
>> because it's a declarative blockchain, but not necessarily true for
>> other Blockchains.
>>
>
> To quickly clarify this one point:
>
> The only interoperable place where a user (DID "owner"/"controller") may
> express their own desires is in the DID document.
>
> This includes specifying any custom preferences about how the DID
> document itself is updated. If a DID method does not permit a user to
> express any sort of custom rules for updating a DID document or will not
> honor them (for example, expressing rules to allow for social key
> recovery via N specific peers) then it is true that any such rules would
> always be absent from (or inert in) DID documents that derive from that
> method.


Good clarification, Dave. I think it reinforces the conclusion reached at
the Boston Rebooting the Web of Trust conference in October, which was that
any subset of a DID document that controls how the DID document can be
accessed/updated on the target system (blockchain, ledger, distributed
database, etc.) MUST be defined in the relevant DID method spec because the
only enforcement point for such access control rules (or capabilities) is
the target system.

I too am a fan of OCAP (the object capabilities security model
<https://en.wikipedia.org/wiki/Object-capability_model>), so I'm thinking
that if the different method authors decide it would be good to have a
common way to represent capabilities in DID documents, we could collaborate
on a separate spec for that.
Received on Thursday, 14 December 2017 17:05:00 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:18:17 UTC