Re: New Work Item Proposal: Revocation List 2020

@Rieks suggestion is reasonable in the real-world sense but poses a
challenge to the privacy aspects of SSI and the rubrics for
decentralization.

Once Connor is expected to routinely phone home to Barkley, the core reason
for SSI is questionable. We’re back in the current situation where Barkley
runs a web server under an SSL certificate that displays the prescription
to Connor under the control of Alice’s authorization server.

Many years ago, I asked our community if a prescription would be a use-case
for a VC and the answer came back yes. We can decide to put off worrying
about the prescription use case but we might also need to revisit
delegation at the same time for somewhat different reasons that @Joe
Andrieu has explored.

My role in our community is from a privacy perspective. The HIE of One
Trustee project is intended to show SSI practice in the mainstream health
care domain. We need the community’s help (guidance as well as coding) if
Trustee is to serve as a reference implementation for our SSI work.

I know that our standards approach is not dependent on a reference
implementation, much less one as rich as healthcare. But I still hope some
participants will see value in a reference implementation and support
Trustee.

- Adrian

On Sun, May 3, 2020 at 3:31 AM Joosten, H.J.M. (Rieks) <rieks.joosten@tno.nl>
wrote:

> @Adrian Gropper <agropper@healthurl.com>, you should not allow Conner to
> revoke a prescription that he has not authored. That would be using
> revocation to control process flow, which is a different from 'coming back
> on on'es assertions' (which is what revocation of a VC means to me). So to
> me, it is like you're trying to get a square peg in a round hole.
>
>
>
> A prescription is like an order form. You don't revoke an order(form), you
> fulfill it, and then mark it as having been provided. So Conner can mark
> the prescription – perhaps issuing a VC that includes (a reference to) the
> presecription – as having been delivered. Imho, any VC should only be
> revokable by its issuer.
>
>
>
> So in your case, Conner should issue a request to Barkley to revoke the
> prescription. That would be similar to the police officers that do not
> revoke driving licenses for major traffic offernders, but rather they use
> (an app that contacts) a system that is operated by, or on behalf of the
> body that issues driving licenses, and inserts a request to revoke it. So
> this body is doing the actual revocation.
>
>
>
> The question remains whether or not all Barkleys and all Conners that are
> out there will be adapting their processes. Often, they already have
> working procedures in place that I think should be mimicked as closely as
> possible.
>
>
>
> Rieks
>
> *From:* Adrian Gropper <agropper@healthurl.com>
> *Sent:* zaterdag 2 mei 2020 16:08
> *To:* Manu Sporny <msporny@digitalbazaar.com>
> *Cc:* Daniel Hardman <daniel.hardman@evernym.com>; Credentials Community
> Group <public-credentials@w3.org>; Michael Chen <shihjay2@gmail.com>;
> Karan Verma <karnverma@alumni.stanford.edu>
> *Subject:* Re: New Work Item Proposal: Revocation List 2020
>
>
>
> Perfect. Now I understand what you mean.
>
>
>
> We can move on to the revocation aspects of the health care use case
> https://w3c.github.io/did-use-cases/#prescriptions The prescription is a
> VC issued by Dr. Barkley. It needs to be revoked by pharmacist Connor if
> and when dispensed. If not yet dispensed, Dr. Barkley must be able to
> revoke the VC because she wants to write a different prescription.
>
>
>
> This means that there are two places pharmacists need to check: one is
> controlled by Barkley the other is controlled by Connor. Unfortunately,
> Barkley does not know which pharmacy Alice will choose so that Connor's
> revocation registry cannot be part of the VC that Alice holds.
>
>
>
> *Point 1: *In the prescription use case, does it make sense for Connor to
> connect to Barkley's registry and revoke the prescription after they
> dispense it? In this case the privacy benefits are lost and so is the value
> of the prescription VC because Connor could have accessed the prescription
> itself at Barkley's server.
>
>
>
> *Point 2:* If Barkley's registry is a DLT with restricted write access,
> then each entry in the registry should have Barkley's DID (so they can
> change the prescription) and a way for Alice to grant the pharmacist she
> chooses, Connor, the right to write into the registry at that particular
> spot. For example, any pharmacist has write access to the registry based on
> their credentials but they must bring a DID along with their VC so that the
> registry can keep a log of Connor's action. If audited, Connor must produce
> a document signed by Alice that says she actually got the prescription.
>
>
>
> *Point 3:* The registry DLT could be a smart contract that checks
> Connor's credentials and keeps the log. The fact that Barkley wrote a
> prescription would be public but the subject and contents of the
> prescription would remain private. I'm not sure if the log of Connor
> filling the prescription can be public because it would show what kind of
> prescriptions Barkley tends to write. Is this where Nighfall comes in?
> https://github.com/EYBlockchain/nightfall
>
>
>
> Extra Credit:
>
>
>
> The current way this is solved for opioids and other controlled
> substances, is each state operates a detailed prescription registry called
> a Prescription Drug Monitoring Program (PDMP) and each state issues
> credentials to every doctor and every pharmacist for controlled access to
> their registry. (It gets worse: the PDMPs have to be connected to avoid
> doctor and pharmacy shopping across state lines and doctors and pharmacists
> have to delegate credentials to staff for workflow reasons. Also, each
> state has different laws for when law enforcement can access the PDMP, with
> or without a court order. This is a nightmare of the first order because
> now we have dueling state agencies and patient privacy interests. But I
> digress...)
>
>
>
> So today the PDMP registry is separate from the Issuer (Barkley) and the
> Verifier (Connor) and government has to issue credentials to all the
> practitioners and much of law enforcement. In some states, the patient can
> get a credential as well as part open record practices.
>
>
>
> Which leads me to *Point 4:* If government is going to maintain a
> registry of all controlled substance prescriptions with controlled write
> and read how can we ease their burden by introducing DID and / or VCs?
>
>
>
> - Adrian
>
>
>
>
>
>
>
>
>
> On Sat, May 2, 2020 at 8:58 AM Manu Sporny <msporny@digitalbazaar.com>
> wrote:
>
> On 5/2/20 2:56 AM, Adrian Gropper wrote:
> > I’m old enough to remember when credit card companies published
> > “little books” of revoked credit card numbers. Each merchant would
> > check to make sure the credit card number was not tampered with and
> > not in the list in the little book of the week.
> >
> > Is this a scheme to compress the size of the “little book” so that
> > the publisher could seed many copies at reasonable cost every week to
> > avoid traffic analysis when merchants come to ask for a copy?
>
> Yes, you could think of it in that way (with some hand waving over the
> details).
>
> To answer your earlier question, Adrian, here's a simple way to think
> about this revocation method:
>
> You are an issuer, and you issue 100,000+ VCs. You will have a "little
> book" that looks like this:
>
> [_____ ... lots of entries ... _____]
>
> Each underscore above (there are 100,000+ of those) map to ONE
> Verifiable Credential. If it's an underscore, the Verifiable Credential
> has not been revoked, if there is an "X" the Verifiable Credential has
> been revoked. So, after a week, you revoke one VC, your little book now
> looks like this:
>
> [_____ ... lots of entries ... __X__]
>
> Note that there is only one "X", which corresponds to the VC that was
> revoked.
>
> When a Verifier goes to check to check the "little book", they say:
> "Give me the entire little book", and in this case, you hand it over to
> them. You have no idea which entry they're interested in, you just give
> the little book over to them.
>
> Once the Verifier has the book, in the privacy of their organization,
> they check the entry they're interested in. If there is an "X" in the
> book beside the Verifiable Credential they're interested in, they know
> it's revoked. Otherwise, the VC is still valid (as far as the revocation
> status is confirmed).
>
> Now, if we were to not compress that little book, for a roughly 100K
> entries, the file size would be roughly 16KB. But, thanks to compression
> technologies that were invented in the 1990s, we can reduce the size of
> the little book by a lot... because there is only one "X" in it, we
> really just need to store the location of that one "X", which takes far
> less space than stating "this VC has not been revoked" over 100K times.
>
> ... and that's more or less all there is to it.
>
> -- manu
>
> --
> Manu Sporny - https://www.linkedin.com/in/manusporny/
> Founder/CEO - Digital Bazaar, Inc.
> blog: Veres One Decentralized Identifier Blockchain Launches
> https://tinyurl.com/veres-one-launches
>
>
>
> This message may contain information that is not intended for you. If you
> are not the addressee or if this message was sent to you by mistake, you
> are requested to inform the sender and delete the message. TNO accepts no
> liability for the content of this e-mail, for the manner in which you use
> it and for damage of any kind resulting from the risks inherent to the
> electronic transmission of messages.
>
>