Re: VCs - zCaps / OCap a Discussion

... so is it fair to say that we've had a fun conversation with 64 posts to
arrive at the conclusion that we still have to pick an authorization
protocol?

- Adrian

On Sat, Dec 19, 2020 at 6:39 PM Orie Steele <orie@transmute.industries>
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/
>
> 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>
>