Re: VCs - zCaps / OCap a Discussion

Stephen Curran <swcurran@cloudcompass.ca> wrote:

While that specific use case might be a bit of an edge case, the common use
> cases we expect to see brings me to the argument as to why a VC-based
> specification of OCAPs (VC-CAPs??) would be extremely valuable:
>

Which specific use case?

>
> - the underlying flow (issuer-holder-verifier) is essentially the same for
> both.
>

I don't expect chained credentials to be the common use case for VCs, but
attenuated delegation is going to be used everywhere with ocaps.  Even with
chained credentials, I'm not sure the verification is identical to that of
delegated ocaps.


> - the need for cryptographic trust in both cases are the same (in the OCAP
> case, the need for the holder to prove a binding to the initial holder --
> as the same entity or a delegate)
>

Agreed.


>    - in saying that, I don't mean "gov't id" type identity but rather I'm
> in control of the holder's (or the holder's delegate's) private
> key/cryptographic binding material
> - the storage for the two is going to be the same -- some sort of wallet
> that the holder can use to receive, hold/protect and present
>

The storage might be the same, but the way you access them may be quite
different.


> - the protocols necessary to issue and present are if not identical,
> extremely close -- and can ideally be merged (see the next point)
>

I'm not sure.  Verifying that a delegation doesn't increase the set of
permissions is key to ocaps.  There must be something similar for chained
credentials, but I don't know if it's the same algorithm.


> - the places where the two are used are often going to be the same, often
> within the same flow. For example, at a hospital, I have a (perhaps
> delegated) capability to do something AND I have a VC that shows I'm a
> licensed medical doctor in good standing.
>

And how is the doctor's VC going to be used?  If it's to make an access
decision when the doctor makes a request, you may have a confused deputy
vulnerability.  The correct way to combine VCs and ocaps is for the doctor
to present his VC and get back a bunch of ocaps.

>
> On that last item, I'm really not going to be happy if I have to use two
> apps/devices to go through two separate flows to show I'm allowed to do
> something.
>

I have designed a UI that hid the fact that you were using one protocol
(not VCs) to request permissions and a different one to use them.

>
> I agree that a VC-CAP would need a full definition and would only be using
> the VC as a transport for the capability. But the ability to combine all of
> the elements of the user experience (wallets, storage, protocols, usage)
> seems to me to be pretty important.
>
> I agree that would be nice.  My fear is that the two use cases are just
different enough to interfere with each other, revocation being the one
that comes to mind.  Even small differences, such as validating chained
credentials vs. ocap delegation chains, can really slow down progress when
one of them wants to change.

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

>