Re: New Work Item Proposal: Revocation List 2020

In Sovrin we actually have a separate non revocation credential that we use to prove in zero-knowledge whether it’s revoked or not with a schnorr proof showing the two credentials are tied together by an attribute in both

________________________________
From: Orie Steele <orie@transmute.industries>
Sent: Saturday, May 2, 2020 9:22:18 AM
To: Adrian Gropper <agropper@healthurl.com>
Cc: Manu Sporny <msporny@digitalbazaar.com>; 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

There is a lot in the previous email, I'm probably not gonna be able to address it all, but I will try :)

There are a bunch of different layers which are being considered by the prescription use case.

1. identifiers (for people, companies and prescriptions)
2. credentials (for prescriptions, for ability to issue them, and for ability to fill them)
3. credential storage (where are credentials, who can access them)

1,2 & 3 do not require DLT / Blockchain, they can be solved with identifiers, signing and encryption, or as they are today.

3 is essentially what we are trying to solve with Secure Data Stores (formerly edvs, now here: https://github.com/decentralized-identity/secure-data-store)... This layer applies to all parties here, the Issuer of the Prescription (Doctor), the Holder of the Prescription (Patient) and the Verifier of the Prescription (Pharmacist).

The pharmacist does not "revoke" the prescription. They verify it, and then they fill / consume it (in part or in full). This can be modeled a number of different ways, but one naive way would be that for every Prescription VC issued by doctors, there are N PrescriptionFilledReceipt VCs from Pharmacists....

A pharmacist stores their filled prescription receipts in their secure data store. We must consider the case where a Patient suffering from substance abuse disorder, attempts to fill the same prescription with a different pharmacy... Last I accidentally tried to do this, they forwarded the prescription in minutes, since I was at the wrong location... I assume they would not do that if I had already filled it.

The Pharmacists can grant access to governments or auditors... Patients can delegate their credentials (say parents to children to go pickup things)....

Revocation is an assertion from the Issuer saying "the claim I made about the subject is not to be accepted"... Anything other than that should be handled via linking of credentials, or higher order interactions with things like Secure Data Stores or Encrypted Data Vaults or Aries Agents.

If it's really the case that 2 partis can both revoke a credentials or are both required to revoke a credential, you can accomplish this use some kind of as yet undefined MultiSig VC format (since revocation lists are VCs)... or you could make N lists and require the credential in at least 1 or all.... in my opinion this second case might be better mediated through an agent or higher order protocol, but it would be possible to adopt the proposal to support this case I imagine.

Since this email is already miles long... I would LOVE to see the BBS+ ZKP VC approach to this problem... I was trying to imagine what it might look like last night but I Imagine Mike Lodder or Tobias would be able to take the VC Format proposed and that suite, and add yet another layer of privacy for those who can support that specific key and signature format. Since the revocation list is a VC, they can use the existing schema definitions... The one part that I don't think would work is the compression.... Is it possible to use BBS+ ZKP VCs to create privacy preserving revocation lists that are the same size / use compression?

Can't I just provide a verifier with my proof of non revocation along with my credential?... even for credentials that were issued with suites other than BBS+, like Ed25519 or Secp256k1?

OS








On Sat, May 2, 2020 at 9:09 AM Adrian Gropper <agropper@healthurl.com<mailto:agropper@healthurl.com>> wrote:
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<mailto: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



--
ORIE STEELE
Chief Technical Officer
www.transmute.industries

[https://drive.google.com/a/transmute.industries/uc?id=1hbftCJoB5KdeV_kzj4eeyS28V3zS9d9c&export=download]<https://www.transmute.industries>