- From: Dave Longley <dlongley@digitalbazaar.com>
- Date: Mon, 5 Nov 2018 15:24:23 -0500
- To: Brent Zundel <brent.zundel@evernym.com>, Joe Andrieu <joe@legreq.com>
- Cc: "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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> 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 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> >>>> >>>> >>>> >>>> >>>> >>>> On Sat, Nov 3, 2018 at 12:24 PM Brent Zundel >>>> <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> wrote: >>>> >>>> +1 >>>> >>>> > On Nov 3, 2018, at 08:27, Manu Sporny >>>> <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/ >>>> > >>>> > 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 >>>> > >>>> >>> >>> -- >>> Joe Andrieu, PMP joe@legreq.com <mailto:joe@legreq.com> >>> LEGENDARY REQUIREMENTS +1(805)705-8651 >>> Do what matters. http://legreq.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> > LEGENDARY REQUIREMENTS > +1(805)705-8651 > Do what matters. http://legreq.com > <http://www.legendaryrequirements.com> > > -- Dave Longley CTO Digital Bazaar, Inc. http://digitalbazaar.com
Received on Monday, 5 November 2018 20:24:50 UTC