Re: VCs - zCaps / OCap a Discussion

I've gone quiet on this thread for a while, trying to learn from Adrian and
Alan. Thank you both for patiently exploring.

I'd like to bend this back to the central question:

>Is it wise to build a new standard for OCAPs, separate from the one for
VCs?


It seems to me that the arguments I've heard, claiming that the answer is
"yes", boil down to this assertion:

>Although the VC spec allows RDF triples that express authorizations, this
is a divergence from the original intent. VCs are fundamentally supposed to
be about identification, not authorization. If you want to make statements
that are verifiable but not about identification, drop back to the more
primitive layer, LD Signatures, and build a new standard atop that.


@Tobias, @Dave, et al: is this a reasonable characterization of your
thinking?

I reject this reasoning, but I could buy a slight tweak to it. Let me
explain the issue I have, and then how a tweak might feel better.

Statements about a divergence from original intent are statements rooted in
tribal knowledge, not standardized language. They presuppose that there's
one tribe whose knowledge of the standard is better than some other
tribe's. But if standards alignment means anything, it means alignment to
the words in the spec itself. Those words--not unpublished, unstandardized
intent--are what we agreed to. Such words represent a lot of compromises;
all of us made them believing that they would bind other people just as
much as they bound us. I feel like I have been skewered (unfairly) by
members of the CCG for lack of compliance to standards; I'm certainly not
going to sign up for compliance to somebody else's preferred tribal
knowledge about the "true" meaning of a standard.

To be clear, I'm not down on tribal knowledge. It's important. I'm not even
down on using it to interpret an important spec of some kind. I'm just down
on claiming it should change how we read something that actually was
published as a formal standard. Essentially, I'm making the same argument
here that Manu made once, when asked why he didn't want a reference
implementation of a standard: only the words of a standard are a standard;
everything else has to be non-normative.

However, I do agree that specs have comfortable and awkward use cases, so a
variation on this argument that could resonate more for me is:

>Although the VC spec allows RDF triples that express authorization, this
is a not a great use of the mechanism, because... ___.


The type of item that would fill in the blank in a satisfying way for me
would be something like "VCs are way more heavyweight than the standard
we'd have to create for OCAPs." Or, "VCs have a whole bunch of required
features that OCAPs don't need." Or "Authorization is not fundamentally a
subject+predicate+object triple." Etc. I don't feel like I've heard any
example of one of these statements that stands up under scrutiny, though.
Did I miss one? I heard some candidates, but when I gave counter examples,
nobody engaged. Let me repeat them.

1. I claim that the following is two classic RDF triples, where each is a
statement about a subject, AND exactly fits the credentialSubject portion
of a VC -- yet it doesn't establish identity at all. It's fodder for a VC
that gives testimony in court case, and 100% compatible with the VC spec
language:

subject: purported accident outside Acme's headquarters
predicate: what I saw
object: Malfoy entered the intersection after the light turned yellow. He
clipped Bob, whose car spun around and collided with Carol...
predicate: what I heard
object: Malfoy's brakes squealed before any other unusual sounds occurred.

2. I claim that the following is a classic RDF triple, AND exactly fits the
claim structure in a credentialSubject portion of a VC, AND is an
authorization statement appropriate for an OCAP:

subject: Alice's capstone robot project
predicate: is hereby made accessible with privilege
object: activate "self defense" mode


I know example 2 fields surprising. I get that. But "surprising" doesn't
mean "a bad idea," and it doesn't mean "out of harmony with the standard."
So that's what I'm wrestling with.

We tend to imagine that the subject in a VC is a person, not a resource for
which authorization is of interest. After all, we spend all our time
talking about credential subjects like Alice the passport holder and Bob
the vaccinated citizen. Yet we know that subjects can be institutions or
things, and that the holder doesn't have to be the subject. The spec is
explicit about that, agreed?

We tend to imagine that the predicate creates a descriptive association
between the subject and the object. Attributes of the subject, right? But
isn't "is hereby made accessible with privilege" a descriptive association
-- an attribute of the subject, which is a resource in this case? Sure, we
don't have an easy verb for this predicate in English -- but there's no
easy word in English for the Czech prozvonit "prozvonit" either (dial a
person and then hang up as soon as they answer, so neither of you incurs
phone charges). That doesn't mean the Czech word is weird.

Re. the architectural intuition that interpreting the spec broadly enough
to frame an OCAP as a VC will introduce problems/tensions we won't like:
this may be true. But I have two observations about it:

1. For me, and probably others that don't share the tribal knowledge I
alluded to above, this is not a question about "broadening our
interpretation" of what a VC is. I've always had this broad of an
interpretation. A VC is a collection of claims by an issuer about a
subject. Yes, it's useful in identity -- but it's by no means limited to
identity. And its foundational standard of LD Signatures is only
foundational if you live in the Linked Data universe; so advising me to
drop back to a lower level standard doesn't resonate. I've been exploring a
mental landscape from this perspective for several years, and so far I
don't see big gotchas. Maybe they exist, but I'm dubious without concrete
examples.

2. I'm worried about a different architectural gotcha, which is the
creation of multiple specs to solve problems that overlap to a high degree.
Each standard we write isn't just more effort to forge consensus and
implement something that's aligned; it's also a reset calendar, plus a
separate group of stakeholders who may drive in a different direction. The
way to get a core of interop isn't to create lots of new standards that
fragment the space; it's to double down on a few that are already common.



On Wed, Dec 16, 2020 at 12:29 PM Adrian Gropper <agropper@healthurl.com>
wrote:

> I have no idea what
>
> “ The PEP may know that the token is valid, perhaps because it has cached
> the validation result, but it doesn't know if the request is included in
> the permissions specified in the token.”
>
> means. I try to use ‘request’ consistently to refer to interaction at the
> PDP. I use ‘token’ in relation to the capability presented by a ‘client’ to
> Company A as the PEP.
>
> - Adrian
>
>
> On Wed, Dec 16, 2020 at 1:07 PM Alan Karp <alanhkarp@gmail.com> wrote:
>
>> Adrian Gropper <agropper@healthurl.com> wrote:
>>
>>> *just sent to me, so replying in private...*
>>>
>>
>> Aaarrrggghhh!!! I hereby give you permission to forward my response to
>> the group if (when) I to this again.
>>
>>>
>>>
>>> On Sun, Dec 13, 2020 at 6:53 PM Alan Karp <alanhkarp@gmail.com> wrote:
>>>
>>>> Adrian Gropper <agropper@healthurl.com> wrote:
>>>>
>>>>>
>>>>> Even if you know the capability has been validated, you still have to
>>>> verify that the request is consistent with it.  What if you asked to write
>>>> with a read-only capability?
>>>>
>>>
>>> *I'm really confused by this. A token presented to the PEP can either be
>>> self-authenticating (like a VC signed by a key that was pre-registered by
>>> the PDP that represents the resource owner). The other alternative is that
>>> the token presented to the PEP is an opaque handle that is presented by the
>>> PEP to a pre-registered PDP. The PDP returns a scope of access. How else
>>> can this work?*
>>>
>>
>> The request presented to the PEP consists of two pieces, the access token
>> and the request you are making of the service.  This combination is signed
>> by the private key corresponding to the public key in the access token.
>> The PEP may know that the token is valid, perhaps because it has cached the
>> validation result, but it doesn't know if the request is included in the
>> permissions specified in the token.
>>
>>>
>>>> One of the nice things is the privacy ocaps can provide.  You may need
>>>> some personal information to decide to grant a capability, but the
>>>> capability need not contain any of it.
>>>>
>>>
>>> *Exactly. That's why I'm a fan of ocaps. We seem to be having trouble
>>> linking them to the real-world use case of health information access and
>>> DIDs. *
>>>
>>
>> Let's work through a use case
>>
>>>
>>>> There must be a disconnect.   You invoke a service to read a particular
>>>> file.  Clearly, the service needs to see that, what I'm calling the API
>>>> part of the request.
>>>>
>>>
>>> *Me too. But the API is only one _part_  of the request. The other two
>>> are requesting party credentials and the purpose of the request. These
>>> other two parts should not be shared with the service (Company A).*
>>>
>>
>> I agree.  The nice thing about ocaps is that Company A can validate the
>> request while learning nothing about the requester.
>>
>> --------------
>> Alan Karp
>>
>>>