Re: DID Key Management Harmonization Proposal #1

On Tue, Jan 9, 2018 at 3:04 PM, Adrian Gropper <agropper@healthurl.com>
wrote:

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

A DID ledger is a simple generic way to refer to "a distributed system that
supports a DID method". For example, for the BTCR method, Bitcoin is the
DID ledger. For the uPort DID method, Ethereum is the DID ledger. For
the Sovrin DID method, Sovrin is the DID ledger.

=D


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