Re: Revocation entry

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
>
>