Re: Revocation entry

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>