Traditional blockchains (e.g. Bitcoin) are known for their chronologically and cryptographically sound data storage capability; as transactions are provably linked in time and evolution of data is controlled by the consensus protocol, it makes perfect sense to utilize these blockchains as “audit logs” for different types of “assets”. However, in Sovrin, records are allowed to be completely unrelated among each other, and there are no know rules on how a record (DDO or claim) should evolve through time. Given this, does it make any sense to utilize Sovrin ledger as an audit trail even for identity-related data?

For example, let’s say proofs of identity documents are anchored (not directly storing any sensible data) on the ledger, how could an agent show in a provable way the evolution of these documents through time? I’m guessing the corresponding agent should also internally store all events (a sort of “private ledger”) and anchor a hash of each event claim to the ledger as well?

Does it make sense at all to utilize Sovrin in this manner?

Many use cases call for the need to leverage the ledger for different kinds of audit tracking, but so far it seems the general vision on the Sovrin ledger is limited to only providing public keys and service endpoints tied to certain digital identifiers… What are your views on this?

We have always assumed that there would be a private ledger that would periodically anchor to the overall sovrin ledger. The private ledger could use any convenient technology (e.g., the “ledger” component from Sovrin’s github, Hyperledger’s Fabric, etc) to generate a ledger that contains merkle-ized rows, and the root hash would periodically be anchored onto Sovrin. This allows proofs of a selective subset of the private ledger, resolved into the timestamp and DID ecosystem that Sovrin provides, proving that certain identities did things or knew things at a certain time.

I don’t imagine it would make sense to use Sovrin itself for private ledgering–that would be a distortion of its purpose for pure identity. In fact, there may be limits in the future that constrain how many attributes are added to the ledger, and how often, to discourage this. But anything we constrain will certainly allow the private ledgers anchored to Sovrin, because the use cases for such a feature are incredibly compelling.

@danielh, This private ledger anchored to Sovrin sounds like a very useful idea. However, when you talk about using Sovrin itself for private-ledgering, I’m not completely sure what you mean. How could it be private if the ledger itself is public by nature? Do you mean using it for storing public proofs for “private data”? This is asuming the public proofs don’t reveal meaningful information, of course… How would this differ from the private Sovrin-anchored ledger idea you initially propose?

If the “private” component in this scheme is privately handled by agents and the Sovrin ledger is used to store anchors for this private data. Does it not fit into Sovrin purpose?.. In the original “private ledger” idea, would these anchors be completely “identity-related” to preserve Sovrin purpose?

What I mean by “use Sovrin itself for private ledgering” is, writing a whole bunch (hundreds or thousands or millions of transactions to Sovrin, just to prove them for a private purpose. Imagine that a person decided to record every financial transaction they ever do (a hash or proof-of-existence for it, anyway) as a new attribute under their DID–so one identity might accumulate thousands or millions of public transactions that are of no use to anybody else in the whole universe. This doesn’t scale well, and it makes every validator node in the world bear the carrying cost, in perpetuity, for your private record keeping. What we want instead is to have you maintain a private ledger, using whatever mechanism you like, and then to strategically anchor that private ledger to Sovrin’s public source of truth (e.g., anchor once a day, or once a year, or once every 10k transactions). This is cheap for Sovrin, gives the user of the mechanism enormous flexibility, and still provides the same strong guarantees about the truth and ordering of items that are anchored.

This seems like a rather important issue to resolve, that anyone could decide to do their “private ledgering” on Sovrin with nothing to stop it, which is the kind of things proof-of-work prevents… seems like a spam issue, too, no?

Just looking at the first two posts in this thread, there may be two related but slightly different uses of the term “private ledger”:

A “private ledger” used by a single identity owner for keeping track of contents and events related to their own data. In this sense, a “private ledger” is a very similar concept (or function) of what we otherwise call an agent, hub, identity container, personal cloud, etc. @phil had a blog post about this kind of “private ledger” a while ago: http://www.windley.com/archives/2016/10/how_sovrin_works.shtml

A “private ledger” shared by multiple participants of a certain community or industry. This is the case e.g. with R3 or CULedger, i.e. they use a ledger to reach consensus on data and events that are useful within this community but not meant for the general public.

Both uses of the term “private ledger” are not mutually exclusive and could complement each other, and both could use a public ledger such as Sovrin for anchoring, to publicly prove that certain things were known or done at a certain time.

BTW if the data structures you want to anchor on the ledger can be modeled more or less like a tree, then check out Chainpoint, it provides a pattern for designing the anchors in a way that lets you prove the existence of a certain piece of your data at a given time. [Small side note: the XDI graph model with its tree-like context structure may be better suited for this than the flat RDF graph model].

+1 to having constraints on how much and how often attributes can be written to Sovrin.

-1 to the term “event claim”, I think “claims” are central to identity systems but I would suggest not overusing the term.

It seems then that we’re dealing with two different and overlapping issues here:

Using Sovrin for storing data for private purposes, thus beating the original purpose of the Sovrin ledger, which is providing a single source of truth for identifiers and their public attributes (such as service endpoints and public keys).

Spamming the Sovrin ledger.

Having a private ledger to periodically anchor its state onto the Sovrin ledger might mitigate issue #2, but certainly it doesn’t do much for #1. So, is this private-ledger scenario mainly envisioned for anchoring data that is relevant to the identity context or is it only the spamming of the ledger what we’re regarding here as the main issue?

I work with @cbruguera, the OP. I am not a developer, I work on the management side of the project.

It seems that ‘private ledger’ is not a very precise term. When I say private ledger I mean one which operates internal to an organisation and while it may embody a distributed database, it enjoys no network effects. A better term for the non-public ledger is a ‘consortium ledger’. It has both benefits of distributed data and network effects based on consensus.

Our application can be characterised as a registry for a sequence of identity-related events. These are not frequent for an individual, and include events like opening a bank account, buying or renting property, etc. We would store anchors to these events in Sovrin (presumably written to the Hyperledger blockchain) and tie these anchors to a set of attributes and possibly physical files off-chain.

Certainly this is not too much a burdon on the Sovrin system? If I make my point clearly and it’s agreed that this is the intended use, then we don’t have to spin our head about ledgers attached to ledgers, and we can proceed on to consider what is a reasonable record format for events anchored to the chain. We can also explore how to manage what Hyperledger documentation describes as ‘state’ (which as I understand it can include deletions of records on the chain).

Now, my guess is that these identity-related events such as opening bank accounts and renting property can be modeled as regular Sovrin claims, issued by the corresponding “authority” according to each case. This assumes, though, that each involved entity is an identity on the Sovrin ecosystem already.

Maybe the complication arises when we start seeing these as “events” instead of “facts” that certain entities can attest to in the form of claims (e.g. “HSBC certifies that Bill Claxton is an account holder at such bank”). These claims would of course have a timestamp attribute on it that could serve for audit purposes later.

What I think the “private-ledger” idea boils down to is that HSBC shouldn’t use the Sovrin ledger for storing proofs of internal events that are mostly relevant to the bank (e.g. “Certain legal document was edited or updated”). Therefore we need to draw a line between what is relevant to the public identity ecosystem and what is private data management. The latter should be kept in a more private environment (which could be at “consortium” level or even individual agent level).

The question remains, though, why would Sovrin allow for periodical “anchoring” of private-ledger data. If the issue is merely a matter of “spam prevention”, where do we set the threshold on how much is too much?

You’ve got that right Carlos. Sovrin is primarily used as a way to verify claims without needing to contact the claim issuer. it “could” be used as an audit log - there’s no way that such a use could be restricted. However, our guidance is to avoid putting private or personal data on ANY ledger, even if it is hashed.

The concept of a “private ledger” which is anchored to Sovrin could enable you to hold such proofs. This topic is one which we need to keep discussing to determine the best approach that suits all Sovrin identity owners. If someone can develop a suitably slick and effective off-ledger store of proofs that can be used as required, with a lovely user interface, that would be very cool.

At some point our team was discussing the possibility of implementing a sort of “hierarchical” topology of networks, so that private “subdomains” could be possible while still keeping Sovrin as the ledger platform. Of course we would need to define and implement practical means to connect these networks and relate data from the public Sovrin “domain” to the more private scopes and viceversa, something like “sidechains” but in a tree structure. I don’t know what are your views on this, but it might be a subject “meaty” enough for another thread.

In any case, it’s likely that a component that is able to “glue” the Sovrin ledger to other ledgers or networks in a generic way would be more practical.