- From: =Drummond Reed <drummond.reed@evernym.com>
- Date: Thu, 8 Nov 2018 10:21:56 -0700
- To: Dave Longley <dlongley@digitalbazaar.com>
- Cc: Brent Zundel <brent.zundel@evernym.com>, Joe Andrieu <joe@legreq.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
- Message-ID: <CAAjunnamSSBpsWpq+a52aijHjY7k6dkZNumkm1aVgb=xnS5OOg@mail.gmail.com>
+1. On Thu, Nov 8, 2018 at 9:37 AM, Dave Longley <dlongley@digitalbazaar.com> wrote: > 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-f >> ormation-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 17:22:22 UTC