W3C home > Mailing lists > Public > public-credentials@w3.org > December 2020

Re: VCs - zCaps / OCap a Discussion

From: Daniel Hardman <daniel.hardman@evernym.com>
Date: Sat, 19 Dec 2020 14:38:22 -0700
Message-ID: <CAFBYrUphicUk9Fup9HqOYe9Qt7qxWq_eBVmRij2MqeEcnUd+RQ@mail.gmail.com>
To: Alan Karp <alanhkarp@gmail.com>
Cc: Adrian Gropper <agropper@healthurl.com>, "W3C Credentials CG (Public List)" <public-credentials@w3.org>
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

> 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

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.

Received on Saturday, 19 December 2020 21:38:48 UTC

This archive was generated by hypermail 2.4.0 : Saturday, 19 December 2020 21:38:52 UTC