Re: Today's presentation on Credentials v Capabilities

The real-world process for prescriptions is:

- The prescription is managed by the system operated by Dr. Bob’s employer.
Bob signs the prescription and it is, unfortunately, not given to Alice.
(Unfortunate because Alice is unable to shop for a pharmacy and this adds
significantly to our drug costs.)The hospital’s EHR becomes the responsible
entity.  Is the EHR a holder or an issuer? Seems like they’re an issuer
delegated by Dr. Bob.

- If the prescription is for a controlled substance, then Dr. Bob is
required to get a de-duplicated identifier for AlIce and to then look Alice
up in the state registry (called a Prescription Drug Monitoring Program or
PDMP) This lookup is also mediated by Bob’s EHR but is tied to Bob’s
individual credentials.

The prescription makes its way directly from the EHR to CVS via a
proprietary network called Surescripts or a fax and is treated more or less
like a bearer credential, typically based on a Trust On First Use approach
where Bob’s authority AND the EHR are deemed trusted if the pharmacy has
seen them before. There’s no explicit trust framework except for controlled
substances. (Surescripts itself is under investigation by the FTC for
anti-trust. Charming folks, I assure you.) The EHR “spends” the
prescription as soon as its receipt is acknowledged by CVS. If CVS does not
have the pills or dispenses only half the pills, they need to return the
prescription to the EHR. (This too is a nightmare for patients that get
caught up in it.)

- Unlike the scenario in the RWOT9 paper, anybody that identifies the
patient name and birthdate can pick up the prescription. This is true for
controlled substances as well but in those cases, the de-duplicated
identifier of the recipient (their driver’s license number) is entered into
the PDMP.

- The pharmacist is required to check the PDMP before dispensing a
controlled substance. This is somewhat redundant with the check made by Dr.
Bob when the prescription is issued. The pharmacist may raise an exception
based on guidelines.

- Partial fill of a controlled substance prescription may or may not be
allowed under law. This too is unfortunate because patients end up with
more opioid pills than they might want and the extras often end up being
misused.

My point is that existing trust frameworks do not map nicely into the
prescription use case and adoption of DIDs and/or VCs for Alice, Bob, or
Bob’s EHR may not convert in a coordinated way. Similar issues probably
arise in other verticals, such as how do letters of recommendation travel
from Issuer to Verifier without being revealed to the subject, etc...

- Adrian

On Tue, Feb 18, 2020 at 7:09 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>
>
>
>