Recording claims on behalf of another agent


#1

Does it make sense (or is it technically feasible) for an agent to record a claim on behalf of another agent?

Let’s say Entity A desires to be able to record claims on the ledger, but it’s not recognized as a Trust Anchor by Sovrin. Nevertheless, Entity B is a Trust Anchor with enough permission to make such writes and it’s also trusted by Entity A to do so.

How about this Entity B being able to record claims that are signed by Entity A on the ledger, after which Entity A is perfectly able to verify its signature over such claims, yet still not in control (or at least not completely) of said claims?

How does this case sound to you?


#2

All this leads me to thinking on another related subject: How do we express such “trust” relationships? Would it be convenient for an entity to record a public (on ledger) claim about it trusting a second entity to do certain things? Do you think it’s advisable to use the ledger for managing some types of “permissioning” for some contexts, like the mentioned case? Or maybe this would be a proper place where link contracts would be playing a primary role?


#3

Carlos, you have two asked two related questions here each requiring its own answer.

On the first one, about Entity A needing an identity (a DID) on Sovrin and the ability to start recording claims against that DID, but Entity A not yet being trusted to write directly to Sovrin. There are two options here. First, if Entity B, who is a trust anchor and thus has permission to write to the ledger, knows and trusts Entity A, then Entity A can create a DID (and the associated public/private key pair) and request that Entity B write the DID/DDO record to the ledger. That DID is now the “genesis record” for Entity A, and Entity A now has permission to write to the ledger. In simple terminology, Entity B was a member of the Sovrin identity network and had permission to add Entity A as a new member.

The second option is that Entity A is not in a position to generate a DID and the associated public/private key pair. In this case Entity B, as a trust anchor, can still create a DID/DDO record for Entity A. Entity B can also write claims for this new DID. The difference is that Entity B is serving as the guardian for Entity A, and will continue to serve as the guardian until Entity A is in a position to take control of its own DID/DDO record (by having it’s own public/private key pair).

Now, on your second question, about how to manage trust relationships and how to delegate trust. I definitely think that some trust relationships—specifically public trust relationships—can and should be written to the ledger. For example, this is how public trust anchor relationships should be recorded—one TA writing the claim that it trusts another DID to be a TA.

But other trust relationships—specifically private trust relationships—should not be on the ledger, but instead be part of the private claims managed by identity owners and exchanged between their Sovrin agents. For example, if I trust my wife to write claims about our house, car, and other family possessions, all of those trust relationships can be recorded in my own private identity graph (and the resulting link contracts) maintained by my Sovrin app(s) and agent(s). Neither my wife or myself need to put those relationships or claims on the public ledger.

Make sense?


#4

I think I might have not exposed the case too clearly…

In my example, Entity A would be in control of its own DID. However, it additionally needs to write other claims but not necessarily about itself or any other already existing identity on Sovrin. In first place, is this possible?..

Assuming it’s possible. That’s where my actual question comes: is this Entity A able to request from Entity B that it writes claims on the ledger on its behalf, yet still signed by Entity A?

For example, Entity A might be a bank that onboards customers online, and it desires to record a proof for each of its customers, yet it’s not practical to make those customers create self-sovereign identities on Sovrin at this point. Each of this claims might be the result of a KYC process, for example, and the bank would like to be able to proof that such processes were factually approved by it. Note that we’re not dealing (in this example) with the bank’s identity per se, but other sorts of claim made by it.

…Let’s say in case this bank is not a Trust Anchor (having no write permissions), is it still able to verify claims made by it? And can it store those claims through another intermediary trusted entity?

Does this make sense?


#5

Carlos, I’m not sure if I’m following all of your use cases in this question. But as usual your questions are forcing me to enumerate definitions and rules we need to define in the Sovrin Trust Framework anyway (which is a particularly high priority this month as we drive towards go-live of the Provisional Network, about which I’ll post separately).

First, some definitions:

  • Entity. A resource (person, organization, thing) that needs self-sovereign identity, i.e., one or more DIDs and DDOs registered in the Sovrin network.

  • Identity owner. An entity that has one or more Sovrin DIDs.

  • Independent identity owner. An identity owner who controls the private key(s) for the owner’s DIDs.

  • Dependent identity owner. An identity owner who does not control the private key(s) for the owner’s DIDs. A dependent identity owner is dependent on a guardian. The DDO for a dependent identity owner MUST contain a link to the guardian’s DID. Note that while people who do not have their own digital devices or connections are one example of dependent identity owners, so are “things” (in the IoT sense, e.g., devices, sensors, apps, physical goods). Things can’t directly control their private keys, so they must have a guardian acting for them. But the identity of the thing is actually independent of the guardian (or anyone else), so the thing is the true “identity owner”.

  • Guardian. An independent identity owner who controls the private key(s) for a dependent identity owner’s DIDs. This means the guardian can act as if it was the dependent identity owner, so it is critical that dependent identity owners and guardians have a strong trust relationship.

  • Provisioner. An independent identity owner who can provision DIDs for itself or for new identity owners to bring them into the Sovrin network.

  • Self-provisioner. An independent identity owner who can only provision new DIDs for itself.

  • Issuer. An identity owner who can issue verifiable claims about its own DID(s) or about other identity owner’s DIDs. All claims from an issuer are signed by that issuer and can be verified by checking the issuer’s public key in its DDO.

  • Trust anchor. An independent identity owner who has earned a trust anchor designation (the rules for which will be defined in the Sovrin Trust Framework—this gets into the Sovrin web of trust reputation system).

Now, following these definitions, here are the rules:

  1. A trust anchor can serve as: a) provisioner, b) guardian, c) issuer.

  2. An independent identity owner can serve as: a) self-provisioner, b) issuer.

  3. A dependent identity owner can only request a guardian to act on its behalf.

  4. A guardian can, on behalf of a dependent identity owner, do anything an independent identity owner can do (which is why the dependent identity owner must have strong trust in the guardian).

Hopefully, with these four rules explained, you can map them onto the entities and requirements of your use case(s). Let me know if you have any remaining questions.

BTW, these definitions and rules are exactly what we propose to include in the Sovrin Trust Framework, so please let me know if you or anyone else has any feedback that the Sovrin Trust Framework Working Group should take into account.


#6

@cbruguera interesting question. If I understand correctly, you have a person, say John, who wants to open an account with a bank, say HSBC. To do that, John needs to provide (in the UK) a proof of identity and a verification of address. As acceptable identification document, John gives HSBC a copy of a current British Passport and as an acceptable address verification document John provides a bill from British Gas. As John is not on Sovrin yet, both passport and bill are still paper-based I guess. HSBC completes the KYC check: name of new customers = name on bill = name on passport.

Now why does HSBC need to use another agent? Can’t HSBC simply create a new DID for John and write a claim related to that DID (as I understand you need a DID to make a claim). At that point in time HSBC does not need to bother John with Sovrin, HSBC could simply remain a kind of “ghost” agent… until John becomes aware of Sovrin and start using it and us HSBC as agent or ask HSBC to transfer DID to another agent.

Wouldn’t this solve you problem?


#7

@Drummond Thank you very much for your detailed response on the different Sovrin roles, that surely clear things up a great deal.

Indeed the original case as it is, sounds like a perfect example for the “guardian” role. In this case, Entity B would be the guardian of Entity A. Clearly it doesn’t make much sense to be a “self-sovereign” identity on Sovrin (that is in control of its own keys) and not being able to write any claims on it. So, if such entity needs someone else to record the claims, it means it’s not completely self-sovereign at all (at least yet), since it depends on another entity. That is a perfectly possible case where a third party needs to take custody on such capabilities (thus it’s a guardian).

Thankfully, the detailed description of the different roles aids to model things out in a better way (as the question is intended for a real use case).

Now, @fabienpe, your idea makes total sense. Yet the intent of the original question was assuming that “HSBC” (playing the role of “Entity A”, for example) has no writing permission to the ledger. The role description given by Drummond, though, makes things clearer now. So I’m assuming the only way an entity has no write permissions of any kind (even claims) is that it is a “dependent identity owner”… For the use case I’m exploring, though, it’s useful to have knowledge of the other different roles, since even if “Entity A” is independent and able to make claims, it might not be able to issue new DIDs, so it would need someone else (a provisioner) to do that on its behalf.

@Drummond, is my understanding correct so far?


#8

These definitions are super helpful, @Drummond. Thank you for posting them.

Since you asked for feedback, let me point out a few places where I have dissonance. Take them FWIW.

“Entity”: First, I’d take out the “self-sovereign” qualifier; the thing you want to define here is identifiable or identity-worthy regardless of the question of sovereignty. I am a fan of self-sovereignty, but I don’t think it’s a precondition to qualifying as this thing you’re defining. It seems like what you’re really after is uniqueness of reference/separability from others. Second, I don’t think “entity” is the right label for this concept. When I am discussing Sovrin architecture, I use “entity” to refer to anything I can point at in my diagrams–agents, edge devices, people, nodes, ledgers, etc. In my mind, an “entity” is just a component in any given ecosystem. A “participant” or an “idem” might be better. (I don’t feel super strongly about replacing the label, so you might just ignore this suggestion.)

General comment: you are equating the ID for an identity with an DID on Sovrin. I thought Sovrin supported CIDs as well. If I have a CID but not a DID, do I not meet the definition of “Identity owner”?

I see where you’re going with the guardian concept, and I love it because it elucidates many issues. However, the definition as you have it here is problematic because it narrowly focuses on private key control. If I tell my wife what my private key is as a redundancy measure (set aside the inadvisability of doing that; it will certainly happen in some cases), has she become my guardian and I become a dependent identity owner? I don’t think so. Perhaps you mean “control” in the sense of “exercise governance” in any loose sense, and you’d say I still “exercise governance” in a de facto way, so the guardianship is only theoretical. I could buy that, but the exact meaning of “control” needs clarification.

Another problem with guardianship as described here is that it’s binary–whereas in “real life” guardianship is a spectrum. The example I gave of a husband and wife sharing access to a private key might be at the “hardly guardianship at all” end of the spectrum, whereas the example of a newborn infant or a smart car that are totally dependent on a different owner might be “super strong guardianship” end. But there are points in between, such as an adult who’s fully capable of operating on their own, but defers in advance to 5 friends as authorities on social recovery in the face of a potentially hacked device. (In that case, the 5 friends exercise a very limited form of guardianship–and it’s group guardianship where no one friend can unilaterally act as guardian; rather, the group as a gestalt must do so.) A typical teenager lives at various points between dependence and independence over a multi-year period. Saying that they do not control their private keys is probably a bit of a stretch in various scenarios–but acknowledging that sometimes parents also control their private keys (or exclusively control some private keys but share access to others) would probably be accurate.

“Provisioner”. My two cents: I don’t like the usage of “provision” that’s being enshrined here. I have never liked that usage, although I have heard it before. In most technical contexts that I’ve known, “provision” is about allocating scarce resources. Here, we are using “provision” almost like a synonym of “enroll”. We don’t “provision” people onto Sovrin because we aren’t dividing up limited resources when we do this. Instead, we “record” them onto the network. Or “usher”. Or “introduce”. And the new DIDs are “created” or “recorded”, not “provisioned.”


#9

Very valuable input, @danielh. I have to comment on some of those points, though.

I was under the impression that a CID was a special case for a DID that happens to have certain cryptographic attributes. I was assuming that in most cases when we talk about DIDs, we’re actually referring to CIDs, isn’t that right? In any case, I’m not completely clear yet as to the use cases where plain DIDs (without cryptographic properties) are useful. Most of the time I’ve been assuming those DIDs have associated cryptographic keys.

The more complex model for “guardianship” is a very good idea in my opinion, as it effectively features the flexibility we need to model real life scenarios and yet unseen future cases.

About the “provisioner” term, I can’t think of a better term at this moment. Although the most common use seem to be related to the management of limited supplies, I don’t think there’s a semantic limitation on the word itself that implies that that which is provided is necessarily finite. An “entity” that records identities on the ledger is actually “providing” or “supplying” identities to the corresponding owners (not really provisioning people into Sovrin, but more precisely provisioning Sovrin identities to people).

Now, this last topic forces me to ask the question: assuming that I’m a “provisioner” (or we might say “Identity provider”), meaning that I can create new IDs on the ledger, how can I ensure the self-sovereignty to the owner? I’m guessing they would need to generate their DID privately and then send me a request with the corresponding DID to be written on Sovrin, correct? (Unless I want to remain the “guardian” of such DID, in which case I would generate it and keep it for myself)…


#10

@cbruguera, yes, you are correct. A dependent identity owner has no direct permissions, so they have to have a guardian do everything for them. By definition only trust anchors can be guardians, and trust anchors have the highest level of permissions, including serving as provisioners. So a guardian can do anything a dependent identity owner needs them to do—the guardian just has to be completely trusted to do it (and not do anything else they shouldn’t).


#11

@danielh: thanks for the excellent feedback. A few notes (using the forum’s quoting feature, which I just discovered).

Agreed. I’ll modify that definition.

On this one, we need to sync up with Jason. My understanding is that all Sovrin identifiers were going to become DIDs—we dropped the concept of CIDs because the DIDs were just the first 16 bytes of the CIDs. But let’s clarify this with Jason.

While I agree with you about guardianship in the real world being much more of a spectrum, the type of guardianship we are talking about in DID architecture (of which Sovrin DIDs are one scheme) really is binary. Either the identity owner controls the private keys, and therefore can sign Sovrin transactions, or not.

There is of course the case where the identity owner controls the private keys but still delegates some functions to other identity owners. For example a husband delegating some control over his private key to his wife. But in that case, the identity owner does have control of the private keys, and simply exercises his/her power of delegation. To keep our semantics clean, I suggest we not call that guardianship, but delegation.

That means we can reserve the term “guardian” for the case where the identity owner MUST trust another identity owner (specifically, a trust anchor) to be the guardian of the identity owner’s private keys. Again, you can argue that this form of guardianship is a spectrum, because the agreement between the identity owner and the guardian could limit the actions that the guardian can rightfully take.

In the end, however, the “bright line” that we’re drawing in the DID context is control of the private keys. If you have that control—even if you delegate some of it—you are an independent identity owner. If you don’t have that control, and must rely on a guardian for it, then you are a dependent identity owner.

On this point, I think we might have to agree to disagree. While “provisioning” has other meanings in other contexts, in an identity management context, it is the standard term used across the industry for provisioning or deprovisioning identities. For example, see this page on the Ping Identity site.

FWIW, I didn’t particularly like the term when I was first exposed to it 15 years ago either. But it’s pretty baked into the industry. I’m open if there’s another better term, but that would require a mental mapping exercise for the IAM folks in enterprises who will be dealing with Sovrin identities that I’d prefer to avoid (we already have enough new concepts for them).

Again, this is great feedback, and I encourage you to look over the full formal definitions of all these terms that will be going into the Sovrin Trust Framework, because that’s where the definitions will take on legal force (not just technical force). Our goal is to have the first cut by Monday, and I will post here when it’s ready. Stay tuned.


#12

Carlos, you are correct. I’m glad you asked that question, because a detailed description of how the provisioning process works will highlight the crucial distinction between an independent identity owner and a guardian. It comes down to the actual provisioning workflow—not the workflow that interfaces directly with the Sovrin ledger, because that’s the same either way—but the workflow between the actors collaborating to provision a new DID on Sovrin.

Here are the two scenarios—one for the independent identity owner and one for the dependent identity owner.

In the first scenario, when an independent identity owner wants to be initially provisioned onto the network, the first step is for the owner to generate their own Ed25519 key pair. They should NEVER rely on third party to do this, because if they do, it is impossible for them to guarantee that the third party does not retain a copy of those keys (I’m not a deep math guy, but I understand it requires a proof of non-existence of something that must in fact exist.)

Note that the first half of the public key (the “verification key” in elliptic curve parlance) becomes the DID that will be registered on the Sovrin ledger.

The second step is for the independent identity owner (or a trust anchor the owner trusts) to create the DDO. (For more on DDOs, see the DID spec.)

The third (optional) step is for the independent identity owner to sign the DDO as proof the owner controls the private key. (This step is optional because a relying party can always confirm the independent identity owner’s control of the private key later by sending a challenge message for the owner to sign in real time.)

The fourth step is for the independent identity owner to request a trust anchor—who by definition has permission to provision DIDs for new identity owners—to write the transaction with the new DID and DDO to the Sovrin ledger.

The trust anchor then sends an acknowledgement to the identity owner, at which point the optional (but recommended) fifth step is for the independent identity owner to do its own lookup of the new DID on Sovrin to ensure that neither the trust anchor or anyone else tampered with the DDO before it was written to the ledger.

Note that throughout all of this, the independent identity owner NEVER shares the private keys with anyone else, including the trust anchor. That’s a very concrete definition of “controlling the private keys”.

Now, here’s the second scenario for a dependent identity owner. By definition, the dependent identity owner does NOT have control of the private keys. So the dependent identity owner cannot generate the DID or compose the DDO to be registered. The dependent identity owner has no choice but to trust a third party to perform all those steps on their behalf.

That third party is the guardian, who by definition MUST be a trust anchor and therefore has permission to provision a new DID and DDO onto the ledger.

So in this second scenario, the situation is the exact opposite. It’s the guardian who takes the same steps an independent identity owner would takje, starting with generating the Ed25519 key pair and then guarding it—just as an independent identity owner would guard it—on behalf of the dependent identity owner. The dependent identity owner NEVER has control of the private key because it must stay completely with the guardian in order to be safe (and to maintain accountability when that private key is used).

That’s why the dependent identity owner needs such a strong trust relationship with the guardian—the guardian literally “has the keys” to the dependent identity owner’s identity.

With this explained, I can finally answer this specific question you posed:

For independent identity owners, the answer to that question is easy: they ALWAYS control the private keys for their DIDs and never give it up to anyone (except by conscious delegation, as I mentioned in my previous reply to @danielh). So they begin and stay truly self-sovereign.

For a dependent identity owner, the exact opposite is true—they NEVER control the private keys for their DIDs. That’s what makes them dependent. But that doesn’t mean they are not self-sovereign.

You ask, “How can they not control their DIDs and still be self-sovereign?”

The answer is a legal one, not a technical one—which is the reason the Sovrin Trust Framework is so important. The Sovrin Trust Framework will require that a guardian has a legal obligation to act in the best interests of the dependent identity owner (the attorneys will choose the right legal term for this, but in the financial world, it’s called a fiduciary).

So even though the dependent identity owner does not technically control their private keys, the dependent identity owner is legally in control of their Sovrin identity, and that’s what makes it self-sovereign.

What really puts a nail in this definition is what happens when a dependent identity owner wants to become an independent identity owner. In this scenario, the dependent identity owner, having now the means to generate and store his/her/its own private keys, takes the exact same steps as an independent identity owner takes when they first register. But instead of generating a new DID, the dependent identity owner just generates a new DDO for their existing DID—the DID the guardian has been maintaining on their behalf. This new DDO contains the owner’s new public key(s)—the ones the owner generated directly and now controls completely.

The dependent identity owner sends this new DDO to the guardian and instructs the guardian to write it to Sovrin. The very moment that new DDO transaction is accept on the ledger, the owner turns from a dependent identity owner into an independent identity owner.

It’s like Pinocchio turning into a real boy (to use a literary analogy :wink: ).

So this is my (long) way of explaining that on the Sovrin network, all identity owners are in fact self-sovereign, whether no matter whether they are dependent or independent.


#13

@Drummond, I very much appreciate the length and detail of your response. Many things are way much more clear now.

The next technical question comes up, though, with regard to the case where “Pinocchio” wants to turn into a real boy (I can’t help but love that analogy):

If DIDs are designed to be the first half of the “eliptical curve” public key (if I’m understanding correctly), and now this identity owner is generating a new key pair in order to take control of its DID, how can it still retain the old DID while having a newly generated public key?

It’s highly improbable that the old DID is stil “derivable” from the new public key. So, I’m guessing this relationship between the DID and the public key is not a strong one. Right?


#14

@cbruguera You are right. The technical details are covered in more depth in the DID spec (which I encourage everyone reading this thread to become familiar with—it is literally the core DNA of self-sovereign identity). But the basic idea is this: a Sovrin DID (which is just one DID scheme—there will be others for Bitcoin, Ethereum, etc.) is initially generated from a Ed25519 key pair. The 22 character DID is a base58 encoding of the first 16 bytes of the public (verification) key. Here’s an example:

did:sov:21tDAKCERh95uGgKbJNHYp

That means the very first time a Sovrin DID is registered, the DID itself is the first half of the public key (you need to look in the DDO to get the whole public key). However one of the primary purposes of a DID is to give you a permanent digital identifier that never needs to change for a relationship (either a omnidirectional public relationship or a pairwise private relationship) even if the associated public/private key pair changes (which in fact is a good security practice for long-term relationships).

So the fact that when a Sovrin DID is first created it is “bound” to the associated private key is really just a coincidence. The DID identifier string could in fact be any randomly generated string, like a UUID. Using the first half of the Ed25519 public key for a Sovrin DID is just a convenient method of producing a globally unique identifier that happens to have a binding to a private key (which, for the initial registration, is actually a nice security property).

But as soon as the public/private key pair for this DID needs to be rotated or replaced, that “binding” breaks. Now the original DID is just a globally unique identifier string. This is exactly what happens when the guardian for a dependent identity owner replaces the dependent DDO with the new DDO for an independent identity owner (turning Pinocchio into a real boy :wink: ). The fact that the DID was originally half of a public key is now just an artifact of history.

The main takeaway from this is that you always need to treat a DID as just a unique identifier string and nothing more, and thus you always need to check with the ledger (or an unexpired cached copy of the latest response from the ledger) to confirm the current public key for an identity owner.

Make sense?


#15

Great! Thanks a lot! :relaxed: