Verifiable Claims Revocation

[joaosantos15]

Issue by joaosantos15
Friday Oct 20, 2017 at 15:00 GMT
Originally opened as inesc-id/dclaims-pm#20

---

There is an open discussion for VC revocation here:
w3c/vc-data-model#35

Essentially there is no standard way of revoking. They're main issue are privacy concerns. I'll cross check their concerts with what we are proposing and then will publish in that issue.

[joaosantos15]

Comment by joaosantos15
Friday Oct 20, 2017 at 15:19 GMT

---

TL;DR

Answers to these questions are required:
1- Can I know how is retrieving my IPFS files @diasdavid
2- Can someone know who is querying Ethereum smart contracts?

---

The main issue about privacy is making sure that the Issuer can not learn about how the issued credentials are being used.
For instance, if issuer:USA_DMV issues a credential for receiver:JOHN saying that John is accredited to drive cars, the DMV should not be able to know with whom John is sharing that credential with.

Can you describe a scenario where the DMV would know how John is using the credential?

Great question! And, sure.
Let's imagine that the revocation mechanism implemented by the DMV is a revocation address specific for that claim, a one-to-one relation (each revocation address concerns one verifiable claim). Something like:

{  
   "claim":{  
      "ID":"123456789",
      "issuer":"USA-DMV-ID",
      "receiver":"John",
      "claim":"driving-license",
      "revocation_url":"www.usa-dmv/is-this-claim-revoked/id?=123456789"
   }
}

As we can see, the revocation address is specific to that claim (the last part of the url is the ID of the license), which is a NO-GO, since by analyzing the web server's requests, the DMV could learn about who was querying that specific revocation address.

A better way of doing it (as far as privacy is concerned) would be to have a large list, with a lot of addresses, a one to many relation (where each revocation address concerns many verifiable claims, effectively becoming a revocation list) something like:

{  
   "claim":{  
      "ID":"123456789",
      "issuer":"USA-DMV-ID",
      "receiver":"John",
      "claim":"driving-license",
      "revocation_url": "www.usa-dmv/list-of-all-the-revoked-claims"
   }
}

Is how are planning to do it, better?

I believe so, I do need answers for these two questions:

• Can I know how is retrieving my IPFS files
• Can someone know who is querying Ethereum smart contracts?

Because, with Hypercerts revocation what would happen would be something like this:

{  
   "claim":{  
      "ID":"123456789",
      "issuer":"USA-DMV-ID",
      "receiver":"John",
      "claim":"driving-license",
      "revocation_url": "ethereum-smart-contract"
   }
}

And that "revocation_url": "ethereum-smart-contract" would resolve to an IPFS object that is unique to that specific verifiable claim. It seems pretty close to the NO-GO approach (one-to-one) but if the answer to the two questions I posed above is no, than we should be fine because even though the relation between verifiable claims and revocation list is one to one, there would be no way of knowing when that resource (the revocation information) is being accessed.

[joaosantos15]

Comment by joaosantos15
Sunday Oct 22, 2017 at 17:31 GMT

---

I talked with @diasdavid and the answer to

1- Can I know how is retrieving my IPFS files
2- Can someone know who is querying Ethereum smart contracts?

is no in both cases. Which is good.

He did raise an about using an Ethereum smart-contract only to save and check the state of a variable, something like:

#sample ethereum contract

cert_id = 12345
revocation_status= false

get_revocation_status(){return revocation_status}

change_revocation_status(){
//perform authentication ops
revocation_status = !revocation_status
}

The problem is that the state the variables' state displayed in the most recent blocks can be subject to change, as those blocks can become stale is the fork they are in is replaced by a larger one.

So, @diasdavid, could we not implement this is a way that would require the block to have been confirmed? Something like what happens in Bitcoin were sellers will only consider the payment fulfilled when they are in a block with several hours?

Essentially what we would be saying is that revoking a VC would take maybe a couple of hours. Do you see that as a problem?

[msporny]

Heads up that we have some closure on this issue over in Verifiable Credentials land: w3c/vc-data-model#35

We are now requesting implementations of the suggested mechanism to refine the proposal.