Re: Bag of Data Anti-pattern

Seems like Joe, Pelle, and I seem to agree on the fundamentals...

On 01/03/2018 11:51 AM, Pelle Braendgaard wrote:
> I am in general fine with your approach Joe. Purpose is important. 
> I'm also fine with it being called "auth" over "keys".

+1

> From a blockchain stand point I also just want to be clear that all 
> the different blockchain implementations I've seen don't store the 
> Owner/master key in the DID Document itself. However the DID
> Document is updated is completely implementation specific and can not
> be standardized.

Almost +1, with the exception of Veres One, which does attempt to
standardize how this is done via the LD ocap spec.

That said, Pelle is correct, Bitcoin nor Ethereum is built to do this so
it doesn't make sense from the perspective of those blockchains.

> Some implementations may need this and some implementations may need
>  other things. We should stay out of standardizing too much there. 
> The only real thing required is to be able to find a public key for
> a DID to verify signed data from said DID. Having a "purpose" type 
> allowing innovation to happen separately will manage this.

+1, for a loose definition of "purpose". We have been calling this
"application", and there are multiple ways to solve that issue, but
fundamentally, that's an easier discussion to have once we agree that
"purpose"/"application" is important... and it sounds like at least Joe,
Pelle, and I agree there.

> The only 2 purposes that I think may be universally useful and can't 
> be delegated to the method implementation layer is:
> 
> - "authentication" - "encryption"

+1

> Not married to any specific name. The above 2 purpose types shouldn't
> even be required, but may be required by other specs built on top of
> it.

We can use SHOULD language, as these are two use cases that are fairly
universal across all DID blockchains under consideration right now, and
are thus a good candidate for standardization.

In other words:

A DID Method that supports DID-based authentication SHOULD use the
"authentication" purpose.

A DID Method that supports DID-based encryption SHOULD use the
"encryption" purpose.

One could argue that we could split both of these functions out into
separate specs, but let's just put it in the DID spec for now and split
it out if the sections get unwieldy. Over modularization of specs tends
to make specs much harder to read.

There is also a security concern that we should take into account, but
I'll raise that later after we have a rough sketch of the direction the
group wants to head in.

> Things like recovery keys, modification keys are all pretty much 
> method specific. There may be cross DID services that emerge that
> may have their own keys as well.

+1

> To me all I want us to do is focus on the lowest common denominator 
> as well as have something that is open enough for anyone to build 
> their own specific methods etc on top of.
> 
> Lets keep it simple and open to innovation.

+1

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: The State of W3C Web Payments in 2017
http://manu.sporny.org/2017/w3c-web-payments/

Received on Wednesday, 3 January 2018 19:17:51 UTC