[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.
 
Hi,

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?
 
Hi,

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.
 
Thank you for the remainder, Tor. I posted a short update regarding this in the #verifiable-credentials channel of the FCD Discord a while ago, which I should have cross-posted here. Let me expand on this.

Unfortunately, the work on this grant is considerably delayed. The original deadline that was discussed in the Grant Proposal thread on Factomize was September 15th, so I believe we owe an explanation to the Standing Parties. The reason for the delay is two-fold.

On the one hand, we've had a big delay with finalizing the DID v2 specification, in which Factomatic has been heavily involved, together with Factom Inc. and BIF. IMHO, even the current version of the specification is not final, but it is sufficient to proceed with an implementation. As such, our resources over the last couple of months have been almost entirely allocated to DID-related work, which we have prioritized even over client-related work and internal product development. This DID work can be tracked in the #dids channel of the FCD Discord, as well as in two of Factomatic's repo: https://github.com/factomatic/py-factom-did and https://github.com/factomatic/web-signer-extension. Both of these repositories are very actively under development and include critical (and full-stack) infrastructure for working with DIDs, namely a registrar, a client library, a resolver and a driver. The reason I'm saying all this, is that, unfortunately without a functioning DID stack, in particular without a functioning DID resolver, it is not possible to have functioning VCs on Factom. Thus, we first need to build out this stack.

The second reason is a more personal one -- I became a father for the first time end of September, which meant that I'm not working or working in a greatly reduced capacity over the course of 2-3 weeks. This has also contributed to the delay.

Overall, I'm very disappointed with the big delay, especially since I argued heavily that the Factom blockchain could become one of the early adopters and leaders of this standard in the proposal thread. I can also understand if the Standing Parties are frustrated, but the reality is that a number of factors that have contributed towards the delay are somewhat out of our hands.

I'm asking for some patience regarding this work and I assure you and the other Standing Parties that in the next months we will be heavily working on this super exciting technology.
 
Hi @Valentin Ganev Hi @Niels Klomp,

Following Niels' answer during the last grant round and the approval of the Python DID Lib funding to Factomatic would you please let us know:
- What are the next steps with an estimated planning?
- What is the impact of the Java Client and Universal Resolver to be produced by BIF on this work ?

For your information, Harmony's integrate did pass the test suite for the VCs but this is an internal solution from Inc.
Now it is time that the whole Factom community accesses this feature through an open source standard possibly passing even more tests.

Thanks.
 
Sorry, I missed that, although I did have a chat with Matthias about the timeline in an unrelated conversation.

On our side, we will be starting work on VCs around two weeks from now. In the meantime, we went through the specification created by Factom Inc. and provided some feedback, including a small optimization of the proof representations. We also participated in a call with Factom Inc. and a member of Hyperledger/Sovrin to discuss their open-source Rust stack and VC/cryptography libraries, as we have plans to leverage some of their work in our implementation.

I will post a message here once we kick off the development and I would advise anyone that would want to follow it more closely to join the Factom Core Developers Discord and track the #verifiable-credentials channel.
 
Indeed, Factomatic is planning on resuming the work on this grant next week. We have another couple of projects we need to wrap up prior to that, but we're on track to finish those this week.

As mentioned in the DID grant thread, I cannot comment on the state of the Java resolver or when it will be released. However, since we currently have the Python implementation, I don't foresee the lack of a Java resolver being a hindrance for the work on Verifiable Credentials.

Regarding the splitting of work, I see 3 main components at the moment:
  • release of a specification. We had started on one internally, but will most likely forgo this in favor or aligning more closely with the specification published by Factom Inc. There will be some changes necessary -- at the very least an addition to the spec for the new type of proofs -- but we will try not to diverge too much for the sake of interoperability.
  • evaluation of the existing approaches done by Hyperledger/Sovrin and deciding which of the proof types we would like to integrate with. They have several different cryptographic proofs available and we would need to do some analysis in terms of their applicability to Factom (proof sizes, running times, supported functionality, complexity of integration with Factom, etc.)
  • migrating one or more of the Hyperledger/Sovrin solutions to Factom
BIF has previously pledged to devote 1 FTE for 1 month for this project and in our discussions with Niels, this time would most likely be split between one researcher and one software engineer, so I believe they should be able to provide support on all 3 components. I personally think that the help will be most needed/useful for the last two items (not neglecting the importance of the spec, but we already have a reference now, which can be leveraged).

In addition to the above, we still plan to develop a simple zk-SNARK circuit or two demonstrating the feasibility of this approach for VCs.
 
Sorry for the delayed reply.

Work on the grant has been resumed as of last week. There are two things I can highlight at this point:
  • both a UI design and architectural/functional design for integration of VCs into Kambani is under way. This includes:
    • a mock-up and front-end implementation of a Verifiable Credentials tab in Kambani
    • identifying the data necessary to store for verifiable credentials and verifiable presentations (including selective disclosure) in the encrypted vault and modifying the vault accordingly
    • new Kambani request types that support requests for proof of possession of a credential satisfying certain properties
    • new Kambani request types for receiving and optionally approving a credential
  • we have been working on specifying several zk-SNARK circuits and an overall architecture for how to integrate those with a credential issuer workflow. This is still in the early stages and is likely to evolve significantly over the next month
One thing that we will be looking at next, especially since the Rust client for Factom has been officially released, is the integration of some of the cryptographic proof types supported by Hyperledger.

I would also like to point out that the scope of this grant will change, as we will leverage as much as possible an existing specification for VCs. Since we don't need to create it from scratch, the time that would have been invested into this from our side, will instead be put towards implementing either a client library for VCs in Python (similar to the client library we implemented for DIDs) or for the integration of VCs into Kambani. In my opinion, the funds are much better spent this way instead of coming up with a brand new specification, but if any of the Standing Parties have some concerns about this, please bring them up.
 
Top