A few questions on libsovrin


I was recently reading a presentation on libsovrin architecture, and a series of questions came out of my mind:

  • What’s “revoc_reg” and how does it work?
  • What’s the difference between functions “sovrin_issuer_create_and_store_keys” and “sovrin_create_and_store_(my|their)_did”? Is there any relationship between them?
  • What does sovrin_wallet_set_seq_no_for_value does and why is it called so many times during the example sequence diagram?
  • Where do old terms like “link invitation” stand now with regard to new API terminology? What would be the equivalent? Are there any other terms and concepts being replaced by the new API?
  • Assuming a python-based agent, where would known components suchs as “Wallet” and “Client” stand now? Would this components be entirely handled by libsovrin? Or would these classes still need to be implemented which would possibly make calls to libsovrin?

I hope I’m not flooding with too many questions, but it’s certainly important to have all these cleared up. Thanks beforehand!


“revoc_reg” is a revocation registry. In general, issuers need to be configured so that they are prepared to revoke claims that they issue (in case they issued them with an error, or the privilege associated with the claim should be suspended or lost). The revocation registry tells the world how the issuer will publish revocation info; this is used by provers to prove to relying parties that the claim they present is still valid (instead of having been valid only at the time of issuance). Anybody can issue claims, but I think revocation may be most interesting to public institutions; private individuals who issue claims (e.g., “I’m asserting that my friend Fred is a good surfer”) may not care about this.

sovrin_issuer_create_and_store_keys is about creating the keys that will be used as an issuer of claims; create_and_store_[my|their]_did is about allocating a new pairwise identity.

I haven’t studied the usage of sovrin_wallet_set_seq_no_for_value uses in the example; I’ll see if I can look at that later.

The preferred term for “link invitation” is now “connection request.” In general, we have a bunch of things that either party in a pairwise relationship can offer, request, and provide. We decided to standardize on those verbs, so we have “claim offer”, “claim request”, and “claim”; also “proof offer”, “proof request”, and “proof”. The analog for connections is “connection offer”, “connection request”, and “connection”. However, “connection offer” doesn’t make a lot of sense; it would be sort of like someone sending you an email that says, “Hey, would you like me to connect with you? If so, I will send you an email so you have my return address.” Instead, we just go straight to “connection request”, which is like sending an email that says, “Hey, I’d like to connect with you. Here’s my return email address so you can accept the request if you like.”

The python versions of wallet and client are eventually going to be replaced by libsovrin, for reasons of consistency. However, that changeover will not be immediate; we only began writing the python wrapper for libsovrin a couple days ago. When we do complete the replacement, we hope the python code that calls today’s python wallet will have only slight tweaks to call a different interface, but will otherwise remain stable.


Thanks for your detailed reply, @danielh.

About the “revocation registry”, I would like to see more detail on how does it work, so far (according to the sequence diagram) it looks like storing a revocation registry is needed after each successful write to the ledger (whether it’s keys or claims). However, it seems a little odd to me that this has to be done in separate calls, allowing for possible inconsistence. What if there’s an error in making the second call (to record the revocation info)?.. Can’t this revocation info be embedded in actual objects (keys or claims)?

Again, I’m just speculating since I don’t really know what this revocation registry looks like and how it should be used.


For security and flexibility we divided creation of anoncreds objects and transaction to the ledger. First user API creates an object and store it into secure wallet by using Universally Unique Identifier, then sends a transaction to the ledger. After completing of transaction ledger sends a seq_no back and all libsorvin API works with seq_no from ledger. But we need to keep a map where libsovrin associate each seq_no with uuid to have an access to libsovrin objects later.

About revocation registry:
In outline, in libsovrin implementation, it’s an accumulator - big number(a point on the elliptic curve). When we create a new claim we need to multiply value of accumulator with other big value. On revoke value of accumulator divides on predefined big value.
Based on the value of accumulator verifier can determine was the claim revoked or not.

No, we don’t need to store and update a revocation registry after each transaction, we need it as often as a certain task requires, for example, once a day. It means that if your driver’s license, for example, will be revoked, verifier will know it only on the next day


Thanks @Evgeniy. That surely helps. I’ll probably be asking more questions when libsovrin python wrapper is ready for me to start testing it. :slight_smile: