search

openssi / peer-did-method-spec

A spec for the did:peer DID method.
https://dhh1128.github.io/peer-did-method-spec/index.html
Apache License 2.0
30 stars 17 forks source link

get alignment on authorization section #105

Closed dhh1128 closed 4 years ago

dhh1128 commented 5 years ago

This issue tracks a deep discussion that first began on email.

Here's a link to the email thread: https://groups.google.com/forum/#!topic/peer-dids/mYmoXfI7be0

The goal of this issue is to get to alignment around requirements, the reasons for those requirements, and a good way to implement them.

@Oskar-van-Deventer @swcurran

dhh1128 commented 5 years ago

@Oskar-van-Deventer began to try to tease out requirements in our email thread. I am reluctant to get overly detailed (that is, start by attempting to collect an exhaustive set of use cases, and to derive all requirements from them). My reasoning for not starting there is that it is expensive, and I am hoping we can get to consensus by starting at a higher level. However, if my hope proves to be in vain, then I am willing to start at a lower level. Let's see if it's necessary.

Here is my attempt to summarize my takeaways for our DID method, from the DKMS (distributed key management system) research that I cited in email (see Aries RFC 0051):

  1. Our DID method should allow an identity owner to have multiple keys.
  2. Our DID method should allow an identity owner to trust some keys more, and some keys less.
  3. Our DID method should allow an identity owner to restrict some authorizations to groups of keys rather than to individual keys.

I think most of the other stuff that we've touched on or might touch on in this thread derives from these 3 assertions. So I'd like to see how much controversy we have about them, before we get more specific.

Please note that all three of these assertions use the word "allow", not the word "require." That's on purpose.

I'm guessing that #1 is not controversial. Am I right?

Based on some earlier comments, I'm guessing that #2 might be harder to align on. Am I right that some of you don't feel in harmony with that one?

Item #3 is a requirement for multisig. I am guessing that in the abstract, people don't disagree with it--but they might have reservations about the way I proposed to address it.

Can you please comment on your feelings about each of these, so we know how deep to go and where to focus?

dhh1128 commented 5 years ago

@swcurran, In the email thread that preceded this issue, you mentioned a concern that you felt like we were asking a remote party to do too much enforcement. Can you comment on whether you feel aligned with this section of the spec? https://openssi.github.io/peer-did-method-spec/#enforcement

swcurran commented 5 years ago

I agree that the second item from your list above is the crux of the issue. Do we need finer-grained capabilities associated with keys or is a key or set of keys (including multi-sig) sufficient to say you have "update" as an implied capability? I think your first and third items are necessary.

Regards enforcement - yes, I'm aligned with that section. My comment comes back to the need for capabilities beyond the implied "update" - having an enumerated list and enforcing the meaning of the elements of that list.

dhh1128 commented 5 years ago

Thanks, Stephen. That's very clear and will let us focus on just one subtopic.

Let's see what other people say.

OR13 commented 4 years ago

authorization is similar to capabilityInvocation in that both seems to be about how keys are used... my first reading of the section made me feel a bit uneasy, If the did document is public, I don't like seeing so much information in the did document, but peer did documents are not exactly public....

Also while I love the idea of SGL, and have used similar things like: https://www.npmjs.com/package/accesscontrol

I feel that this authorization section is a category above what a did document traditionally handles, and pulls did:peer towards a more assumed private world view, which puts it in a special category of DID Methods.

I have a couple questions:

  1. Is authorization required to be a valid did:peer?
  2. Is it possible to put authorization behind a service endpoint, and use authentication to expose it at the application layer instead of the PKI layer?
dhh1128 commented 4 years ago

Closing now that this issue is moved to its new home at https://github.com/decentralized-identity/peer-did-method-spec/issues/11.