Re: VCs - zCaps / OCap a Discussion

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


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

I don't think I said that credentials implied anything about identity.
It's the VC use cases and examples that I frequently see that are mostly
about identity.

Most people I've worked with who are just learning about ocaps want to
include some form of identity, role, or attribute authentication.  I'm
afraid that all those identity-based VC examples will lead them down the
wrong path.

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

Yes, you did show that.  The problem is that a lot of other fields could be
included in a zcap when they shouldn't be, and I'm afraid less
knowledgeable people will include them.  I would feel much better about
using VCs for zcaps if the spec limited which fields are allowed in a zcap.

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

Just because you can, doesn't mean you should.  There are only two parts to
an ocap, the thing (noun) and the permissions (verbs).  Forcing them into a
triple may confuse people.

I have one other concern about using VCs for zcaps.  How do you do chained,
subscope delegation?

--------------
Alan Karp

>