Re: VCs - zCaps / OCap a Discussion

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/

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

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

... 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 (great documentation
available at this link)

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>
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>