I had the idea that trust anchors were manually selected by the Sovrin Foundation, is that not right? Whatever is the case, which are the rules for granting someone the right to write on the ledger? Is this already defned? Also, are there any “levels” of such permissioning? or is it a completely binary attribute? (an entity either is or is not a trust anchor)

Moreover, is a “trust anchor” role required to write any sort of claim on the ledger, or only for creating new identities? Is there any differentiation between creating identities per se and making regular claims about these identities or any object whatsoever?

Carlos, that’s a whole pack of questions. I’ll take them one at a time.

cbruguera:

I had the idea that trust anchors were manually selected by the Sovrin Foundation, is that not right?

The very first trust anchors will be invited by the Sovrin Foundation, yes. But then trust anchors will be able to invite other trust anchors in a web-of-trust model. This rooted web of trust design is being developed by the Sovrin Trust Framework Working Group, so please do engage there if you are interested (I chair that WG). We’ll be publishing draft documents about it later this month.

cbruguera:

Which are the rules for granting someone the right to write on the ledger? Is this already defned? Also, are there any “levels” of such permissioning? or is it a completely binary attribute? (an entity either is or is not a trust anchor)

Hey Drummond, effectively your other post answers many of these questions.

Now, since “Every identity owner can create new identities for themselves”, I was wondering: How does the Sovrin Ledger (or the nodes securing the ledger) know that the identities I’m trying to create are for myself and not for anyone else?.. How is this differentiation on “write levels” is actually enforced by Sovrin?

@cbruguera Congratulations! You take the prize for spotting the single hardest issue in the Sovrin Trust Framework (so far).

The short answer is that DID creation transactions from Sovrin identity owners (who can only created new DIDs for themselves) will use one type of cryptographic authorization token and DID creation transactions from trust anchors (who can create new DIDs for others) will use a different type. We are still working out the details, because the hard part is to make these tokens anonymous credentials to protect privacy.

@cbruguera It’s just another name for a revocable anonymous claim. What’s special about it is that the issuer is a trust anchor and the relying party is the Sovrin ledger!

This is a subject the Sovrin Trust Framework Working Group is actively discussing with the Technical Governance Board because it’s at the heart of how Sovrin can support both verifiable public identity and pairwise private identity at the same time. Stay tuned—I should have more info about this after meetings with TGB chair Jason Law next week.

Oh I get, and clever way to put it (as a revocable anonymous claim). I can intuit that many other forms of “permissioning” can be implemented for Sovrin that way.

By the way, is there any updated source of info on anonymous claims? I’ve read some info about some IBM platform that does the same (was it bluemix? I’m not sure), but I’m certainly more interested in more Sovrin-oriented readings on the matter. Any good references?

The Sovrin anonymous claims work is being spearheaded by Sovrin Technical Governance Board chair Jason Law and cryptographer Dmitry Khovratovich. They have published some papers about it but I’m not current on the links so I’m hoping @Khovratovich can help me out here.

Anonymous claims are implemented today; see https://github.com/evernym/anoncreds. Sovrin currently depends on this codebase, but at a revision slightly earlier than what we need to fully provide the features Drummond has described. (What makes this more complicated is handling revocation. We’ve written support for that, but integrating it into sovrin is not quite finished…)

We expect anon claim support to show up in Sovrin soon after the Jan 2017 go-live date. The TGB will approve the feature when they believe it is ready, and the public can monitor the TGB’s voting and process.