Re: DID Key Management Harmonization Proposal #1

What's a DID ledger? How's it different from a DID method?

On Tue, Jan 9, 2018 at 5:54 PM, Manu Sporny <msporny@digitalbazaar.com>
wrote:

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


-- 

Adrian Gropper MD

PROTECT YOUR FUTURE - RESTORE Health Privacy!
HELP us fight for the right to control personal health data.
DONATE: https://patientprivacyrights.org/donate-3/