Re: DID Key Management Harmonization Proposal #1

On 01/09/2018 04:09 AM, =Drummond Reed wrote:
> "encryption" might also be on the "core properties" list. In other 
> words, if the idea is to separate the list of public key objects
> from the list of authentication "suite" or encryption "suite"
> purposes, then encryption seems nearly as important as
> authentication.

It's a topic of discussion. The group could go either way and I can't
say that I have a good read on the options. For example, if one were to
argue that authentication should be a service... then what about
encryption as well? As Markus pointed out, encryption is highly
dependent on the sort of crypto you're using as well. It's for those
reasons that I hesitated to put it in the core proposal.

Given the "if we had to do one thing, we'd work on authentication" theme
that I kept hearing and given the further discussion we need to have on
encryption, I thought we'd defer the discussion until after we got the
authentication stuff sorted out so that folks felt like we have at least
closed out the biggest issue on the table.

So, yes, encryption is important, but wanted to try and wrap up the
authentication use cases while hinting at how we might do encryption in
the next round of discussions (rather than try to tackle everything at
once).

> What is the uncertainty about encryption? Why is it a second-class 
> citizen to authentication?

There seems to be uncertainty on whether or not folks want to accomplish
encryption as a service or as something else. It'll be one or the other,
but the discussion is younger than the authentication discussion.

It's has more to do with how we prioritize discussions, not that we
wouldn't support encryption in some way in DID v1.

> // verifiable credentials "credentials": [ { ... }, ... ],
> 
> // services "services": [ { ... }, ... ] }
> 
> While this is a good example of how the spec may be extended, as 
> discussed on the last Closure Call, we need to avoid going down the 
> slippery slope of defining anything outside of the core properties in
> the main DID spec. Agreed?

Agreed, it was just there mostly for holistic purposes. It hints at how
we would address those use cases w/o having to dive deep. We may even
want to reserve the property names in the JSON-LD Context as a placeholder.

> This property lists any public key cryptographic material that is 
> owned by the entity represented by the DID (or a delegate). Biometric
> material, smart contracts, etc. do not belong in this field and an
> error should be thrown by processors if any non-owned non-public key
> data is found in the publicKeys field.
> 
> While it's an interesting idea, by why tests would such an error be 
> detected?

It helps enforce the purpose of the field. If we don't throw errors when
we detect bad usage, then the likelihood that the field will start being
abused is higher. To put it another way, we can always relax the rules,
but the opposite is rarely true.

> Note that this DOES NOT mean that an application, such as a website 
> performing login authentication, must accept all authentication 
> mechanisms listed in the DID Document. The list of acceptable 
> authentication mechanisms will be the union of what the DID Document
> 
> Markus pointed out that he believes you meant "intersection" not 
> "union", yes?

Yep, sorry, I meant intersection.

> There are certainly variations to the algorithm that we can discuss, 
> but that would be the general structure of it, which would be fairly 
> simple to implement in code, operating using a stock JSON processor.
> 
> Given the growing interest in DID Auth—and that what you are 
> proposing is one potential definition of a DID Auth protocol—this 
> could be a good step in that direction. On the DIF call we discussed 
> whether in fact this isn't better described as a service, albiet one 
> that does not require a separate service endpoint (the way this 
> particular protocol flow works—a variant that would send the 
> challenge out-of-band, such as to a mobile phone, would require that 
> endpoint).
> 
> What are your thoughts on why this is not a service?

Fundamentally, you can do authentication purely on messages... outside
of a protocol. So, in some cases you don't really care what protocol was
used to get a message to you (NFC, HTTP, Bluetooth, etc.)... all you
care about is that you have a signed message and you need to
authenticate the sender of that message. It's not necessarily a service,
but a meta-service.

There's a fair amount of hand waving there and one could easily argue
that you could just create a generalized service for authentication, and
I think that's a fair point and worth a debate on the topic.

> There is still a danger that one completely mis-implements the 
> specification and just searches through publicKeys. A mitigation for
>  this would be to remove the publicKeys property, which a few seem 
> like they would be unlikely to do.
> 
> Speaking for the minimalist worldview, I would say the publicKeys 
> property is the keystone of this proposal ;-)

One could still argue that you could remove publicKeys and the whole
system would work. It's just that some in the group wouldn't be happy
with that approach... which is why the compromise to include publicKeys
is there. :)

For example, the code path provided in the initial proposal would allow
a DID ledger to exist that made sure that full key definitions were used
in the authentication field, which would mean the general algorithm
would never fall back to the publicKeys array.

it also means that a DID ledger could opt to put full key definitions in
the publicKeys array and use references elsewhere, and everything would
still work.

So, two different world views supported by the same unified algorithm.

-- 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 Tuesday, 9 January 2018 22:54:54 UTC