There’s been enough discussion about the importance of encouraging and providing means favoring the non-correlativity of identity data belonging to a particular identity owner. However, there might be (and there’ll surely be) cases where correlativity is desirable. Which mechanisms might be put in place in order for such links to be effectively made between scattered claims/data pertaining to a single entity that is desiring such data to be correlated?

For example, certain institution might need to quickly record new identities on the ledger corresponding to customers (or members) of such institution and these identities might be associated with certain claims signed by the institution… Afterwards, those identity owners might want to claim that such already-verified data corresponds to them. What are your views on the appropriate and practical manner to link scattered ledger-data in order to prove some form of correlation under a single identity?

Carlos: your question goes to the heart of Sovrin privacy architecture. The basic idea is that Sovrin identity owners are the only ones who can correlate and prove claims about themselves to the relying parties of their choosing. One way they can do that by is proving that they control the private keys for the DIDs used by any set of claims. Of course when they do this, they correlate those DIDs. So the second way they can do that is by sharing one pairwise-unique DID with the relying party and then using anonymous credentials to prove any other claims that the relying party needs.

Both methods work. It’s worth noting that with both methods, the actual claims are not only the Sovrin ledger. Only the DIDs and public keys and agent endpoints (and, if needed, the revocation materials) are on the ledger. The rest of the claims are held with the identity owner’s Sovrin agent, and they are exchanged with relying parties directly agent-to-agent. This maximizes the identity owner’s control over privacy.

What about third party “correlational” claims on the ledger itself? Let’s say an institution is the owner of a claim that verifies some personal information relating to my identity, yet this claim is done before I even own a Sovrin Identity. After I effectively get to create an self-sovereign identity on Sovrin, I might like to be able to prove that this previously existing institution-backed attestation relates to my persona… How do you see this fitting into the Sovrin scheme?

Maybe the institution would need to make a second claim that links the two other (the previous ID verification and my current personal DID)? On the other hand, what if an institution (or any party whatsoever) makes a claim about my persona that I don’t approve? Maybe this “correlational” claim would have to be signed by both the institution and myself?

Carlos, it’s a good question where “pre-existing claims” about a Sovrin identity owner fit. IMHO the answer aligns directly with the principle of self-sovereignty—that an identity owner must be able to fully control their own identity graph—and the principle of verifiable claims—that every identity owner should be able to make claims about any identity that can be verified as having come from that identity owner.

So let’s walk through applying these two principles to your use case. Let’s say Institution A creates claim X about person B using identifier AB before person B has a self-sovereign identity. That claim might in Institution A’s directory service someplace and can be looked up using the identifier AB that Institution A assigned to person B.

Now person B gets a new Sovrin identity with identifier DID B that person B fully owns and controls, fulfilling the self-sovereignty principle. Person B would like to have Institution A make the same claim X about Person B’s new Sovrin identity. Person B could self-attest that Institution A had made claim X. But because it was self-attested, it would not be verifiable.

The only way for claim X to become a verifiable claim would be for Institution A, with it’s own Sovrin identifier DID A, to make claim X about Person B, and then sign that claim with Institution A’s private key so that it is verifiable. If Institution A shares this verifiable claim X with Person B, now both Institution A and Person B can tell anyone who is interested that Institution A with DID A has made claim X about Person B with DID B, and anyone can verify this signature by looking up DID A on the Sovrin ledger to get the public key for Institution A.

The critical takeaway from this is that neither Institution A or Person B should be trying to create a correlation between Institution A’s original identifier AB for Person B and Person B’s new Sovrin DID B. Institution A’s identifier AB should stay private between Institution A and Person B. Instead, Institution A should make a new claim X against Person B’s Sovrin DID B, as only DID B is self-sovereign and fully under Person B’s control.

Note that this self-sovereignty applies equally to Institution A. In other words, even though Person B is self-sovereign for DID B, Institution A is self-sovereign for the claim X that it makes about Person B. So if for example Institution A needs to revoke claim X (say claim X is a claim that Person B is a student at Institution A, and then the student withdraws from school), then Institution A is able to revoke claim X and does not Person B’s (or anyone else’s) permission to do so.

Now, about your final question, [quote=“cbruguera, post:3, topic:150”]
What if an institution (or any party whatsoever) makes a claim about my persona that I don’t approve?
[/quote]

By following the same two principles—both self-sovereignty of identity owners and self-sovereignty of claims issuers—the answer must be that anyone can create a claim about anyone—true or false, positive or negative. Sovrin infrastructure itself does not say anything about whether a particular claim is true or false or positive or negative. What Sovrin lets you do is verify that a claim was made by the claim issuer and verify that the identity owner presenting that claim really controls that Sovrin identity.

This is important as it means any kind of claim system or reputation system can be built on top of Sovrin and they can all work independently, without needing to interoperate if that is not necessary. If they need to be interoperable, then that puts additional requirements on the format of the claims or reputation statements they make—which is obviously very important—but that level of interoperability lies at a layer above the Sovrin identity layer.

@Drummond I know this is an old thread, so I hope you don’t mind me resurrecting it for a bit of clarification.

Drummond:

The only way for claim X to become a verifiable claim would be for Institution A, with it’s own Sovrin identifier DID A, to make claim X about Person B, and then sign that claim with Institution A’s private key so that it is verifiable.

If correlation is expressly being avoided via the use of multiple DIDs, what would be the impetus for Institution A to issue a claim about Person B before that individual had become sovereign? Given that Institution A is apparently required to issue a second DID after Person B has become sovereign in order for Person B to have any benefit from the claim, why would Institution A not wait until Person B requested the issuance and avoid the double work? Perhaps I’m missing a benefit to the network or the issuer that would encourage such behavior?

They probably would wait. I think this scenario where a person has a credential with a correlated ID before they start using Sovrin is a bit of an edge case if you think about it technically, but it does occur when you look at physical credentials that might become digital through Sovrin.

For example, I have a driver’s license from the state. They might offer me a digital credential using Sovrin and thus “reissue” the credential but it’s the first time I’ve gotten a digital credential from the state. Or maybe they’re switching systems from a digital driver’s license solution that is based on an app to one that uses Sovrin and so the credential would be reissued.

For the most part reissuing credentials isn’t going to be much work and won’t necessarily cost the issuer much, so I don’t think reissuing credentials is going to a big deal. In many cases credentials are going to be self-service and be issued on demand. For example, my bank might have a place I can request a credential about my average daily balance for the last month that I can request any time I need it.