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.