Re: Revocation entry

Many already know this, so this comment may be partly redundant--but for
those who are unaware, I'll just make a note about Sovrin and Hyperledger
Indy's approach to this problem.

We were concerned that most revocation mechanisms destroy privacy, because
they involve looking up revocation status in a centralized location with a
consistent lookup key. Alice has to disclose the revocation lookup key with
each credential use, providing a perfect correlator. Anybody monitoring
such lookups can see every time Alice uses her credential, and which
verifier has to check non-revocation as a result.

Sovrin therefore implemented an approach that uses cryptographic
accumulators instead. This allows Alice to prove in zero knowledge that the
credential she's using has not been revoked, without disclosing any kind of
revocation lookup key for herself. (She does, however, disclose where the
issuer's revocation commitment is published on the ledger. All holders of
credentials from the same issuer disclose the same value for that, so this
had a herd privacy profile.) The particulars of this mechanism are
described here
<https://github.com/hyperledger/indy-hipe/tree/master/text/0011-cred-revocation>
.

This method works fine, and is being used in production. However, it is
"heavy" in the sense that it requires more setup from issuers, and it means
provers have to download some auxiliary data files to prove non-revocation,
if their credentials have revocation features. So Sovrin is now in the
process of switching to a more elegant approach that uses merkle trees
(with a root hash on the ledger) instead of cryptographic accumulators.
This will make the burden on issuers and provers much lighter.

On Thu, Sep 26, 2019 at 11:34 AM Isaac Patka <isaac@bloom.co> wrote:

> I’m also interested in some standards on revocation registries. Bloom’s
> implementation embeds revocation tokens in the original credential signed
> by the issuer. Issuers revoke the credential by publicly listing the
> embedded token on a registry (currently implemented as a smart contract on
> Ethereum). This satisfies point 2A in Orie’s email. There is nothing
> publicly revealing about publishing the revocation token.
>
> We don’t currently distinguish the revocation reason between key
> compromise and credential status change. Not sure how important the reason
> code is because the end result is the same.
>
> The most important thing is that the revocation method is embedded in the
> original credential and signed by the issuer.
>
> There may also need to be some method of batch revoking based on issuance
> metadata. For example an issuer should be able to revoke all credentials of
> a certain type before a certain date if they discover a flaw in their
> verification system.
>
> Revocation token spec:
>
> https://github.com/hellobloom/specs/blob/master/attestation-data/Bloom-Merkle-Tree-22facf0b-bedb-4b45-bb7d-edcd57213eb0.md#claim-node
>
> Revocation registry in a smart contract:
>
> https://github.com/hellobloom/core/blob/master/contracts/AttestationLogic.sol#L318
> Deployed here:
>
> https://etherscan.io/address/0xceec7aaa57e3a77c73a9954b9b7d5b32ab688318#code
>
>
> On Sep 26, 2019, 1:09 PM -0400, Orie Steele <orie@transmute.industries>,
> wrote:
>
> As I understand it, there is no formalization of this concept... or if
> there is, its not widely supported enough to be linked or described in
> https://www.w3.org/TR/vc-data-model/#security-considerations
>
> I think there are 2 things related to revocation that need to be defined
> well.
>
> 1. Key revocation (how to show that a key that is still present in a DID
> Document or similar is revoked)... pretty similar to the concept in PGP...
> http://www.pgp.net/pgpnet/pgp-faq/pgp-faq-key-revocation.html...
> Important to consider because it may or may not be a requirement: see the
> comment about signing key in 2.
>
> 2. Credential revocation with registry (as you mention).
>
> There are a couple highlights that hint at implementation requirements
> (the following subset pulled from search results for "revocation"):
>
> *A. Revocation by the issuer should not reveal any identifying information
> about the subject, the holder, the specific verifiable credential, or the
> verifier.*
>
>
>
>
> * B. Issuers revoking verifiable credentials should distinguish between
> revocation for cryptographic integrity (for example, the signing key is
> compromised) versus revocation for a status change (for example, the
> driver’s license is suspended). C. Designing revocation APIs that do not
> depend on submitting the ID of the credential. For example, use a
> revocation list instead of a query.*
> I implemented a revocation approach for an ipfs based did scheme as a PoC
> a while back. It used self describing JSON Schema, and a custom revocation
> credential format:
>
>
> https://github.com/transmute-industries/transmute/blob/86563bfca6e197877f0e5bb287948501bcce8e84/docs/schemas/com.transmute/didRevocationCert/jsonschema/1-0-0
>
> This code is pretty stale at this point, but I will try and explain:
>
>
> https://github.com/transmute-industries/transmute/blob/86563bfca6e197877f0e5bb287948501bcce8e84/packages/transmute-did-orbit-db/scripts/utils/orbitHelpers.js#L380
>
> We used OrbitDB which is an append only database on top of IPFS.
>
> For any given public key, you can construct a log that will only take
> signed entries from that key, (the log is p2p discoverable and sync-able
> over WebRTC).
>
> When processing a DID Document, the verifier needs to know that the
> "revocations" property of a public key points to a orbit db database
> address, that needs to be searched for messages related revocations.
>
> The messages must be signed by the key to get added to the list (property
> of orbitdb).
>
> The message can be a revocation of the key itself, or a revocation of a
> specific VC (indicated by hash).
>
> The verifier should handle these scenarios differently as noted above.
>
> The PoC worked and there was a UI demo of it but it relied on IPNS and I
> have since taken down the IPFS node.
>
> You may or may not be able to get it to work locally:
> https://github.com/transmute-industries/transmute/tree/86563bfca6e197877f0e5bb287948501bcce8e84/packages/transmute-did-orbit-db
>
> 2 reasons we abandoned this project.
>
> 1. it was mostly an experiment related to DIDs
> 2. there was no formalization around what we were doing from a revocation
> perspective
>
> I would love to help get a better formalization around revocation, if any
> of this is helpful feel free to use it.
>
> OS
>
>
>
> On Thu, Sep 26, 2019 at 11:31 AM Oliver Terbu <oliver.terbu@consensys.net>
> wrote:
>
> Hi,
>
> Is there a recommended way for how to specify a revocation method in the
> VC, or what information a revocation entry should provide -- e.g., status
> only? I know there will be likely a revocation method registry in the
> future but how do we avoid name clashes?
>
> I'm familiar with:
>
> "revocation": {
>   "id": "http://example.gov/revocations/738",
>   "type": "SimpleRevocationList2017"
> },
>
> We want to implement a smart contract-based revocation registry -- don't
> worry, we are not going to store the revoked VCs themselves. My proposal
> would be:
>
> "revocation": {
>   "id": "some-identifier-that-points-to-the-instance",
>   "type": "EIPxyzRevocationRegistry2019"
> },
>
> Thanks,
> Oliver
>
>
>
> --
> *ORIE STEELE*
> Chief Architect
> www.transmute..industries
>
> <https://www.transmute.industries>
>
>