[BIF-Factomatic-003] Verifiable Credentials FIP

The work on the Verifiable Credentials FIP was somewhat delayed due to the on-going discussions between Factom Inc., BIF/Sphereon and Factomatic on consolidation of the two DID specifications.

That said, we haven't been dormant and made progress on several fronts. We looked at existing implementations of verifiable credentials, in particular at:
Hyperledger Indy is the most advanced implementation and it provides tools for issuers and holders of credentials, wallets for managing those and for constructing verifiable presentations, as well as a comprehensive cryptographic library in Rust, with wrappers in Javascript and Python. The implementation also provides limited support for selective disclosure based on an extension of the Camenisch-Lysyanskaya (CL) signature scheme (more information for the technically inclined: here and here). This signature scheme allows a credential holder to prove some predicate over an attribute (e.g. over 18 years old), without disclosing the exact value of the attribute (e.g. their date of birth). More generally, it is possible to prove a boolean predicate consisting of AND and OR gates and >, =, < relations on attributes (e.g. (I live in the US AND I'm over 21 years old) OR (I live in EU AND I'm over 18 years old)). However, the existing implementation in Hyperledger Indy only has support for AND gates and only for >= as a relation. Even in its fully fledged version, this scheme does not support arithmetic operations on attributes (e.g. it is not possible to show that the sum of several account balances you own is above/below a given threshold). We view this as a big limitation of the expressiveness of the protocol, but are happy to hear if this is seen in the same way by others, depending on their use cases.

Blockcerts has a healthy ecosystem of tools around verifiable credentials, in particular a multi-platform wallet and a universal verifier for verifiable presentations. The project consists of a set of blockchain agnostic protocols. Concrete instantiations are live on the Bitcoin and Ethereum blockchains, which suffer from fluctuating costs and are more expensive than Factom. Other implementations are welcome. Blockcerts currently has no support for selective disclosure.

Iden3 is an Ethereum project utilizing zk-SNARKs for identity management and verifiable credentials. It has an in-browser SNARK prover and an alpha wallet. It also has a Go cryptographic library, which implements useful primitives for zero-knowledge systems. We believe this could be of separate interest to the community. Because Iden3 relies on SNARKs for generating proofs related to credentials, it has full flexibility over the predicates, which can be proven, which is an advantage over the CL signature scheme. The disadvantage is that SNARKs require a trusted setup.

Our original idea was to follow a path similar to Iden3 and to use zk-SNARKs for selective disclosure. We still think this is the best path forward, but we are curious to hear other opinions, including thoughts on a potential strategic move of leveraging Blockcerts and getting Factom's name next to Bitcoin & Ethereum, which should put Factom in a great light, emphasizing its advantages. If there is interest from the general community, we will investigate what a potential Blockcerts integration for Factom would look like.

In addition to the above, we also familiarized ourselves with the verifiable credentials data model, looked into a selective disclosure method based on Merkle trees and into cryptographic accumulators as revocation registries.

The main item for the next month will be to create the specification for the FIP.
Last edited:
Will you have to re-implement all the cryptographic primitives those projects have implemented or you will be able to leverage existing implementations?
Unless there is a strong sentiment against using zk-SNARKs for selective disclosure, we plan to use it for the implementation. There are a number of libraries that aid the creation of SNARK circuits and some of the functionality that we need in order to get selective disclosure is already available (e.g. hash functions, Merkle tree authentication paths, etc.). So, we will definitely not be implementing everything from scratch. However, we will also most likely use a library, which is not mentioned above (either one from Zcash: https://github.com/zcash/librustzcash or a newer one: https://github.com/scipr-lab/zexe/ with which we have some experience from prior work). Essentially, the main part of the implementation would be to implement a SNARK circuit (or several), which allow a prover to prove some statement about credentials that have been issued to them.

As a side note, we are currently considering extending the existing CL signature scheme in Hyperledger with other relations (<, =) and also adding support for OR gates. Ideally, we would like to release a library, which has support for both zk-SNARKs and CL signatures, but we still need to evaluate the effort required, as providing two implementations would be outside of the scope of the original grant proposal.

I'm looking at the Timeline provides in the grant document and I'm a bit confused as to how they work out.

My understanding is this:
M1 (M1.1/M1.2) - After two weeks
M2 (M2.1) - Work to happen in the next 6 weeks with milestone at the end.
M2 (M2.2/M2.3) The final 1-2 weeks?

I'e is M2.1 due now this week (8 weeks after the work started), and M2.2/M2.3 in an additional 1-2 weeks?

M1.1 was estimated at 2 weeks.
M1.2 was estimated at 2 weeks.

So, M1.1 and M1.2 are estimated at 4 weeks. M2.1 is 6 weeks. M2.2/M2.3 are the final 1-2 weeks.

The last two milestones are also dependent on external contractors, so we cannot guarantee that they will start immediately after the implementation is done, i.e. there might be a period of one or more weeks while we wait for the security auditors to be available and to start reviewing the code.

The above -- as well as the (partial) dependency on stabilizing the DID specification and implementation -- was why I raised concerns about setting specific dates for deliverables, however, after some lengthy discussions in the Grant Application thread, in the end we committed to a timeline which should end on September 15th. I still believe this is manageable, despite the fact that we started work on the grant with a considerable delay due to the DID v2 work.