As far as I understand, “minting” a new Sovrin ID is technically equivalent to writing some sort of “genesis claim” on the ledger. In such case, is an “author” field mandatory for such claim? Meaning, the identity creator (a trust anchor as I understand so far) should need to own a provable identity on the ledger in order to register new entities… Am I on the right track?

So, if all claims (including ID creation AKA “genesis” claims) must be made by an existing identity on the system, who makes/made the first claim? Is there any sort of “root DID”?

On the other hand, does the trust anchor itself need to have a running agent in order to request the creation of new DIDs? Do those requests need to come from an agent per se?

I’d appreciate any level of detail that can be shared regarding the minting of new IDs on Sovrin.

Carlos, great question. In fact it is one of those perfect “devil in the details” question that also happens to be at the heart of the Sovrin Trust Framework, since that’s where we’re working out the precise governance rules for the ledger.

First, you are exactly right, every new Sovrin ID is the “genesis claim” for a new Sovrin identity. Technically this claim is the registration of a DID (decentralized identifier)—see the DID Implementer’s Draft 1 spec for details.

And you are also right that, because Sovrin is a public permissioned ledger, every entity who has permission to write to the ledger must already have an identity on the ledger. And this leads to the “turtles all the way down” problem of who has the first identities on the ledger?

The answer is: the Sovrin Foundation trustees—currently the 11 individuals listed on the Sovrin Foundation About page. As currently implemented in the Sovrin Voting ledger (a separate ledger from the main Sovrin identity ledger), the trustees vote on the first stewards—the legal entities who will run Sovrin nodes. Then either trustees or stewards vote on adding more stewards, and the pool of stewards slowly expands (within the policy constraints of the Sovrin Trust Framework, e.g., the number of stewards in any one jurisdiction or industry will be limited).

All trustees and stewards are also what we call trust anchors—entities who have permission to write a new identity to the Sovrin identity ledger. But not all trust anchors have to be trustees or stewards. A trust anchor can also be an individual or organization that does not serve on the Sovrin Foundation board or run a Sovrin ledger validator node, but who is still trusted to provision new Sovrin identities and not use their write permission to spam or attack the Sovrin ledger.

So how are trust anchors chosen? The Sovrin Trust Framework Working Group is currently evaluating a web of trust model that essentially is the same as the steward selection process: a minimum number of existing trust anchors must vote to add a new trust anchor. This is exactly the process already defined in the Respect Trust Framework that was first listed with Open Identity Exchange in May 2011.

If the Trust Framework Working Group decides to adopt this web of trust model, then accountability for each new identity written to the Sovrin identity ledger ultimately lies with the trust anchor who provisioned the identity owner. Let’s make this concrete with an example. Say A is a trust anchor who knows identity owner X and believes X can be trusted to live by the Sovrin Trust Framework and not abuse the Sovrin ledger. So trust anchor A agrees to provision Sovrin identities for identity owner X.

Note that X will not need just one Sovrin DID, but as many DIDs as will be required to keep X’s relationships contextually separated. So trust anchor A doesn’t need to register just one new DID for identity owner X. A starts out by registering 100 of them.

This “supply” of DIDs should last X for a reasonable period. The only one that knows that all these DIDs belong to identity owner X is trust anchor A—and even A doesn’t know which of those 100 DIDs that X is using for a particular identity. But a chain of accountability has been established. In other words, if there is ever an issue about of of those 100 DIDs abusing or attacking the Sovrin ledger, then the authorizing authority, trust anchor A, is accountable for having authorized provisioning of that DID to identity owner X, and now trust anchor A can hold identity owner X accountable.

Again, this web of trust model is still in early discussion in the Sovrin Trust Framework Working Group, so no firm decision has been made yet. Please do let us know your feedback, and any other ideas you have.

Carlos, yes, all DIDs that are truly “self-sovereign” must be generated by the identity owner and cannot be generated by a trust anchor or anyone else. The identity owner must be the party in control of the private keys from the moment they are generated.

However that does not mean that the identity owner’s client app needs to generate all 100 private keys at once. Rather it can generate and register them in the background as needed in order to build up a reserve while not interfering with the identity owner’s usage of the app.

Also, I had one private response ask whether it wasn’t a correlation risk for the trust anchor to know all 100 DIDs, because then they are not truly anonymous. That’s true. There is in fact a way a trust anchor could authorize an identity owner to register 100 DIDs completely anonymously—by issuing an anonymous credential (this is already supported by the Sovrin code base).

The problem with this is accountability. If the identity owner it truly anonymous, then there is no way to hold the identity owner accountable if he/she then decides to spam the ledger by writing, for example, 10 million bogus attributes to one of his/her anonymous DIDs. The anonymous credential would reveal which trust anchor issued it, but it would not reveal the identity owner who actually registered a particular DID. So there is no way I see (so far) to hold them accountable.

I completely agree that from an anonymity standpoint this is less than ideal. One solace is that there is no need for an identity owner to be reliant on a single trust anchor. An identity owner may use as many different trust anchors as needed to spread the correlation risk.