Need new class of keys because of overloaded Owner Keys

[kimdhamilton]

From @ChristopherA on July 13, 2017 18:24

We have a problem in our DID specification where we are assuming that owner keys are what is also used for signing claims. This is causing us a number of problems in the BTCR method.

What we are discovering is that what the spec says owner key is used for is overloaded.

Instead, I suggest that the owner key(s) are ONLY used for signing DDO objects.

What we need is another list, with a name TBD but is basically the "claim issuer keys", which are in a DDO, signed by the owner keys, which are keys allowed to be used to sign names. This list may, or may not, include the owner key, but if the list doesn't exist, then the owner key is presumed to be one of them.

cc: @talltree @msporny @dlongley

Copied from original issue: WebOfTrustInfo/btcr-hackathon#38

[kimdhamilton]

Ryan and @ChristopherA working on MVP DID Spec. Goal: lessons from hackathon, focus on what is in DDR spec is minimum required for BTCR, make suggestions on what in current DID spec maybe should be moved to method specs.

[kimdhamilton]

From @msporny on July 17, 2017 0:40

Agreed that this is an issue, we hit it this past weekend talking through the spec w/ @talltree in Washington DC.

We need to start considering moving to a capabilities based security model for keys and avoiding the ambient authority security issues that we seem to be marching into.

That is, we should have key attributes in the DDO that are very specific when it comes to what the keys listed can do. Something like:

"pocAuthorization": { // proof of control authorization field
  // key details go here... capability is 'proof of control' ... object is the DDO
}

[kimdhamilton]

From @msporny on July 17, 2017 1:14

@kimdhamilton wrote:

Ryan and @ChristopherA working on MVP DID Spec.

"DID Spec"? Or "BTC DID Method Spec"?

The DID Spec is this: https://opencreds.github.io/did-spec/

[kimdhamilton]

From @ChristopherA on July 17, 2017 1:16

Sounds like we are in general agreement here. I would very narrowly define each capability — I'd rather have the same proof be presented with multiple capabilities rather than overloading a capability.

Another insight from BTCR — whenever you see the word "key", consider not using it. Instead, it is a signature proof, where there may be many other forms of proof in the future. i.e.

"pocAuthorization": { 
  // proof details go here

[kimdhamilton]

From @ChristopherA on July 17, 2017 1:19

In my opinion after the hackathon, which I believe we all concure on is that the current DID draft at https://opencreds.github.io/did-spec/ has many features in it that are a) not required or are not possible in BTCR, and b) many features in it that probably shouldn't be in that spec at all, but another layer.

In particular, guardian is totally broken. A particular proof may be able to be presented by a guardian for different capabilities, and maybe that role is tagged as part of that proof, but it is not a first-order capability.

[talltree]

Seeing this message 2 days later (the hackathon produced a geyser of messages), I just want to go on record that I don't agree. I spent several hours discussing this with Manu and Dave last Friday, and while I'm happy to rename the relation from "guardian" to something more primitive, as a fundamental relationship between key owners, we need it.

=D

On Mon, Jul 17, 2017 at 8:11 PM, Kim (Hamilton) Duffy < notifications@github.com> wrote:

From @ChristopherA https://github.com/christophera on July 17, 2017 1:19

In my opinion after the hackathon, which I believe we all concure on is that the current DID draft at https://opencreds.github.io/did-spec/ has many features in it that are a) not required or are not possible in BTCR, and b) many features in it that probably shouldn't be in that spec at all, but another layer.

In particular, guardian is totally broken. A particular proof may be able to be presented by a guardian for different capabilities, and maybe that role is tagged as part of that proof, but it is not a first-order capability.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/opencreds/did-spec/issues/13#issuecomment-315920592, or mute the thread https://github.com/notifications/unsubscribe-auth/ADLkTWkc_TacoNldNNhK07Fi30XFbl5vks5sO_g6gaJpZM4OasGZ .

[msporny]

It took @talltree and us a while to dig down into the exact definition of guardian and what it could/couldn't do, so that may be the first thing that we need to discuss: "What are a guardian's capabilities?". @dlongley and I discovered that a guardians capabilities are different from proof of control and everything else in the DID. It's another capability that the DDO is listing, so I think it's premature to say that it's not a first order capability.

It's also difficult to say exactly what IS a first order capability since we're using a very extensible data model. So, we should probably address at least the following questions:

1. Exactly what set of capabilities does listing a guardian provide?
2. How should we achieve those capabilities?
3. How are we layering specifications? Could "guardian" be a layer on top of DIDs?

We should be very careful about this particular feature (guardians), because as @talltree mentioned during our face to face, this affects the very people we're trying to help with this technology - those that have found themselves in vulnerable situations (refugees, human trafficking, no identity, etc.). Of all of the issues that we have on the spec, the "guardian" one is the one we shouldn't take lightly.

[msporny]

Suggest that we attempt to close this issue at RWoT6 by stating that guardianship is accomplished via the use of Capabilities and point to how we do this via the grantCapability and invokeCapability mechanisms in the Veres One DID Method specification.

[msporny]

Feedback from RWoT6: We have agreement on a design pattern for specifying what a particular key can be used for: The cryptosuite -> public key pattern, which is used by "authentication" in the specification.

For the topic of guardianship, we have two mechanisms that we could use either:

1. a coarse grained "guardian" pattern modeled off of the cryptosuite -> public key pattern, or
2. the use of Capabilities to provide more fine-grained description of guardian capabilities and actions.

We will submit a PR that states this in the specification, and will close the issue after the PR is approved.