Trust Anchor Obligations


#1

With regard to the “Identity Owner Agreement”, which has been the recent subject of discussion at the Trust Framework Working Group, there’s one thing that makes me particularly curious: How come there’s no particular consideration with regard to the terms of being a Trust Anchor? A Trust Anchor is supposed to have more responsibility over the platform than regular identity owners.

Correct me if I’m wrong, but I haven’t been able to find any “trust anchor agreement” so far. It might perfectly be that I missed it, but if that’s not the case, then it seems “trust anchoring” is a role that might be a little bit underestimated in the present moment. We could argue, of course, that trust anchors have been attested by another trusted entities, but is that enough for sure? As far as I know, technically it’s enough for an entity to have been attested by one other entity to be considered a trusted entity for the whole network… Is this correct? Are there any other policies being considered for this matter?

All this brings up the subject of accountability. Is the originator of the trust “attestation” to be held accountable for the new trusted entity? What if a particular identity owner whose DID was created by Trust Anchor B engages in undesired behavior, Trust Anchor B surely must be held accountable in some manner, but is there also some weight resting over Trust Anchor A (who made an attestation for Trust Anchor B to become so)?.. On the other hand, are there any trust-anchor credential revoke mechanisms in place or in consideration?

It might be a very personal view, but I feel like the Trust Anchor role should be given some more relevance, since ultimately a significant aspect of the integrity of the Sovrin ledger is up to them in some way.

Any thoughts?


#2

@cbruguera The reason it is not a separate agreement is that any Identity Owner can become a Trust Anchor. So we needed to make it part of the Identity Owner Agreement. Trust Anchor Obligations is in fact a defined term in the Provisional Trust Framework, and they are defined in this section of the Provisional Trust Framework Public Review Draft 01.

In the proposed new language for Identity Owner Obligations that I posted last night for Public Review Draft 02, it says (emphasis added):

That attestation is called a Trust Anchor Connection, and yes, you are correct that in the Provisional Network only one Trust Anchor Connection is required to become a Trust Anchor.

But that’s a very simple rule intended only for the first stage of the network when it is still small and “everyone knows your name” (as the Cheers theme song put it). As the network grows, the Sovrin Board of Trustees should be able to change the threshold number of Trust Anchor Connections needed for an Identity Owner to qualify as a Trust Anchor. This policy has already been added to the second Public Review Draft being prepared for the Trust Framework Working Group to review tomorrow (Tuesday).

The short answer is “Yes, absolutely”. This is what the Sovrin Web of Trust model is all about—how to design the Sovrin Trust Graph so that is helps protect a distributed web of trust relationships in much the same way the Sovrin ledger helps protect a distributed database of transaction records.

But in large part we decided to put that policy definition work out of scope for the Provisional Trust Framework so that we could finish it quickly. Once that is done, defining the rest of the policies for the Sovrin Web of Trust will IMHO be the majority of the work remaining to complete the Sovrin Trust Framework V1 that will govern the General Availability Network.

I completely agree. IMHO Trust Anchors will be the heros of the Sovrin Network (keep in mind that every Trustee and Steward is automatically a Trust Anchor). I look forward very much to working with you and the rest of the Trust Framework Working Group to make it so.


#3

Thanks @Drummond, as usual, your response is very concrete and detailed. This surely helps to clear things up.

So, all in all, this provisional phase will serve as the testing ground in which all these agreements and technical implementations will evolve themselves according to the needs of the ecosystem.


#4

@cbruguera Yes, exactly. It’s a phased approach because it takes time to build up trust in a trust network.


#5

Hi, this is my first posting. Still trying to understand the details of Sovrin. What is becoming clear to me, that in Canada, in developing the Pan-Canadian Trust Framework with DIACC, our focus is mostly that - on trust anchors, namely authoritative parties within jurisdictions.


#6

Tim, welcome. At some point I would love to discuss the synergies between a technical trust framework like the Sovrin Trust Framework and the Pan-Canadian Trust Framework. Perhaps after the Sovrin Board of Trustees approves the Sovrin Provisional Trust Framework, which is slated for March 22.


#7

Drummond,

Sure thing. That will give me some time to better understand Sovrin. It is becoming clearer to me that the Sovrin framework enables trust to be conveyed. More to come,