Re: VCs - zCaps / OCap a Discussion

Daniel Hardman <daniel.hardman@evernym.com> wrote:

Let me start by saying I would love to use VCs for authorization, but I'm
afraid the use cases are just too different.

>
> However, I do agree that specs have comfortable and awkward use cases, so
> a variation on this argument that could resonate more for me is:
>
> >Although the VC spec allows RDF triples that express authorization, this
> is a not a great use of the mechanism, because... ___.
>
>
> The type of item that would fill in the blank in a satisfying way for me
> would be something like "VCs are way more heavyweight than the standard
> we'd have to create for OCAPs." Or, "VCs have a whole bunch of required
> features that OCAPs don't need." Or "Authorization is not fundamentally a
> subject+predicate+object triple." Etc. I don't feel like I've heard any
> example of one of these statements that stands up under scrutiny, though.
> Did I miss one? I heard some candidates, but when I gave counter examples,
> nobody engaged. Let me repeat them.
>

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.

>
> 2. I claim that the following is a classic RDF triple, AND exactly fits
> the claim structure in a credentialSubject portion of a VC, AND is an
> authorization statement appropriate for an OCAP:
>
> subject: Alice's capstone robot project
> predicate: is hereby made accessible with privilege
> object: activate "self defense" mode
>
>
> 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

       subject: Bob
       predicate: may activate any mode
       object: Alice's capstone robot  (Note the designation of a specific
object unlike in your example.)

and use the subject as part of making the access decision.

Other things that worry me about combining the specs are sub-scope
delegation chains and revocation.  Revocation in particular is implemented
quite differently for claim-type VC and for ocaps.  Then there's the fact
that the meaning of some of the fields is quite different, as in your robot
example, which can lead to confusion.

All that being said, I recognize that a lot of the mechanics are the same
for both use cases.  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.

>
--------------
Alan Karp

>