Re: VCs - zCaps / OCap a Discussion

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

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

Yes, but you've worded them better than I did.

>
> 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.
>
>
I like it.  I think the privilege names can come from the resource API.

I don't know if "bearer" is the right term.  What you call "bearer" is
really the holder of the private key corresponding to the public key the
ocap was issued to.

>
> 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.
>
>
If that language is normative, and a VC ocap with extra fields fails to
verify, then sign me up.

One other thing is to make sure that the ocap and the resource invocation
be signed as a unit.  (The Navy's first implementation based on our Zebra
Copy work signed them separately.)

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

My other concern was that conflicts will arise as the standard evolves.
You've convinced me that won't be a problem.

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

>