Re: Revocation entry

Yes, I agree with Daniel and cryptographic accumulators are definitely the
best way to go but there will still be registries on different networks.
For this reason, we need to have a standardised way for how to encode the
instance and scheme of the revocation registry in the VC.

My question was purely on the format of the revocation entry in the VC
itself rather than how to implement revocation in a privacy-preserving way.

Our current approach is:

```
"revocation": {
  "id": "some-identifier-that-points-to-the-instance",
  "type": "EIPxyzRevocationRegistry2019"
},
```

In this example, `id` will indicate on which network the revocation
registry is located, e.g., by using network id or chain id.

@Daniel: is this the way Sovrin is implementing it? How do you encode the
information in the VC in case you do?

For now, I don't want to go down the rabbit hole of discussing scalability
and feasibility of implementing a multitude of different revocation schemes
on different networks. We will probably have similar tools to a universal
resolver that will be able to verify VCs across different revocation
registries. Note, that this could be even more difficult than just
supporting different VC formats or DID methods, as you could have different
revocation registries per DID method and issuer. The issuer will basically
control where verifiers need to look up the revocation information.

Thanks,
Oliver

On Thu, Sep 26, 2019 at 7:49 PM Daniel Hardman <daniel.hardman@evernym.com>
wrote:

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