Re: Today's presentation on Credentials v Capabilities

I was rambling in IRC about this during the meeting. The data model
similarities (and differences) caught my eye, but based on the discussion,
I saw why the zcap spec (for example) was more streamlined for the purpose.

Yet, I did not understand how no-phone-home yet issuer-specific were
reconcilable, but I didn't think there was time to get into it.

Again, I was approaching it from a very low-level data model diff-ing
perspective, and wondering if we will end up with a range of VerifiableXs
in the future.

On Tue, Feb 18, 2020 at 3:54 PM Joe Andrieu <joe@legreq.com> wrote:

> Daniel,
>
> Let's dive into this. I agree that VCs can be used for delegation. I just
> don't believe they are the most appropriate way to do so. You can, of
> course, say *anything* in a VC, so you can easily make statements that are
> interpreted as delegations. But VCs themselves do not provide mechanisms to
> specify or interpret capabilities and delegations.
>
> So, let's take your first statement:
>
> 1. Credentials can be made delegatable, and they can be attenuated. This
> collapses the most interesting differences between credentials and
> capabilities, making a special new data format for capabilities
> unnecessary. Capabilities can be done with VCs (any type that's
> W3C-data-model-compliant).
>
>
> 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.
>
> What does it mean to delegate that? Or attenuate it.
>
> Yes, I can make statements about that statement. I can even make arbitrary
> statements about that statement. I could say "Joe delegates the credential
> X". But these appear to have no meaning.
>
> Generally only privileges are delegatable. So, the only VCs that are
> delegatable are those expressing privileges. But which VCs should be
> interpreted that way? Certainly not VC X. 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.
>
> 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.
>
> I also read through the article contrasting zCaps with your approach (
> https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0104-chained-credentials/contrast-zcap-ld.md
> ).
>
> I won't go into it line-by-line here, but I do invite others to review it.
>
> There are some misconceptions about how zCaps work (verifying a DID
> signature doesn't require phoning home to the DID subject) and some root
> disagreements about priorities (ZKP ALL-THE-THINGS). I also have my doubts
> about the security implications of "short circuiting" VC issuance.
>
> That said, I'll repeat my opening statement. YES, you can use VCs to
> construct delegations.
>
> 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.
>
> 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?
>
> -j
>
> On Tue, Feb 18, 2020, at 10:52 AM, Daniel Hardman wrote:
>
> FWIW, I would like to offer the following alternative perspective to the
> ideas in Joe's slides.
>
> 1. Credentials can be made delegatable, and they can be attenuated. This
> collapses the most interesting differences between credentials and
> capabilities, making a special new data format for capabilities
> unnecessary. Capabilities can be done with VCs (any type that's
> W3C-data-model-compliant).
>
> 2. The problem of extending privileges (delegation and attenuation) is
> actually a special case of the more general problem of data provenance.
> Delegation just requires that we show the provenance of privileges (did
> these privileges derive from someone who had them to give away?). But
> solving the data provenance problem has additional far-reaching benefits (a
> small employer can prove the provenance of data that they collected from an
> employee, that originated in a passport -- and the assurance associated
> with the employment credential, for those attributes, can be as strong as
> it was for data directly from the passport itself, instead of being
> governed by whatever trust someone might be inclined to give to the small
> and unfamiliar employer).
>
> This is discussed at length in Aries RFC 0104:
> https://github.com/hyperledger/aries-rfcs/blob/master/concepts/0104-chained-credentials/README.md
>
>
> On Tue, Feb 18, 2020 at 11:06 AM Joe Andrieu <joe@legreq.com> wrote:
>
>
> Here's a link to the powerpoint for today's tech talk.
>
>
> https://github.com/w3c-ccg/meetings/blob/gh-pages/2020-02-18/credentials_and_capabilities.pptx?raw=true
>
> -j
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>