Re: Today's presentation on Credentials v Capabilities

This exact scenario (both the normal use of a VC-based prescription that
Adrian postulates, and some of the wrinkles that Joe raises) is discussed
in "Alice Attempts to Abuse a Verifiable Credential" from August's RWOT.
<https://github.com/WebOfTrustInfo/rwot9-prague/blob/master/final-documents/alice-attempts-abuse-verifiable-credential.pdf>

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

> Since the prescription is not presented back to the doctor, it is probably
> a VC.
>
> How CVS "modifies" the VC is an open issue. There currently is no way to
> guarantee that Alice doesn't have a backup copy of the original VC.
>
> Unfortunately, keeping track of usage like that will need some form of
> quasi-centralized tracking. You could set up a blockchain that allows
> doctors to authorize X pill vouchers for a particular proof mechanism (aka
> DID/key pair) and pharmacists would require Alice to "spend" those pill
> vouchers to get her prescription fulfilled. Unless you have some sort of
> coordinated ledger, you really can't get away from the duplicate pill
> problem--its essentially the same as double spend.
>
> You could also choose to restrict the prescription to a particular
> pharmacy (another form of centralization). In this case, CVS would issue a
> capability for Alice to receive so many of a specific type of pill, and
> they would simply keep track internally wrt refills, etc. Of course, the
> problem is CVS would become the arbiter of all truth, undermining the
> authority of the physician and Alice's ability to get her prescription
> fulfilled somewhere else. This approach seems like a non-starter.
>
> The harder problem, IMO, is doctor shopping where the patient gets
> multiple doctors to issue prescriptions. Even with the fancy blockchain I
> theorized above, this would still be a point of risk. In order to close
> that, you need to de-dup the patient across all doctors for specific
> medicines, which is frought with privacy problems. There might be some
> approaches that could avoid some risks, but doing so rigorously is, IMO,
> still a research question.
>
> -j
>
> On Tue, Feb 18, 2020, at 4:51 PM, Adrian Gropper wrote:
>
> Is a prescription a credential or a capability? Dr. Bob is the issuer of a
> prescription for 30 pills with Alice as a subject. Alice delegates her son
> to pick up the drugs. The son chooses CVS as the verifier. After
> dispensing, half the pills, CVS does something to modify the prescription
> to indicate 15 pills.
>
> - Adrian
>
> On Tue, Feb 18, 2020 at 2:53 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>
>
>
>
> --
> Joe Andrieu, PMP
>                    joe@legreq.com
> LEGENDARY REQUIREMENTS
>    +1(805)705-8651
> Do what matters.
>                  http://legreq.com <http://www.legendaryrequirements.com>
>
>
>