Re: Worldview conflicts on the purpose of DID documents

On 12/14/2017 12:03 PM, =Drummond Reed wrote:
> On Thu, Dec 14, 2017 at 10:52 AM, Dave Longley 
> <dlongley@digitalbazaar.com <mailto: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.

Or, alternatively, the core definition can reside in another spec that
DID method specs may reference and define custom mappings to. For
example, the "OCAP DID spec" can say how to do things in a common way
across DID methods that support it.

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

I agree. I think it's fine if certain DID methods don't want to support
user-specified update rules, but if some DID methods want to do this
(and it appears that they do), they should use something interoperable
that can be used by all interested participants rather than each method
reinventing the wheel in different ways.


-- 
Dave Longley
CTO
Digital Bazaar, Inc.
http://digitalbazaar.com

Received on Thursday, 14 December 2017 17:21:03 UTC