Identity Owner Agreement


#1

As part of the release of the Trust Framework (I could not take part in the call so apologies if the following was answered already), I noticed the creation of an Identity Owner Agreement that would need to be signed between the Sovrin Foundation and the Identity Owner.

I found this particularly surprising and confusing. As I understand, any end-user (you, I, etc.) of the Sovrin Network is also an identity owner in practice. Will having such legal agreement in place not mean that the Sovrin Foundation will know the binding between people in the real world and identifier on the network?

Assuming that this agreement can be signed electronically, what key material is expected to be used?

In the case of Alice joining the Sovrin network through Faber College, what would be the additional process she would have to go through for having the agreement in place with the Sovrin Foundation?


#2

Seems to me there is very little int the way of identity owner obligations. Would it be appropriate for users to consent via a “check the box” standard terms and conditions instead of a long form legal agreement to be e-signed? Otherwise We may be creating additional sign up friction than is logical.


#3

You have zeroed in on a key topic of discussion in the Sovrin Trust Framework Working Group: the role of the Identity Owner Agreement. There are two parts to this question:

  1. Should all Identity Owners be required to agree to the Identity Owner Agreement?
  2. How should consent to the agreement be recorded?

On the first question, there are two schools of thought:

  1. All Identity Owners should have a legal commitment to protect the network. This is the rationale currently reflected in the Sovrin Provisional Trust Framework (PTF) Public Review Draft 01.
  2. Only Trust Anchors need to have a legal commitment to protect the network. See Section 2 of the PTF for the definition of a Trust Anchor.

Right now the sentiment of the Working Group is that all Identity Owners should have the legal commitment to protect the network because that will provide the greatest protection for everyone. However part of the reason we are comfortable with this is that the Sovrin Foundation does not need to “know the binding between people in the real world and identifier on the network”

This comes down to the question of how consent to the agreement is recorded. Right now all the PTF requires is that, somewhere in the process of obtaining a new Sovrin identifier, the human being responsible for registering that identifier sees and agrees to the Identity Owner Agreement. This means the “consent” is the actual registration on the ledger itself. No intermediary needs to record the consent—or keep any record of the registrant’s real world identity.

If you think about it, this is the thing we do every day registering for an account at many websites: we need to check a box to agree to the terms and conditions of the account, even though the site often has no way of knowing our actual identity.

One reason sites do that is that they can later prove in court, if necessary, that everyone who signed up for an account agreed to the terms and conditions, even if the site could not prove a particular registrant’s identity. That’s what the PTF is currently proposing: that every Sovrin Identity Owner agreed to the (very simple) terms and conditions of the Identity Owner Agreement, which is simply to protect the network.

Thoughts?


#4

Edmund, just to clarify, the Trust Framework Working Group never intended for the Identity Owner Agreement to be “e-signed”. It was always intended to be just a checkbox like standard terms and conditions (see my previous message).

However you are correct that the terms of the Identity Owner terms are so simple, they could be displayed directly instead of even needing to be referenced. I like that idea.


#5

While it makes sense to me for stewards to sign formally an agreement, I agree that a check-box (with a minimum legalese, not à la Facebook, Google or Microsoft) would be enough for end users. But the way the Identity Owner Agreement is written and presented gave me the false impression of something much more formal than a standard check-box.

The fact that:

No intermediary needs to record the consent—or keep any record of the registrant’s real world identity.

is reassuring.

Finally, what end users can do on the network will be limited by the app they use to interact with agents, so pushing more responsibility on the app providers and the agents could also be a way to help protect the network.


#6

I think it’s also going to be useful to challenge our thinking with negative scenarios that fraudsters will zero in on very quickly. A series of “what if…” would be particularly good I think.


#7

Some thoughts…

  • An Identity Owner must be a natural person or an organization, therefore DIDs can only be issued by Trust Anchors to entities they have identified as one or the other
  • Identity Owners will mainly interact with the network and the foundation via intermediaries (Agents) or applications and it is in these applications that people will encounter the flow of t’s and c’s however they are presented. We discussed before that it may be appropriate for the Foundation to recommend wording to include in user t’s and c’s. To this extent, there is no ‘identity owner’ agreement, only an agency agreement
  • Another way that an Identity Owner will interact with the Foundation is through the trust mark and it is here that the Foundation makes a ‘promise’ to the end user. It might be better to think about a reciprocal undertaking from the IO rather than a ‘contract signature’.
  • no agreement is enforceable if we cannot identify the real world person and this is only possible through using some form of escrow (see discussion on Sybil attacks http://forum.sovrin.org/t/the-privacy-vs-accountability-problem-solving-for-sybil-attacks/108/2) . But with something as diffuse as ‘protect the network’ its unlikely to be enforced in any case. This implies that it is option 2 (Trust Anchors) who have this as a legal obligation to Sovrin Foundation, whereas IO’s have a reciprocal ‘promise’ which is explicit in any t’s and c’s for sovrin-based services they might use such as those from an Agent or Developer. Might Trust Anchors have an agreement but Identity Owners have none? Does this imply that Trust Anchors have some form of legal agreement with IO’s they provision? How can they enforce this if they comply with the TF and do not know the identity of their IOs?

#8

@NickyH Just a note that this is a great set of observations and questions. I’m on the road in San Francisco presenting on Sovrin this week (just had a great meeting with the Hyperledger folks) but I’ll be back online with some thoughts on this questions this weekend.


#9

I’d like to take a stab at summarizing the results of the trust framework working group on the issue of the Identity Owner Agreement (IOA)

Terms

  • verinym - a DID corresponding to an independent human (entity capable of exerting legal sovereignty)
  • IOA - Identity Owner Agreement
  • TA - Trust Anchor
  • IO - Identity Owner
  • anonym - a DID written directly to the ledger, not by a TA

Summary

  1. The IOA is an agreement accepted by all independent human individuals who establish DIDs on the Sovrin network.
  2. The IOA represents the T&C of participating on the Sovrin ledger - and it boils down to “i agree not to take steps which hamper the efficient function of the network itself”
  3. The IOA very specifically does not extend to any actions taken by the IO which are not involved in the operation of the network itself
  4. The act of requesting that a Trust Anchor generate a DID for a human individual is exactly and completely the step required to acknowledge the T&C of the IOA, the writing of the DID genesis claim onto the ledger constitutes the consent, and the act of revoking the DID (publishing a null DDO), is the act of revoking consent to the T&C of the IOA for that DID.
  5. A given IO may have multiple IOA agreements in force at any one time, as only the IO knows the non-revoked Trust Anchor authorized DIDs under their control
  6. All DIDs, verinym or anonym, represent an acceptance of the IOA on behalf of the controlling party (Guardian, owner-of-Thing, Individual, or Organization)
  7. In the case of guardians, the IOA is between the author requesting that the TA (could be same entity) record a new DID and not between the subject represented by the DID.
  8. In the case of Things, the DID inherits the IOA T&C from the owner of the Thing (either verinym or anonym)
  9. verinyms are always created as part of an existing web of trust, and this is the hierarchy by which IOA consent is traced, and it is what ensures the legal continuity of Sovrin
  10. anonyms are always created as isolated nodes, and develop trust by establishing relationships with other existing nodes.
  11. an anonym can never be a TA

This still seems too wordy and unclear - and I invite everyone to polish it or correct it. Perhaps we can assist the legal eagles by providing appropriate text?

Questions:

Definition of Abuse:
can 2&3 be more precisely specified as “writing to the ledger” - are there any other mechanisms by which the network can be harmed? Perhaps not, if the action also includes “I agree not to coordinate communities whose intent is to disrupt the network”

Claiming a DID
Something we didn’t cover in the discussion was the issue of claiming a DID from a guardian. This is the act of changing the IO associated with the IOA-consent attached to the DID. How could this be enforced, if at all - i will add another topic to the forum for this, as it comes into play in cases where DIDs are created on behalf of others, and potentially without their knowledge or consent. This allows “every DID = IOA consent” but only if we say that the IO associated with the DID changes - and how do you do that - do we specifically put something in the DDO for guardian-held DIDs, so that when the controller of a DID changes from the guardian to that same DID (e.g. the establishment of sovereignty), the IO associated with the DID also changes and the new IOA comes into effect?

Creation of anonyms
In light of #6, every DID represents an acceptance of the IOA - ultimately by someone. The TA-based throttling mechanism, where you need a verinym in order to be able to generate a limited number of anonyms - and where an anonym does not convey the right to create additional anonyms. How could this possibly be enforced?

Role of the TA
The role of the trust anchor, in this case, is fundamentally one of throttling the creation of anonyms. Anonyms can be controlled by IOs who are not subject to the IOA, but anonyms can not create additional anonyms - thereby limiting the potential impact of malicious individuals.

would it make sense to allow a TA to authorize the creation of anonyms for a child verinym? In the world of TAs there is a clear path of IOA consent - and there are potentially needs to create multiple and/or large blocks of anonyms (perhaps as a Guardian enrolling a population of at-risk individuals).


#10

@ewelton Congratulations on:

  1. An excellent summary of one of the richest and most nuanced aspects of the Sovrin Trust Framework (the IOA and how it pertains to Sovrin identity owners).
  2. One of the deepest set of questions about the Sovrin Trust Framework ever posted in a single message. We could practically write a book about these subjects!

That said, because we need to keep pressing forward and close on these questions in order for the Trust Framework Working Group to complete Public Review Draft 02 of the Provisional Trust Framework by our new deadline of Feb 28, let me try to be as concise as possible in my answers.

I agree we should double check with Sovrin Foundation counsel @sblackmer about the precise language for the Identity Owner Obligations in the IOA. Please review the current language—which includes a catch-all along the lines you suggest—and see if you have any other specific suggestions.

Yes, that’s exactly how it works. In other words, when a Guardian registers a DID on behalf of a Dependent, it is the Guardian who is subject to the IOA. As you say, the Dependent may not even know he/she is registered. However when the Dependent requests that the Guardian remove the Guardianship in order turn the Dependent into an Independent, that’s when the Dependent becomes an active IO and must agree to the IOA. Note that there is a very specific state change in the DID when this happens (the guardian block is removed and an owner block is added)—see the DID spec for details.

This is exactly right. That’s why your Summary point #1 above is true: “The IOA is an agreement accepted by all independent human individuals who establish DIDs on the Sovrin network.”

The Sovrin Technical Governance Board (TGB) and its chair Jason Law are working out the precise details, but the basic idea is really quite simple:

  1. The DID registration transaction for a verinym is verified by a TA signature.
  2. The DID registration transaction for an anonym is verifed by a zero-knowledge proof (ZKP).

This makes it easy for the Sovrin validator nodes to enforce the following rules:

  1. TAs can create verinym DIDs.
  2. Verinym DIDs can create anonym DIDs.
  3. Anonym DIDs cannot create any other DIDs.

Make sense?

Correct. TAs also have some other trust maintenance functions, but this is the primary one.

Actually, following the rule we stated above, anonyms can only be created by Independent IOs, and all Independent IOs are subject to the IOA.

Correct.

Yes. In fact, this follows from what you said above: “The role of the trust anchor, in this case, is fundamentally one of throttling the creation of anonyms.”

The TGB is calling this throttling mechanism a “trust claim”. It is essentially a ZKP that the TA issues to the IO that permits the IO to register up to a specified limit of anonym DIDs (the throttling limit).

The key point is that throttling is only necessary when registering anonyms. It is not needed when registering verinyms because if there is abuse (e.g., an IO writes a bot to register 100M verinyms), the “chain of custody” can be followed upstream to the TA who authorized the IO, and the IO can be held accountable. But for anonyms that “chain of custody” cannot be followed, so they need to be throttled.


Endnote: I doubly appreciate these questions because they help illustrate why and how the Sovrin’s web of trust model works. This is important not only to finishing the Provisional Trust Framework, but for the white paper the TGB would like to issue when the Provisional Network goes live (tentatively titled The Sovrin Web of Trust Model). More on that after we finish Public Review Draft 02 of the Provisional Trust Framework.


#11

I do thank you for the support and attentive response - well spoken, measured, and presented as always.

I still find myself troubled by the niggly bits of the IOA and consent propagation - and wish I had more time than Tuesday nights to really sift through this. Please bear with my misunderstandings and help me get to the bottom of that nagging feeling that one or two stitches are still out of place.

Current Language / IO Obligations

The current language is:

Identity Owner Obligations
The Identity Owner shall conform to all policies set forth in the PTF and STF that apply to:

  1. Identity Owners.
  2. Any additional role for which the Identity Owner qualifies and elects, including Trust Anchor and Guardian.

The Identity Owner shall not:

  1. Abuse, spam, or otherwise take malicious action against the Sovrin Network.
  2. Interfere with the use or enjoyment of the Sovrin Network by other Members.
  3. Use a Sovrin Identity to impersonate another Identity Owner or otherwise misrepresent the Identity Owner’s identity or relationships.
  4. Otherwise break their Sovrin Promise.

I don’t see the need for #2, except as a some pre-emptive statement - an IO who also has the “woodworking merit badge” is still an IO. The clause seems redundant - and if there is some intent whereby this might not be redundant, that intent ought be more clearly visible. I’m just wondering about a simpler statement of this obligation:

The IO shall conform to all policies set forth in the PTF and STF, in all engagements with the Sovrin Network, by virtue of being an IO and without further qualification.

In other words, IO is entire and complete - there can be no division, such as “IOs whose names are like %Bob%” and “IOs who act as TAs”

Of most concern to me, however, is item #3 in the second set. #1 and #2 are pretty generic - it identifies Abuse, Spam, Malicious Action, and Inteference - those are pretty broad, and subject to the whims or precedence and social decision (the record of decision and action taken by the Sovrin Court, or Sovrin Council of Elders, or Respected Sovrinic Council, etc.) - no worries there. #4, likewise (through substitution of definition), basically says the same thing - it says "agrees to play by the rules of the STF and PTF - and is, ultimately, redundant with the first section.

Item #3 however - is a problem. It extends outside of the relationship of the IO to the SN (Sovrin Network). It is about the use to which the DIDs on the SN are put - and that opens up a huge can of worms, and one that seems to me to show up again in the edge cases of the Verinym/Anonym/Pseudonym triad.

Very specifically, I think that item #3 should simply be dropped. The appropriate vehicle for the policing and management of item #3 are reputation systems and the mechanics of trust flow through the network. With the absence of PII on the ledger, the determination of impersonation is exceptionally vague, and in the case of anonyms, requires the claim that the PII linked to third party accounts bound to anonym X is the same as the PII linked to third party accounts bound to anonym Y, but furthermore, that the verinyms associated with the genesis of anonyms X and Y correspond to third-party linked PII such that verinym-which-authored-X has claim on the PII, while verinym-which-authored-Y does not. This, sadly, is probably one of the simplest contortions of such a case.

The Trust Anchor mechanism is appropriate for #3, the IOA is not.

I might counter with a term that says “IOs agree to support, enforce, and enhance the neutrality of the Sovrin Network as a means of establishing and maintaining the authenticity of identity” - but clearly the wording would need some smithing.

Guardianship

Thank you for pointing out the spec - the issue of guardianship and the ‘claiming of an ID’ - via update of the DDO, is clear there. Also, the IOA is clear - the Guardian owns the responsibility and liability for the IOA until transferred. I did not see (although I was perhaps too rapidly going through the spec) a specific means of Rejecting the Guardianship of a DID/DDO. Presumably this is executed by “accepting the DID” and then “publishing a null DDO” - perhaps this needs to be trinary. The state change being from Guarded Identity -> (Owned Identity, Terminated Identity)?

Throttling

This is an absolutely beautiful bit of wizardry, and I am very excited to learn more about it. It does indicate that DIDs can be easily partitioned into verinyms and anonyms - much in the way they can be quickly partitioned into Independent and Dependent. I think that this means we can update the taxonomy diagram.

Propagation of IOA consent

I expressed a concern that a verinym could author anonyms that did not correspond to IOs, but you countered

I think that is true, but only if the following statement is also true

Anonyms are always Pseudonyms of the generating Verinym

I do not see the above claim formally documented anywhere. It may have been implied by the ‘anti-impersonation’ clause of the IOA, but (cutting out a long winded analysis) I think I could argue my way out of that. If the condition of pseudonymity is upheld, then IOA consent propagation is clear, with the following lemma:

Guardians may only create Verinyms

which is a rule that could be enforced by validator nodes, since the status of a DID/DDO as guarded/owned and as verinym/anonym are easily determined. This would be a tweak for the TGB, reifying the concepts of verinym and anonym.

Tenative Summary

My gut tells me that there are two issues here - at core, just two minor refinements:
1 - the Identity Owner obligations, item #B,3 - the “impersonation clause” - because this breaks out of the network and relies upon claims about the use to which the data pinned to the network was put. This is as thorny as the grammar required to express it.
2 - explicit recognition of verinyms and anonyms as entities within the technical taxonomy of both the sovrin network and the governing trust framework - rendering the rules of anonym generation and processing, and the differences between verinym processing, and in particular how verinyms participate within the TA-based web of trust while anonyms represent nodes on potentially (completely) isolated subgraphs, while simultaneously demonstrating that the existing of anonyms implies that there exists a corresponding connected verinym node which has demonstrably consented to the IOA.

Point #2 here is particularly subtle and important to get right - because, at first glance, it makes absolutely no sense.

What comes to mind, when I think about #2, is the current fracas over the legal status of the “Facebook/React.js patent clause” - a moment of quick googling will reveal enormous discussion about a silly clause in the licensing of React.js (and other libraries) from Facebook. The discussion itself has given rise to “alternative facts” - otherwise known (outside of the Trump administration) as “vapid fantasy”. The alternative fact in this case is the idea that Facebook can shut down your product line if your product line uses React and if they have a beef with you. That’s not the case, but it is the result of overly subtle legal considerations making their way into the limelight through mass publication.

The parallel with Sovrin is the concept that an anonymous identity can somehow be held accountable to a legal framework when there is no way, even in mathematical principle, for the owner of that identity to be identified. The subtlety rests on an existence-proof vs. solution-proof - we know, by virtue of the fact of the existence of the DID, that there once was an IO who consented to the IOA, and with the refinements of IOA consent propagation, we know that the ultimate owner of that DID did consent to the IOA, even though we can not, as a matter of mathematical reality determine who that is.

It is such an obtuse statement, that one has to wonder, “Why on earth does it matter and wouldn’t it be simpler to call Anonymity, simply Anonymous?” - the fact that such a fine distinction was made, as a legal matter, must mean that “Something is rotten in the state of Sovrin”.

Perhaps it is better to simply accept certain simple freedoms be awarded to anonymity, with a throttling component ensuring that anonymity can not be a vehicle for network abuse.

What this means is that “Verinyms accept the IOA, Anonyms do not” - but, since Verinyms can only mint a limited number of Anonyms, then there is a throttling which can mitigate the risk of antagonistic Verinyms bent on intense disregard of the IOA and interested in attacking the SN.

The win is that the logic and expression is simple - the very fine grained analysis of “complete coverage of IOA consent” is a bit winded, and with the removal of item #B,3 from the IO obligations, the pinning to PII external to the network is removed. If #B,3 is retained, then the IOA consent includes conventions which could potentially mandate the compulsion of 3rd parties to reveal PII data - I know that such a situation would surely never happen in a civilized world, but, well… let me tell you the story of a boy named Ed…


#12

Love the terminology anonym verinym etc


#13

@ewelton Thanks for another deeply reasoned post. The following reply is intended specifically to capture my thoughts in preparation for the special Trust Framework Working Group call tomorrow (Thursday) at 10AM PT. This call will be focused on closing the open issues with the Identity Owner Agreement (and “propagation of consent”).

On this I disagree. But before I explain, first let me quote a subsequent sentence of your post:

On this I do agree—with the right “smithing” this should work. Let me explain (this is a long explanation, but I provide the full detail so we can hopefully get down to the very heart of this discussion):

First, one of the most unique aspects of Sovrin architecture is that it is a single system that supports the full spectrum of identity from public verinymous identity (transparent, legal, highly correlate-able) to private anonymous identity (opaque, unaccountable, non-correlate-able). And in the middle is a special category I’ll call private verinymous identity, which is an identity that can be held accountable, but which is not publicly identifiable or correlate-able.

For the purposes of this analysis, this means we can cleanly divide Sovrin identities (one or more DIDs registered by an Identity Owner on the Sovrin ledger) into two categories:

  1. Verinymous—DIDs for which the Identity Owner can be held accountable directly by virtue of the Identity Owner’s relationships on the Sovrin Network.
  2. Anonymous—DIDs for which the Identity Owner cannot be held accountable directly by virtue of the Identity Owner’s relationships on the Sovrin Network.

My thesis is that we have carefully designed the Sovrin Network and the Sovrin Trust Framework to around two principles:

  1. All Identity Owners MUST have at least one verinymous identity (public or private).
  2. All Identity Owners MAY have a reasonable number of anonymous identities (the “reasonable number” rule is to prevent spam or DDOS).

The first rule means that all Identity Owners must enter the network via a Trust Anchor, so their first DID is verinymous (either publicly associated with the Identity Owner’s legal identity or privately associated by virtue of the Identity Owner’s relationship with a Trust Anchor).

This is what makes 100% of Sovrin Identity Owners accountable for the Identity Owner Agreement—the fact that a Trust Anchor ensured that a real human being (or organization) agreed to become a Sovrin Identity Owner.

Now, the fact that an Identity Owner has the right (via the Sovrin Trust Framework) and ability (via the Sovrin Network) to then create anonymous DIDs does not change the fact that the Identity Owner has obligated himself/herself/itself to the Identity Owner Agreement.

And, in my personal opinion, since Sovrin is an identity system, one of the obligations in the Identity Owner Agreement should be that an Identity Owner agrees not use the system to cause harm by impersonating another Identity Owner.

To that point, in your post, you make this argument:

And:

Here is why it matters: accountability. You are absolutely right that, as I defined above, an anonymous DID cannot be held accountable directly by virtue of the Identity Owner’s relationships on the Sovrin Network. In other words, as you point out, with an anonymous DID you cannot mathematically prove that you have a path to the legal identity of the Identity Owner.

But that is not the only path to accountability. In the real world, there are countless other ways to discover the real relationship between an Identity Owner and an anonymous DID. The fact that Sovrin infrastructure itself does not provide that path does not mean it does not exist.

And if that path is discovered in some other way—by detectives, by law enforcement, by slip-up—now the fact that you can prove that the Identity Owner MUST have agreed to the Identity Owner Agreement matters. Because the Identity Owner can now be held accountable for that obligation.

In short, what we have is anonymity with accountability. Not perfect accountability—because Sovrin infrastructure alone can’t supply that—but practical accountability because it applies to 100% of Sovrin Identity Owners. So if any Sovrin Identity Owner is ever caught violating their obligations in the Identity Owner Agreement, they can be held accountable.

And I personally believe that accountability should extend to not using Sovrin to cause harm by impersonating the identity of another.

I look forward to tomorrow’s discussion. BTW, any Sovrin community member who would like to attend the special call (at 10AM Pacific Time), just send me email at first name drummond dot last name reed at company evernym dot com.


#14

This is absolutely gorgeous… I see us closing in on the endgame, the hairs split finer and finer. I am going to devote the rest of the evening to trying to generate a response - but time and context are not on my side - it has been a long day of “Sovrin related” meetings - the next call hits hours >24 but it is the last for the stretch.

from what I can see - we are in agreement for the 99% case - but the mathematician in me (the part of my psyche that thinks UUID’s are crap, because they are ‘effectively universal’ but not ‘truly universal’) is not yet content. The practical part of me is content - with some minor wordsmithing and a little textual buff and varnish. For me the test of legal text is Turing, who is a far stricter master than jurisprudence.

That tension - the mathematical and the legally pragmatic - now is the window when we get to pour and police the cement - in a million years that cement will turn into coal or diamonds depending on the flaws we unknowingly introduce. Reasonable cases are well treated - but I feel I can imagine and illustrate conditions of identity so horrific they make the holocaust look like a disney choreographed hell. it is paramount that we take every effort to provide digital means to avoid, not just recurrence of past blasphemy, but the abuses of future sadists.

When digital identity fails, and it will, let it not be at the hands of the architects.

next post coming… the remaining hairs are quite fine.


#15

@Drummond - so much of digital communications has devolved into 160 character touch-pad ejaculations it is just tremendous to read something longer and so well presented - I thank you for your time and appreciate the effort behind this argument - it was a joy to read and consider.

I agree with you pretty much across the board - and I think there is only one point where an assumption (one implicit in the original source material) needs be made explicit:

Restriction of Anonym Scope

Anonyms are necessarily Pseudonyms for the originating Verinym. It is not the case that an anonym can be minted on another’s behalf.

When this is enshrined - explicit and obvious - perhaps in the Identity Owner Obligations, the concerns I have melt away - and, if placed next to the impersonation clause, it renders the potential abuses of the impersonation clause impotent.

From this, it follows that

Guardians may only create Verinyms, not Anonyms

as such it exposes Guardians to “KYC-like” obligations of the form that @cbruguera mentioned on the call. If a Guardian may only mind Verinyms, then the conditions of determining a Verinym need to be expressed. In this context - a pre-claimed Verinym could be either (a) accepted [via the attachment of an owner property to the DDO] , or (b) rejected as falsification… perhaps through the publication of a ‘null’ DDO?

the condition of a guardian minting ids under duress causes the generation of KYC-detritus in environment wherein it could be used for deleterious purposes. When I ask all of the citizens of a country to register their religious preference so that I can mail them the appropriate ‘seasonal card’, there is a substantial risk that the same “goodwill list” could be abused. This is the sense, to me, wherein a Guardian’s ability to mint Anonyms, which perhaps later become Verinyms (through and equivId link?) is possibly valuable.

I do not have the time to make a clearly thought out case here - but I wanted to get this out the door.

Accountability & the PII revelation clause in the IOA

On the matter of accountability…

But that is not the only path to accountability. In the real world, there are countless other ways to discover the real relationship between an Identity Owner and an anonymous DID. The fact that Sovrin infrastructure itself does not provide that path does not mean it does not exist.

my claim is not that such paths do not exist, it is that they necessarily exist via off-ledger PII and provide a specific vehicle for pressuring organizations (such as those hosting Agencies) into revealing PII. I would like to remove the vehicle by which those who have power-and-guns (e.g. governments and mafias) can ply their violent trades.

When the fervor of nationalism or patriotism seizes a people, they are prone to genocidal violence - and when a people are in the grips of such psychology the unimaginable becomes commonplace. I can fully imagine a state department security officer holding a gun to the head of a poor sysadmin in mountain view and demanding the release of PII. Please do not ask me to reveal why I can imagine this so vividly, but let us assume, for the sake of argument, that such an event could occur.

I want that sysadmin to be able to throw a “manual of impossibility” at the DSS agent - one that clearly absolves them of any possibility of revealing the PII.

At present it is the job of the TGB, and the agent working group, to sufficiently arm our poor mountain-view-sysadmin. I think we need to make sure that we also do our part, and make sure that there is not even a suspicion that Mr. Mountain View could be of value (he may still be put to the blade - but at least it won’t be on account of a loophole we exposed)

so, i agree

And if that path is discovered in some other way—by detectives, by law enforcement, by slip-up—now the fact that you can prove that the Identity Owner MUST have agreed to the Identity Owner Agreement matters. Because the Identity Owner can now be held accountable for that obligation.
In short, what we have is anonymity with accountability. Not perfect accountability—because Sovrin infrastructure alone can’t supply that—but practical accountability because it applies to 100% of Sovrin Identity Owners. So if any Sovrin Identity Owner is ever caught violating their obligations in the Identity Owner Agreement, they can be held accountable.

I think that as long as “Anonyms are Pseudonyms for Verinyms” is in play - the above is 100% viable.

However, I do not like the lemma

Guardians may only create Verinyms, not Anonyms

very specifically, I want to have the ability to use Sovrin to smuggle the future Edward Snowden’s out of the country - and I want Sovrin’s help to do so.

That being said and clear, I am willing to bow on this point - it is the ‘finest of hairs’ being split. Outside of this confluence of extreme edge cases, I am fully comfortable with the framework as it stands. If I am ever in the position of abetting future Mr. Snowdens, I will likely pursue the standard route and purchase an official passport based on “alternative facts” - (for the life of me I don’t know why he chose HKG instead of BKK, but maybe I’m just jealous :wink:

Impersonation Clause

I do not have any problem, at all, with the impersonation clause in the case of Verinyms. I support your arguments and reasoning in this case. And when anonyms are covered by the “preservation principle” it is not a problem.

When considering the case of “minting anonyms as a guardian of a persecuted group” - that is the only case where I find the impersonation clause problematic.

i am only wondering if we can do a little better by tweaking the terms of the impersonation clause, and perhaps adding some structure like “guardian/owner” explicitly for the edge case of “guardian minting anonyms for another, where the claim is not guardian/owner, but anonym->verniym, perhaps in concert with the addition of the owner clause in the DDO?”

@Drummond - i wish we could cut out the internet and explore this via letter sent by tall-ships across oceans. the hurried consideration of my response is less than I would have liked to offer.

talk to you in 17 minutes :wink: