Re: Today's presentation on Credentials v Capabilities

>
> Can you provide an example? Even better if you start with a VC, issued by
> Joe, that claims "The sky is blue". We'll call this VC X.


There are very detailed examples and diagrams in the RFC I linked.
Interestingly, the most elaborated example is one you also used, about
delegation of a car key with a valet.


> So how does anyone know which VCs are delegatable? Further, how does
> anyone know the boundaries of that delegation, that is, the range of
> verifiers for whom such delegation is appropriate? Just because I give my
> child a VC saying they can use my credit card to buy milk at Ralph's
> doesn't mean that the cashier at LiquorMart will honor that constraint.
> Heck, all they need is the credit card # and a willing cashier. More
> importantly, will the credit card companies recognize that delegation as
> legitimate? What if they accept the first one (because "Milk from Ralph's"
> is fairly well defined) but they reject the second one? More likely,
> because the LiquorMart POS almost certainly doesn't require a VC of any
> particular type, the cashier will probably just make the sale. In contrast,
> the same use case using zCaps would originate at the credit card company
> and invoking it at either the LiquorMart or Ralph's would definitively
> validate the purchase according to the delegation framework as defined by
> the credit card company... and the retailer would immediately know whether
> or not the transaction is valid.
>

I believe the RFC I linked to has moderately good answers to these
questions. It is not a deeply polished doc, though, so there could be gaps.


> zCaps is a particular set of semantically rigorous operations that define,
> without ambiguity, how delegation and invocation proceeds for particular
> actions at a given issuer. I have my doubts about the wisdom of
> shoe-horning custom semantics into the VC structure, which is meant for
> verifying statements by one source at another. Statements across trust
> boundaries and actions within a singular trust context are two very
> different beasts, IMO.
>

You are making the claim that capabilities are inherently about a singular
trust context. I think that's an oversimplification. That's fine. We can
agree to disagree. I may be wrong. If so, I agree that this might be a
reason to explore a new mechanism.


> There are some misconceptions about how zCaps work (verifying a DID
> signature doesn't require phoning home to the DID subject)
>

I think you may be misconstruing something. Did you have the following
sentence in mind when you made that conclusion? I said that the zCaps
"mechanism for validating the non-revocation status of each credential in
the delegation chain seemed to follow the same revocation checking pattern
as traditional non-ZKP credentials." Note that this sentence has nothing
about signature verification in it, and that it also has nothing about DID
subjects in it. It's about revocation checking, not signatures.


> and some root disagreements about priorities (ZKP ALL-THE-THINGS).
>

The mechanism I'm advocating is not dependent on ZKP technology, as the RFC
states very explicitly at the top (and several places in the running text).
You could implement it today with Digital Bazaar's JSON-LD-centric
credentials, or with JWT-centric credentials, etc. I also pointed this out
in my first message on the thread. I have never taken the position that we
should "ZKP ALL-THE-THINGS." That is a caricature that seems to crop up
from time to time in these circles; I would be glad of a general commitment
from all of us to kill such distortions. As near as I can tell, the
caricature seems to survive on careless FUD. I find it particularly amusing
in this case, given the non-ZKP-oriented content I linked.


> I also have my doubts about the security implications of "short
> circuiting" VC issuance.
>

Excellent. I invite you to contribute to the discussion about the VC threat
model at credential-fraud-study@googlegroups.com, or to raise issues
against Aries RFC 0207: Credential Fraud Threat Model
<https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0207-credential-fraud-threat-model/README.md>;
when there's evidence of serious engagement on the topic in W3C circles,
perhaps we can finally bring it to this group as a work item. I raised the
threat model topic at the Aug 2019 RWOT, but didn't have an opportunity to
engage with you directly. My perception is that we're not thinking about
this topic hard enough, yet. So your thoughts could probably help us a lot.


> But IMO doing so is barely more rigorous than using a printed contract for
> the same purpose. Maybe it will be accepted by a verifier, maybe it won't.
> Maybe it will make sense to a verifier, maybe it won't. Maybe it will be
> delegated appropriately, maybe it won't. Maybe the verifier will be able to
> make sense of delegations, maybe they won't. zCaps fixes all that
> ambiguity, IMO.
>

It seems like maybe you haven't read the RFC? We could very well still have
a difference of opinion when you've done that, but I doubt it will be about
ambiguity.


> Let me finish by inviting you to present your approach on a future call.
> My discussion was to socialize a distinction between credentials and
> capabilities that is creating value for people I'm working with. As CCG
> co-chair, it would be a service to the community if you could present your
> approach to directed capabilities.
>
> Would you be up for that?
>

Yes, I'd be glad to do that. Thank you for the invitation. How is an item
like this scheduled?