Re: VCs - zCaps / OCap a Discussion

Hi Orie

I support your general approach outlined in your strawman. It pretty 
much matches my ideas for VC capabilities. Proof of the key in the 
subject id proves you are the rightful possessor of the capability.

It also supports bearer capabilities by simply removing the subject id. 
In this case delegation is not required (or meaningful) as anyone who 
possesses the VC possesses the capability. And this is surely the 
meaning of a bearer credential. You do not have to prove ownership since 
you are bearing it. Bearer credentials by their very nature can be 
stolen or passed from holder to holder.

Happy Christmas

David

On 19/12/2020 23:38, Orie Steele wrote:
> I made some updates to this strawman proposal for using the VC Data 
> Model to describe capabilities, capabilities chains, delegation and 
> invocation:
>
> https://transmute-industries.github.io/authorization-credentials/ 
> <https://transmute-industries.github.io/authorization-credentials/>
>
> There are tests, covering some basics of verification of both 
> capabilities and invocation.
>
> There is really nothing original in this approach, its simply applying 
> the W3C VC Data Model to the ZCAP-LD spec here: 
> https://github.com/w3c-ccg/zcap-ld <https://github.com/w3c-ccg/zcap-ld>
>
> I am assuming that 0 changes to the VC Data Model will be allowed, and 
> that the specific JSON data model for expressing capabilities may vary 
> from domain to domain... I chose to try and combine some of the GNAP 
> structured scopes stuff just to make everyone even more frustrated :)
>
> I've had hallway conversations about this work in a number of places, 
> and most of what I have to say on the subject has already been said on 
> this thread, but I want to echo what Daniel Hardman said regarding 
> "identity"..... I see the relevant parts of VC Data Model as being 
> about identifiers, semantically unambious expression of complexity (as 
> it related to permissions / trust) and cryptographic protection 
> mechanisms for those assertion formats.
>
> VCs are not about "Identity" any more than ECDSA is about identity... 
> how a capability is expressed, and how it is authenticated / protected 
> are natural fit for the "credentialSubject" and "proof" section of 
> VCs.... but I could say the same thing of the "payload" and "header / 
> signature" sections of https://tools.ietf.org/html/rfc7515 
> <https://tools.ietf.org/html/rfc7515>
>
> ... so what's the real problem with authorization?
>
> It's not "identities" or "proof formats".... its "scopes".... If you 
> have spent any amount of time in enterprise api configuration hell, 
> you probably are aware of all the different ways that companies have 
> found to map strings to capabilities (being the bearer of a token with 
> the proper scopes)...
>
> For example, google as some nice URIs:
>
> https://www.googleapis.com/auth/admin.directory.user 
> <https://www.googleapis.com/auth/admin.directory.user> (great 
> documentation available at this link)
>
> https://developers.facebook.com/docs/permissions/reference/ 
> <https://developers.facebook.com/docs/permissions/reference/> 
> (facebook will need to review your app to make sure you care as much 
> about user privacy as they do)
>
> Microsoft, Apple, Amazon... all the big tech companies that we use for 
> our personal data, and our corporate data all have their own way of 
> expressing this information...
>
> There was a time, when you had to buy a different floppy disk / drive 
> and use different software in order to move your data around on the 
> first PCs... that's where we are in "enterprise api integration land" 
> today... The only point of commonality is OAuth 2.0 (HTTPS / JWT)... 
> it's like saying we have interop because we agreed to use binary 
> computers.... (don't get me wrong, we need at least one way to 
> communicate, and until something can actually beat OAuth in a fair 
> fight... it's all we have).
>
> The thing that excites me the most about a cryptographically secure 
> semantic capabilities future is the hope that one day a human will be 
> able to understand what systems access their data, and will be able to 
> change those policies in ways that make sense to both humans and 
> machines, without reading OAuth Scope documentation for 3 weeks.
>
> The semantic side of the VC Data Model seems unreasonably heavy until 
> you consider the alternative, and then it seems like a reasonable 
> upfront investment to avoid a problem of unbounded economically 
> incentivised complexity.
>
> OS
>
>
>
> On Sat, Dec 19, 2020 at 3:40 PM Daniel Hardman 
> <daniel.hardman@evernym.com <mailto:daniel.hardman@evernym.com>> wrote:
>
>     Alan said:
>
>     >Let me start by saying I would love to use VCs for authorization,
>     but I'm afraid the use cases are just too different.
>
>     Here is the definition of "credentials" as a noun, from Meriam
>     Webster <https://www.merriam-webster.com/dictionary/credential>:
>     "testimonials or certified documents showing that a person is
>     entitled to credit or has a right to exercise official power."
>     It's pretty hard for me to see how, under that definition,
>     credentials are not related to authorization. For me, it also
>     undercuts the assertion that credentials are all about identity. I
>     would say, rather, that they're all about trust in the word of an
>     issuer (about any topic, for any use case). This is especially
>     true when the spec already has a whole section about bearer
>     credentials, which by definition can't establish identity.
>
>         All of the above.  I think a comparison of the VC and zcap-ld
>         specs answers the first and second points.  The recent
>         discussion about VP and VR is a hint that the VC spec may
>         become even more heavyweight than it is now.
>
>
>     The VC spec is not in flux. I don't see how it can get heavier
>     unless a new version is released. And I thought my examples showed
>     how it can be used in a way that's just as lightweight as zCAP
>     proposes to make an alternative mechanism.
>
>                 First, an ocap is not a triple.  An ocap is an
>                 unforgeable, transferable permission to use the thing
>                 it designates.  To me that looks like predicate/object
>                 with no subject.  (I guess you could call it
>                 subject/predicate with no object if you prefer.) 
>                 Using a verb "activate" in place of an noun "object"
>                 is strange indeed.  More importantly, I'm afraid
>                 people will create ocaps like
>
>
>     The question isn't about the definition of an OCAP (I agree with
>     yours). The question is whether the semantic content of an OCAP
>     can be represented with a triple. I say yes. Sorry my example was
>     confusing. The object in the sample triple was not the verb
>     "activate" -- it was a privilege (a noun) named "activate
>     self-defense mode". If I use a different privilege name (e.g.,
>     "maintenance" -- the bearer has a maintenance privilege), does
>     that make it clearer? I am saying that the subject of an
>     authorization triple is the resource, the object is the privilege,
>     and the predicate is the association that obtains between the two,
>     for whoever the bearer happens to be.
>
>     Alan said:
>
>     > So, instead of a separate standard, is it possible to define two
>     types
>     > of VC, claim and authorization?  If a given certificate can be
>     one or
>     > the other, then perhaps the spec can limit which fields may be used
>     > for each type.  That approach should keep the bulk of the framework
>     > the same.
>
>     And David Chadwick responded:
>     >This is a very sensible suggestion. There is already the type
>     field that
>     >is used to describe what type of VC this is. I (and I think Daniel as
>     >well) suggest that the schemas of the subject properties will further
>     >determine the meanings of the properties and thus imply the use
>     of the
>     >VC. The "name" property implies ABAC whilst the "read" property
>     implies
>     >a permission.
>
>     I just wanted to +1 David's answer.
>
>
>
> -- 
> *ORIE STEELE*
> Chief Technical Officer
> www.transmute.industries
>
> <https://www.transmute.industries>

Received on Thursday, 24 December 2020 18:47:49 UTC