Re: VCs - zCaps / OCap a Discussion

Alan:

Thank you for the thoughtful answers. I feel like I understand your concern
a bit better; it seems that you're worried about VC-based OCAPs having
extra fields (an anti-pattern), and about the oddness of fitting 2 fields
into 3, because misunderstandings will ensue. Did I summarize you
accurately?

I think those are reasonable concerns. To me, a good way to solve them
would be to publish a paragraph that says something like this:

An OCAP is a bearer credential that includes "https://*somewhere.com
<http://somewhere.com>*/ocap-context.jsonld" in its @context array, that
declares one value of its type property to be "OCAP", and that has a
single, simple credentialSubject block that looks like this: {"id": "
*url_identifying_the_resource*", "ocap": ["*privilege_name*"]}. This
announces to the world that the bearer of the credential is authorized to
access the specified resource with the specified privilege name(s).
Privilege names should be defined in an additional JSON-LD @context to
clarify their semantics.


That's almost it. We still need some cautionary language, and we need to
answer your question about delegation. That would require an additional
paragraph:

There is one optional, extra attribute (embodying a second possible RDF
triple) in the OCAP's credentialSubject block: provenanceProof. If this
field is present, its value is an embedded verifiable presentation of
another OCAP that shows how the issuer received authority sufficient to
grant the privileges it is extending. This can be used to create delegation
chains. Although VCs in general are extensible, adding additional fields or
credentialSubjects to an OCAP VC is strongly discouraged, as this
undermines the pure authorization semantics that are a defining
characteristic of OCAPs.


And that's about all. I've essentially written an entire OCAP spec in two
paragraphs. There's more that could be said -- examples, implementation
guidance, more about the theory of OCAPs -- but the core is just that much.
In this approach, OCAPs become verifiable by any stack that can verify VCs,
as just a credential type with some constraints. They have all the same
signature suites, serialization formats, revocation mechanisms, governance,
tribal knowledge, documentation, PR gravitas, and community implementations
that VCs do. They don't need a separate spec or separate libraries, and the
interop task is minor high-level details, not foundation-level tech.

I believe Orie embodied thinking like this in the OCAPs-as-VCs repo that he
hyperlinked. I had a similar idea. I wrote a doc that describes this
mechanism (Aries RFC 0104: Chained Credentials
<https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0104-chained-credentials/README.md>),
and spoke about it at IIW. IIRC you attended the session and gave some
really helpful guidance; I rolled some of it into an update to the doc. Now
Sam Smith is proposing to generalize the idea of provenanceProof to other
problems, allowing an issuer to cite sources for any data (not just authZ
data) they put in a VC ("Here's the name and address of the
credentialSubject, and here's a provenance proof that shows where I got
that info, so you can believe the origin issuer instead of me, the
proximate issuer.") This has applications in supply chain, guardianship,
and organizational behavior, not just OCAPs. It can also shrink the number
of parties that must be trusted in an ecosystem (a crucial goal that we're
undervaluing throughout the VC ecosystem), since a valid chain can have any
number of unknown intermediaries, as long as its root is known.

What started this whole conversation is that Kaliya asked Sam and me to
talk to zCaps proponents because she correctly noted an overlap in the
problem we're going after. It is true that we are intending to represent
OCAPs as VCs and that this overlaps with the problem domain of zCaps -- but
we are also wanting to solve that other data provenance problem, too. And
the reason I'm not liking the "give OCAPs a separate spec of their own"
answer is that every variation of VC use cases we dream up is going to
trigger the same tension. Should VCs be used to give legal testimony -- or
should we invent and standardize a new spec for doing that, even though it
essentially recapitulates the full content of the VC spec? How about
tracking chain of custody in supply chain? How about VCs for voting? Etc.
Etc.

Now, I know that you, personally, did not argue that VCs were purely
identity oriented. If I've summarized your concerns well, you've just had
worries about the narrow case of OCAPs being solved with a broad tool like
OCAPs. But your argument has something in common with the "VCs are only for
identity" argument: both advocate narrow solutions. I get the wisdom of
narrowness. But I don't think it's the optimal tradeoff in this case.
Getting the world to adopt decentralized identity is already a huge shift.
VCs add another crucial, high-stakes standards-and-interop battle that we
must fight. The DID spec is another. And then there are battles about DID
methods, blockchain interop, governance, etc. We can only afford to fight
so many battles like this, in a given timeframe. When you have a lot of
breadth but you target narrow standards, that means you have to have a
*lot* of standards. This isn't the right strategy, IMO, when a space is
young. Young spaces should have a few broadly applicable standards. Then,
years later, when group wisdom and battle scars have accumulated, you
produce specialized standards for particular problem domains, when you're
confident that the narrowness is justified by the extra precision. That's
why I'm not a zCaps supporter; they specialize too early.


On Wed, Dec 23, 2020 at 4:59 PM Alan Karp <alanhkarp@gmail.com> wrote:

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