Re: Bag of Data Anti-pattern

Great overall discussion in this thread.

Quick comment on the "Keys-used-to-update-the-DID-Document" topic
(FUNCTION 1 in Joe's e-mail):

I agree most methods don't need to store these keys in the DID Document
itself, since using them to update the DID Document is method-specific
functionality.
Except for Veres One, as Manu says, which uses information from the DID
Document to implement updates (I think you called this "declarative" at
some point).

However I could also envision Bitcoin or Ethereum based DID methods that
also "update" their DID Documents using keys that are NOT the native
Bitcoin or Ethereum keys, in which case you would still have to store
them in the DID Document similar to Veres One.

I could also envision a minimal DID method that only supports a single
key, which would be used both for updating the DID Document itself, and
also for other purposes/applications (i.e. this single key is used both
for FUNCTION 1 and FUNCTION 2 in Joe's term).

Not saying these would be super useful DID methods, but I'd actually be
interested in trying to define them, just to see if the overall
framework is flexible enough to support them.

Markus

P.S. I don't have a strong opinion right now on how to model "keys",
"auth suites", "purposes", etc., but intuitively I have felt for a while
that it would make sense to have the "purpose" (or "application" or
"usage") somehow separated from the technical key properties (the "type").

On 01/03/2018 08:17 PM, Manu Sporny wrote:
> 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
>

Received on Thursday, 4 January 2018 16:44:17 UTC