- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Thu, 8 Nov 2018 11:37:21 -0500
- To: =Drummond Reed <drummond.reed@evernym.com>
- Cc: Brent Zundel <brent.zundel@evernym.com>, Joe Andrieu <joe@legreq.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
On 11/06/2018 12:49 AM, =Drummond Reed wrote: > First, I want to say this message from Dave is exceptionally articulate > about the relationship of Verifiable Credentials (which 90% of the time > I end out just shortening, in context, to "credentials") and "Authorized > Capabilities". > > However to agree with Daniel, just as I find that most of the time I can > leave out "verifiable" because it "comes with the territory" of digital > credentials, I think most of the time we'll be able to leave out > "authorized" because it "comes with the territory" of capabilities. > > Ironically the short-form pairing I like perhaps even more than > "credentials" and "capabilities" is "dcreds" and "dcaps". And that > certainly reinforces the decentralized aspects of both. Another option for renaming Object Capabilities is Decentralized Capabilities. Decentralized Capabilities enable an authorization framework where delegation can happen in a decentralized way, where a single centralized namespace for resources is not required, and where centralized ACL management is not required. This would get us to a "dcaps" short-form as well. > > On Mon, Nov 5, 2018 at 12:24 PM, Dave Longley > <dlongley@digitalbazaar.com <mailto:dlongley@digitalbazaar.com>> wrote: > > On 11/05/2018 02:54 PM, Brent Zundel wrote: > > > > On Mon, Nov 5, 2018, 11:40 Joe Andrieu <joe@legreq.com > <mailto:joe@legreq.com> <mailto:joe@legreq.com > <mailto:joe@legreq.com>> wrote: > > __ > Adam, > > I agree. I think we're on the same page: the authorization > happens > at the issuance of the capability (ignoring any separation of > creation & transmittal). Hence, my preference for the past > participle "authorized". The semantics are that if you have the > auth* capability, you can exercise the capability because the > capability *has* been authorized. > > > This does not fit with my understanding of how the ecosystem > could work. I might receive a credential from an issuer, but > authorization couldn't happen until the presentation of that > credential is verified. > So authorization happens at verification. > > > This discussion is about capabilities, not credentials. I think it's > important that we don't mix the two (some others disagree). > > Verifiable Credentials are about describing things. Verifiable > Credentials allow you to say things about others in a way they can > independently share whilst preserving the trust that you said it. This > tech can be used as part of an authorization framework, but it does not > constitute one on its own. > > Authorized Capabilities are directly about authorization. They allow you > to delegate authorization to take some action with some resource to > others such that they can also independently delegate it (with > restrictions). An Authorized Capability must be cryptographically > invoked (and/or delegated). Invocation may require some additional > caveats, such as the possession of certain attributes by the invoker. > > This is one way that the two technologies can be used together: a > Verifiable Credential can provide a trusted claim that an entity > possesses the required attributes to invoke an Authorized Capability. > > > > > Flip it around and it might be clearer. To my reading, an > "unauthorized capability" would be like stolen car keys. > You have > the capability, but you aren't authorized. In contrast, an > "unauthorization capability" reads to me that you have the > capability to remove authorization, to unauthorize something. > > The past participle, "authorized" reads as modifying > capability, > whereas the little known FCE nounification [1] of > "authorize" into > "authorization" reads as the capability to do the verb > "authorize" > > To add another coat of paint to the zCap thing. Since zkp > seems to > have run away with the zzzzs, ACap might work well with > either Auth* > Capability. > > -j > > [1] > http://www.tinyteflteacher.co.uk/learning-english/FCE/word-formation-ion-nouns.html > <http://www.tinyteflteacher.co.uk/learning-english/FCE/word-formation-ion-nouns.html> FWIW, > I knew all about gerunds "-ing" noun forms. I didn't know > about FCE > until Google enlightened me. > > On Mon, Nov 5, 2018, at 9:47 AM, Adam Lake wrote: > > > Joe, > > I think I get your point but don't the capabilities > exist prior to > be used? That is, they are Authorization Capabilities > until they > are used to delegate, or authorize, a capability? > > I agree that Authorized Capabilities flows off the > tongue a bit > easier than Authorization Capabilities. > > Adam > > > On 11/3/2018 2:10 PM, Joe Andrieu wrote: > > +1/2 > > I like changing it, but I would suggest Authorized > Capabilities. > > First, it's easier to say. > > Second, it states the actual function more clearly: > if you have > an authorized capability, you're authorized. If you > have a zCap, > you're authorized. Or, in the inevitable > vernacular, if you have > a capability, you're authorized. > > "Authorization Capability" reads to me as if the > holder has the > capability to authorize--which is only true if its > delegatable > and not true in the generalized case. > > Bikeshed on... > > -j > > > On Sat, Nov 3, 2018, at 9:40 AM, Darrell O'Donnell > wrote: > > +1 > > > *Darrell O'Donnell, P.Eng.* > > darrell.odonnell@continuumloop.com > <mailto:darrell.odonnell@continuumloop.com> > <mailto:darrell.odonnell@continuumloop.com > <mailto:darrell.odonnell@continuumloop.com>> > > > > > > On Sat, Nov 3, 2018 at 12:24 PM Brent Zundel > <brent.zundel@evernym.com > <mailto:brent.zundel@evernym.com> > <mailto:brent.zundel@evernym.com > <mailto:brent.zundel@evernym.com>>> wrote: > > +1 > > On Sat, Nov 3, 2018, 10:14 Jordan, John CITZ:EX > <John.Jordan@gov.bc.ca > <mailto:John.Jordan@gov.bc.ca> > <mailto:John.Jordan@gov.bc.ca > <mailto:John.Jordan@gov.bc.ca>> wrote: > > +1 > > > On Nov 3, 2018, at 08:27, Manu Sporny > <msporny@digitalbazaar..com > <mailto:msporny@digitalbazaar.com > <mailto:msporny@digitalbazaar.com>>> wrote: > > > > Hi all, > > > > This is related to the OCAP-LD spec > that some of us > are working on in > > this community: > > > > https://w3c-ccg.github.io/ocap-ld/ > <https://w3c-ccg.github.io/ocap-ld/> > > > > Digital Bazaar's engagement with > customers over the > past several months > > wrt. the term "Object Capabilities" > has resulted in > confusion around > > exactly what an Object Capability is. > > > > Some history -- the "Object > Capabilities" name was > originally picked to > > differentiate from the "Linux > Capabilities" stuff, > which really didn't > > have much to do with capabilities (in the > authorization sense). Object > > Capabilities makes more sense when > you're talking > about programming > > languages, but we don't really use it > in that sense in > this community. > > > > I propose we name the specification > more appropriately > in the hope that > > the name evokes what we're actually > doing with the > specification. The > > technology we're developing in this > community > specifically has to do > > with Authorization... > capability-based authorization. > Thus, I'm > > suggesting the spec is renamed to > "Authorization > Capabilities"... > > shortened to "zCaps" for the cool > kids in the community. > > > > Also, this is a bike shed discussion, > so I fully > expect it to get out of > > hand and for us to have to do a poll > like we did for > the Verifiable > > Credentials terminology. Please only > suggest names > that you're committed > > to using with your customers (or that > you would use > with non-technical > > folks). If we get a bunch of +1s with > no strong > objections, we're > > done... and yes, I know that's > wishful thinking. :) > > > > -- manu > > > > -- > > Manu Sporny (skype: msporny, twitter: > manusporny, G+: > +Manu Sporny) > > Founder/CEO - Digital Bazaar, Inc. > > blog: Veres One Decentralized > Identifier Blockchain > Launches > > > https://tinyurl.com/veres-one-launches > <https://tinyurl.com/veres-one-launches> > > > > > -- > Joe Andrieu, PMP joe@legreq.com > <mailto:joe@legreq.com> <mailto:joe@legreq.com > <mailto:joe@legreq.com>> > LEGENDARY REQUIREMENTS > +1(805)705-8651 > Do what matters. http://legreq.com > <http://www.legendaryrequirements.com > <http://www.legendaryrequirements.com>> > > > > -- Adam Lake > Director, Business Development > Digital Bazaar > Veres.io > 540-285-0083 > > > -- > Joe Andrieu, PMP joe@legreq.com <mailto:joe@legreq.com> > <mailto:joe@legreq.com <mailto:joe@legreq.com>> > LEGENDARY REQUIREMENTS > +1(805)705-8651 > Do what matters. http://legreq.com > <http://www.legendaryrequirements.com > <http://www.legendaryrequirements.com>> > > > > > -- > Dave Longley > CTO > Digital Bazaar, Inc. > http://digitalbazaar.com > > -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Thursday, 8 November 2018 16:38:00 UTC