Re: VCs - zCaps / OCap a Discussion

Thanks for sharing this Kaliya - it's an interesting discussion.

The arguments bring me to a question that I'd like to understand from the
OCAPS perspective.  My question is rooted in Dave/Manu's assertion that the
difference is not between VCs and ZCAPS-LD, but between VCs and LD
Signatures. Here is where I struggle with that. The difference between VCs
and LD Signatures is the holder/subject. AFAIK, an LD Signature is an
assertion verifiably associated with its issuer. A VC is a comparable
verifiable assertion from an issuer, but one that is verifiably given
to/about someone else -- the holder/subject.  Those are
quite different, and lead to my question:

For OCAPS, is a simple assertion sufficient to convey the capability for a
functioning system, or does it matter to whom the capability was given?
I've always assumed that it is important that a capability being used is
done so by the party to whom the capability was given, or there is a chain
from a delegate to the initial receiving party.


If it is not important, then it seems to me that making OCAPS a form of VCs
gets us little.  If it is, then it seems to me that any OCAPS system is by
definition going to recreate much of what is accomplished with VCs.

As Dave and Manu point out, for OCAPS to work, whether within VCs or as a
separate thing, it must be spec'd and agreed to. I read through the
ZCAPS-LD and I confess that it does not seem complete to me -- I came away
with little sense of how they would be used in systems.

I also agree with the original premise that Sam and Daniel have referenced
about the potential value of chained credentials outside of their use in
OCAPS. And I think that too requires a spec of how that would be done.


On Sun, Dec 6, 2020 at 9:48 AM Adrian Gropper <agropper@healthurl.com>
wrote:

> My separation of concerns perspective has vastly different authorization
> requirements.
>
> A data processor should be blind to role, identity, or attribute except to
> the extent they are intentionally revealed by a customer or other account
> holder or required by law or auditing practice.
>
> A data controller should be my semi-autonomous agent and capable of
> evaluating role, attribute, purpose, or identity in order to grant access
> to data processor.
>
> It’s confusing to me whether Confidential Storage is scoped to include the
> controller as well as the processor. EDVs are clearly on the processor side
> with some processors holding the encryption keys and others expecting the
> keys to be held by some other entity.
>
> On the other hand, our WG seems to have an interest in talking about a
> controller role as well.
>
> Adrian
>
> On Sun, Dec 6, 2020 at 9:39 AM Christopher Lemmer Webber <
> cwebber@dustycloud.org> wrote:
>
>> David Chadwick, you are completely correct that these are not new, and
>> that Verifiable Credentials can be used as an authorization system, and
>> as an authorization system resembles RBAC and ABAC, which are both in
>> the ACL-style world of identity-based authroization systems.  I agree
>> that this is possible, and what we get out of layering authorization on
>> top of an identity-oriented system.
>>
>> Now the question is, is an RBAC/ABAC/ACL style system *equivalent to*
>> an ocap/zcap style system?  And I'm going to say: no.  And I'm not the
>> first one!  This is called "the equivalence myth" in ocap circles,
>> and has been long documented:
>>
>>   https://srl.cs.jhu.edu/pubs/SRL2003-02.pdf
>>   http://www.erights.org/elib/capability/duals/myths.html#equiv-myth
>>
>> So now that we've established that VCs as an authorization system will
>> result in ACL/RBAC/ABAC systems, and that such systems are *different*
>> from ocap/zcap style systems, the question is now a design *choice*.
>> I have made, at length, my argument for why, understanding this, we want
>> a clean separation and thus to choose ocaps/zcaps for authority at great
>> length already in the following post:
>>
>>
>> https://lists.w3.org/Archives/Public/public-credentials/2020Dec/0028.html
>>
>> But I appreciate your clear categorization of which authorization-camp
>> we will end up if we build such authorization on top of VCs.  That helps
>> make the conversation much easier!
>>
>>
>> David Chadwick writes:
>>
>> > Conceptionally Verifiable Credentials are not new. They were first
>> > standardised in the 1960s by ECMA as PACs (Privilege Attribute
>> > Certificates).
>> >
>> > "Authentication and Privilege Attribute Security Application with
>> > related key distribution
>> > functions" Standard ECMA-219, 2nd edition - March 1996
>> >
>> > They have always been authorisation tokens, whether directly or
>> > indirectly. Using them for identity is simply indirect authorisation
>> > via ABAC and RBAC.
>> >
>> > Every plastic card I have in my physical wallet today is an
>> > authorisation token, whether directly or indirectly. If it did not
>> > confer some privilege on me, I would not make space for it.
>> >
>> > I agree with Daniel, schemas will need to be defined to store
>> > different types of authz credentials in VCs, But that is not new
>> > either. Schemas are needed for all the properties that are assigned to
>> > VC subjects.
>> >
>> > Kind regards
>> >
>> > David
>> >
>> > On 06/12/2020 01:37, Christopher Lemmer Webber wrote:
>> >> I wrote my mega-response before reading Dave's; we raise some different
>> >> points, but I think Dave frames things nicely as well.
>> >>
>> >> Dave Longley writes:
>> >>
>> >>> TL; DR: My current view is that the main confusion here may be over
>> the
>> >>> difference between VCs and LD Proofs, not VCs and ZCAPs. VCs are not a
>> >>> generalized container for attaching a cryptographic proof to a
>> document.
>> >>> That's what LD proofs (or JOSE style proofs) are for. VCs *use* LD
>> >>> proofs (or JOSE style proofs) to attach an assertion proof to a
>> document
>> >>> that specifically models statements made by an issuer about some
>> >>> subject, which is therefore inherently about the identity of that
>> subject.
>> >>>
>> >>> Even if we were to say "let's combine ZCAPs and VCs" -- we'd
>> >>> *still* need to agree on a data model for expressing OCAPs inside VCs.
>> >>> If we want that to be standard (which is what standardizing ZCAPs is
>> >>> about), then that work doesn't "go away" just because you put a ZCAP
>> in
>> >>> a VC as a "credentialSubject".
>> >>>
>> >>> Daniel,
>> >>>
>> >>>> ... snip ..
>> >>>>
>> >>>> Second, I have yet to see ANY justification for the hammer/screw
>> >>>> analogy. I gave an example of using a VC to express an ocap. It was
>> >>>> simple and elegant, and 100% compatible with the VC spec.
>> >>> I think your example has a flaw, however, because the data itself does
>> >>> not express what you said it expresses. Rather, a plain reading of it
>> >>> using the VC semantic model says something else.
>> >>>
>> >>> ```
>> >>> {
>> >>>    "@context": [ "https://www.w3.org/2018/credentials/v1",
>> >>> "https://roboticlab.cam.ac.uk/grants" ],
>> >>>    "type": ["VerifiableCredential", "RobotPrivilege"],
>> >>>    "issuer": "https://facebook.com/Amy",
>> >>>    "issuanceDate": "2021-01-01T19:73:24Z",
>> >>>    "credentialSubject": { "id":
>> >>> "https://roboticlab.cam.ac.uk/~amyt/capstone-project", "allow":
>> "operate"},
>> >>>    "proof": {...}
>> >>> }
>> >>> ```
>> >>>
>> >>> The above does not say "It's an assertion that the bearer is
>> >>> authorized." as you stated in your earlier email. It says:
>> >>>
>> >>> The subject identified by
>> >>> "https://roboticlab.cam.ac.uk/~amyt/capstone-project" has the
>> property
>> >>> "allow" with the value "operate".
>> >>>
>> >>> This has nothing to do with any bearer of the VC. In fact, if one were
>> >>> to *guess* more about the meaning of this VC, it would be that Amy's
>> >>> "capstone project" is allowed to operate. Again, that's just guessing
>> >>> from the English used in the terms and the identifier. This is not
>> what
>> >>> a machine would think without adding special-cased code that bends the
>> >>> meaning to fit a use case. A machine would simply consider the
>> >>> statements to be about whatever this subject is. This highlights that
>> >>> VCs are just about making statements of identity about a particular
>> subject.
>> >>>
>> >>> Note that the triples here are:
>> >>>
>> >>> <https://roboticlab.cam.ac.uk/~amyt/capstone-project> <allow>
>> <operate>
>> >>>
>> >>> (For some unambiguous mapping of "allow" and "operate" to full URLs).
>> >>>
>> >>> These statements presumably say nothing about the bearer (unless the
>> >>> bearer is identified by that "/capstone-project" URL). Even if so,
>> what
>> >>> would they be allowed to operate on?
>> >>>
>> >>> So the semantics that you're layering on top through language in your
>> >>> email are not present in the data itself. Another attempt will have to
>> >>> be made to see what a VC would look like if it were to properly model
>> an
>> >>> OCAP.
>> >>>
>> >>> My guess is that the VC would have to contain a fully modeled OCAP
>> >>> as the `credentialSubject`. If true, it would become more obvious (in
>> my
>> >>> view) that the VC data model is merely being (mis-)used as a container
>> >>> for an OCAP. Instead, applying a proof to the OCAP directly would have
>> >>> sufficed and it could more accurately carry important semantics such
>> as
>> >>> that the purpose of the proof was for the delegation of authority
>> rather
>> >>> than merely asserting such authority exists (a claim of identity).
>> >>>
>> >>> Certainly, you could express a claim that someone possesses an OCAP.
>> >>> Note that this is still different from expressing a claim, for
>> >>> example, that someone possess a driving license. Possession of a
>> driving
>> >>> license does not authorize you to drive *my* car. It isn't bound to a
>> >>> particular object and what you can do with it extends even beyond just
>> >>> driving. You could potentially present your driving license and get an
>> >>> authorization to drive *my* car in return. But even then you don't get
>> >>> to drive my car simply because you are saying you have an
>> authorization
>> >>> to drive *my* car. That may cause you to drive my car when your intent
>> >>> was different (merely to announce that you could if you wanted).
>> >>>
>> >>> I think this highlights some other problems with trying to fit OCAPs
>> >>> into the VC/VP model. There are some odd semantics to overcome if
>> >>> someone wants to "present" an OCAP using Verifiable Presentation
>> >>> machinery. As they are presenting the fact that someone said they
>> >>> possess an OCAP rather than creating a proof that is explicitly
>> invoking
>> >>> it. You don't invoke a Verifiable Presentation -- you invoke the OCAP,
>> >>> so that's where the proofs should be attached. It seems to me that a
>> >>> number of rather semantically-confusing hacks would have to be
>> >>> implemented in order to cause OCAPs to travel inside of VCs.
>> >>>
>> >>> IMO, this suggests to me that trying to fit OCAPs into the existing
>> >>> VC/VP standard may be moving backwards toward a world where the
>> >>> semantics for VCs are in people's heads, not in the data itself. A
>> major
>> >>> reason for much of the VC work was to make data more self-describing
>> and
>> >>> capable of being used across contexts without needing to go through a
>> >>> centralized authority for extensibility.
>> >>>
>> >>> Existing work (JWT claims, etc.) could not do this and were very
>> limited
>> >>> in what they could convey across contexts. This is because they really
>> >>> were more useful as authorizations for a specific party, not merely
>> >>> statements of identity. The existing work emphasized the authorization
>> >>> use cases first rather than the identity ones and then said "This
>> could
>> >>> work in the identity cases too" without a focus there. The result was
>> a
>> >>> half-measure that never really solved the bulk of the identity use
>> >>> cases; that's why VCs sprung into existence. I suspect we'd be making
>> >>> the same mistake in the opposite direction to try and bend VCs back
>> >>> toward authorizations ... just because maybe we could squint and make
>> it
>> >>> work.
>> >>>
>> >>> OCAPs are an improvement over other authorization schemes for a
>> variety
>> >>> of reasons, and flavors such as ZCAP-LD do include some level of
>> >>> self-describing information as well, but it is less of a concern
>> because
>> >>> they are intentionally not used across contexts. There is only one
>> >>> "verifier" or one "type" of object for a given capability. What you
>> can
>> >>> "do" with an OCAP is not open-ended -- it is strictly defined by the
>> >>> verifier (which is the same party as the original "issuer"). VCs are
>> the
>> >>> opposite and intentionally split the issuer and verifier parties apart
>> >>> -- even if you can have one party play both roles for some use cases.
>> >>>
>> >>> This means OCAPs and VCs have very different economics as well. VCs
>> are
>> >>> designed for an ecosystem where issuers can create valuable VCs to be
>> >>> broadly used across many verifiers precisely because they are fully
>> >>> self-describing and issuers are confined to only making statements
>> >>> that express properties of identity about subjects. Issuers needn't be
>> >>> concerned about what authority is conferred because they do not grant
>> >>> any authority. Only verifiers do that. Issuers do not *need* to know
>> or
>> >>> care about how these properties may be used -- and interesting new
>> ways
>> >>> to use them may crop up long after issuance.
>> >>>
>> >>> OCAPs are quite the opposite; their use is strictly defined and
>> limited
>> >>> by the original granter of authority. This also means that, as a
>> granter
>> >>> of a capability, you don't need to gather as much community consensus
>> >>> around what the meaning of a particular authorization is in order for
>> >>> what you're granting to be useful across contexts ... because that
>> would
>> >>> be an abuse of the OCAP. You are explicitly not making a statement of
>> >>> authority that is intended to be used *anywhere* except on the target
>> >>> object.
>> >>>
>> >>> Of course, since VCs are based on an open world model, you can try and
>> >>> put anything you want into them. That doesn't mean it won't get
>> >>> cumbersome or that everything *should* be put into them. Furthermore,
>> a
>> >>> VC is always: "An issuer says these things are true about X". This is
>> >>> perhaps more restrictive than some people are thinking.
>> >>>
>> >>> Sure, you can substitute anything into "these things" or "X", but you
>> >>> can't change the rest of that sentence. A VC cannot say you have
>> >>> authority, it can say an issuer says you have authority. It is not an
>> >>> authorization itself. It could be used by some decision engine to
>> >>> *decide* to grant authorization, but that "granted authorization" is
>> >>> what an OCAP is. The OCAP *is* the authorization: delegatable and
>> >>> invocable at a particular target object -- and not to be confused
>> with a
>> >>> statement of identity. Similarly, as mentioned above, a VP does not
>> say
>> >>> you're invoking an OCAP -- if you were to present one "as a VC".
>> Rather,
>> >>> it would say that you're *announcing* that an issuer *says* you have
>> an
>> >>> OCAP. I think these differences are important and confusing them leads
>> >>> to subtle vulnerabilities.
>> >>>
>> >>> My current view is that the main confusion here may be over the
>> >>> difference between VCs and LD Proofs, not VCs and ZCAPs. VCs are not a
>> >>> generalized container for attaching a cryptographic proof to a
>> document.
>> >>> That's what LD proofs (or JOSE style proofs) are for. VCs *use* LD
>> >>> proofs (or JOSE style proofs) to attach an assertion proof to a
>> document
>> >>> that specifically models statements made by an issuer about some
>> >>> subject, which is therefore inherently about the identity of that
>> subject.
>> >>>
>> >>> Lastly, even if we were to say "let's combine ZCAPs and VCs" -- we'd
>> >>> *still* need to agree on a data model for expressing OCAPs inside VCs.
>> >>> If we want that to be standard (which is what standardizing ZCAPs is
>> >>> about), then that work doesn't "go away" just because you put a ZCAP
>> in
>> >>> a VC as a "credentialSubject".
>> >>
>> >> .
>>
>>
>>

-- 

Stephen Curran
Principal, Cloud Compass Computing, Inc. (C3I)
Trustee, Vice Chair - Sovrin Foundation (sovrin.org)

*Schedule a Meeting: **https://calendly.com/swcurran
<https://calendly.com/swcurran>*