Authoritative Tracking of "What is on the Ledger"


I’m looking for a pointer to a document I can check from time to time to see what the latest thinking is to answer the question “what is on the ledger”.

Most recently this came up, for me, in the Trust Framework context - where “Zero Knowledge Proofs” were considered for ledger content. This is clearly not right - as ZKP, in any form, is private, individual knowledge. On the other hand “public data”, such as “I want the whole world to know that DID_123 is the authority of the United Nations General Secretary” could very much be on the ledger.

I wondered, at the time, is there “some place” that I should watch to monitor what is “on the ledger” - some formal document? If so, where is it, if not, let’s create it.

Currently I believe the following to be on the ledger

  1. DID => DDO map
  2. claim definitions
  3. public claims - public announcement of PII for a DID
  4. revocation accumulators

Notes about each element

DID => DDO map

  1. first DID => DDO record is the ‘genesis claim’
  2. updates to the DDO are sequential, last is the ‘current DDO’
  3. DID => null/{} is equivalent to ‘terminating a DID’
  4. service_endpoints are listed in the DDOs, or can be found implicitly through systematic lookup

claim definitions

  1. these must cover all public claims
  2. used to form an ecosystem for inter-agent claim exchange

public claims

  1. the only PII appropriately stored on the ledger
  2. serves as shorthand for common cases of looking up service endpoint, and contacting agent, obtaining and verifying claim
  3. example : “I am the president of the united states and my address is 1600 Pennsylvania, …”

revocation accumulators

  1. allows public revocation of otherwise private anonymous claims

Does this sound right?


Hi Eric,

We don’t have such a thing just yet. We have been talking about a ledger “browser” which you could use to examine the content of the ledger. It’s in the (long) list of things to do, and of course anybody could develop such a thing.

I like the elements you’ve listed. The DID to DDO map will be useful and as the entries are chronological it will be simple to find the last current DDO (and therefore which prior ones are obsolete).

Claim definitions become even more useful when individual identity owners are creating their own claims, particularly when they are stating an intent to buy or acquire something. Once there’s a browser there will be search, and once there’s search then vendors can search for people who are stating intentions.

That list does look right by the way.


Hi Andy,

I think a “ledger browser” is a great idea - but I would also like to clarify my concern. I’m not so worried about the quantitative issue of the contents of the ledger at a point in time, rather, I am looking for a community visible, formal summary of the latest thinking of the sorts of entities that are intended to go on the ledger.

Perhaps a document in a git repo would be the thing - it would be versioned, have history, and allow the thinking to change.

Various information, such as claims and ZKP assertions, have, at times, been candidates for “going on the ledger” - but it is hard to track the current community consensus. For example, ZKP, since it contains PII, should not be on the ledger, but should, instead be off ledger.

I would like to suggest that Sovrin maintain a versioned copy of a document that contains the above list - perhaps in the README of a repo for a ledger browser - and we can broaden the search to find folks who have bandwidth to code that up! :wink:


Ah yes, I’m with you Eric.

The only thing that I think is missing from your list of things to be stored is proof of consent. This is particularly applicable in a GDPR data sharing world, where both parties (ID owner and relying party) may want to prove consent for data sharing.

Being able to point to an immutable consent proof on Sovrin would allow the relying party to confirm that consent was given by the ID owner. It would also allow the ID owner to confirm to whom they have given consent in the event that they wanted to issue a “please forget” or “please delete” request to satisfy right to be forgotten type requirements.

One other thing I have been thinking about is storing proof of “please delete” requests as well e.g. DID 1 requests DID 2 delete all info associated with DID 1. This may be useful for ID owners to prove to regulators that a delete request was issued in the event that the relying party did not comply.

I like the idea of a “what’s on the ledger” doc. Do you fancy starting one in /sovrin-foundation/sovrin/docs?



I would be more than happy to maintain the “Ledger Contents” reference document, and your comments perfectly illustrate the sort of discussion and decision that we can record there. For me, when planning and proposing an “information architecture” around identity, having a stable source of “what is supported/what is not” that I can point to and share with other stakeholders is tremendously valuable.

Recognizing that it is open-ended and flexible is one thing, but that can pose problems when promoting a Sovrin solution - since every solution has to start from 1st principles and educate/define/defend the entire architecture.

re: delete control for GDPR - I agree - public termination of an identity is an extremely important concept - in fact, it can even be used to ‘track’ deletion status. The topic all connects to a concern I had for guardianship - i think that “guarded->owned” needs to be updated to be “guarded -> (owned,destroyed)” to capture exactly that situation but without the additional overhead of “taking ownership for the purposes of immediate deletion” - it embodies the action of “You did what on my behalf? undo that!” without the need to “establish transient control”

in terms of immutable consent proof - that touches on the issue of link contracts - another thing I’m not totally clear on - or rather, I’m not clear what the state of thinking is… link contracts, when signed, include consent, while consent without reference to “what has been authorized” is somewhat odd. Both, however, are slightly at odds with the PII-restriction.

All of this has been hashed out in various discussions, it is just not clear what the current thinking is in terms of implementation.

I will do my best to capture this landscape in a Git document - and point back to Forum topics for the discussion behind why the document is in a specific state.




I would recommend moving it to a different repository however - the ‘sovrin’ repository was split - for good reason, but it gets confusing when code commits and documentation happen next to legacy code.

There are also some google doc whitepapers coming - google docs makes a great collaboration platform for that sort of thing. On the other hand, git provides a great means of keeping snapshots of documents, and providing “reference copies” and tracking formal updates.

Please advise - i think Sovrin can do a little better at maintaining a formal document library - the documents are incredibly useful, the first draft of the library whitepapers were instrumental in making Sovrin happen. I think that Sovrin will benefit from having clear answers to the next level of specific questions:

For example:

  • who are the founding stewards
  • where are they located, and what cloud providers are they on
  • what is the ASN distribution of the node
  • what is the geographic and corporate distributions of the nodes
  • what is our best assessment of our ability to achieve ‘diffuse trust’ for the stewards

in addition to

  • what data is on the ledger, what is not, and what are pointers to the relevant discussions
  • latest whitepapers
  • previous whitepapers
  • library of claim definitions (could be drawn from the ledger, and should be drawn from a client - which would be downloadable where?)

would sovrin-foundation/sovrin-docs be a viable repository - to join the -common, -client, and -node repository suite?


+1 to establishing a separate repo for Sovrin Foundation docs. @danielh - is this something the Technical Governance Board could decide on relatively quickly?

I like the idea of putting the whole second generation of white papers and overall Sovrin technical documentation in that repo.


I agree that this is a distinct move that needs to happen. I was just in a room today, with people interested in paying my team for a demonstration - they’d been following through the Getting Started guides and had some ideas - but ideas that, as far as I can tell, are a little out of date.

The need for a “latest snapshot of the library” - something that could effectively go under the ‘Library’ tab on the web site - is something that is needed. More important is the versioned history - not the change history, just the clear, public versioning - checkpoints in time with some pointers to other resources, such as google docs and forum posts, that track the changes.

We need to make a coherent picture available to people who are in a position to “check in from time to time” but who are not in a position to invest heavily in Sovrin - Sovrin being “somethign on the sides of their otherwise busy worlds” - such as the fellow today, on his way to prep for a meeting with a national regultory agency - and digital identity for the nation was, once again, on the docket.

I will volunteer to be the repository secretary, and marshal inputs from the Sovrin community - organize it as pull requests for upstream - e.g. i’ll be secretary, not editor. It’ll help salve over the frustration some of have felt about the need to monitor the slack channels - as I ungraciously expressed to @danielh in private chat one very, very late night. everyone is crazy busy, but that includes - not just us - but also the targets of our efforts - folks willing and interested in giving Sovrin a hearing, but who need a softer, clearer, presentation - people for whom ‘participating in the community’ or ‘joining a slack channel’ are non-options.

@Drummond also mentioned some updated white papers. Google docs is a great place to develop those - but, unless I’m missing something, it is not a great way to provide a discrete evolution of the ‘stable releases’ of said documents. Github is that, and systematic publication via (how about a simple github pages map of the state?)



I will survey the TGB today and see if we can get a crisp decision. I love the idea of using a github repo as the canonical location. Besides helping the community, it will work very well as a crisp scope-of-concerns for a tech writer, if we can task one to live there. Let me socialize this with the TGB today and see if we can make it happen.


How are we on this. I’d love to have a punctate redux of ledger contents to which I can point with some identifier… URL? github link?


Hi Eric - this is on the top of my list at the moment. I’ve just finished a paper on how verifiable claims are the “currency” of identity, which is going through internal review at the moment. The “what’s on the ledger” paper is coming next.

We’ve had some stimulating discussions on this topic over the last few days actually, regarding how we handle proof of existence (or not) which are influencing the content of the paper.

I’ll get it written asap.