Transfer of DIDs or claims


#1

Is it possible for the ownership of a DID (or a claim about a given DID) to be transferred to another identity?


#2

The DID spec says that ownership of a DID should NEVER be transferred. In other words, a DID assigned to a person should only ever be used by that person. A DID assigned to a business should only ever be assigned to that business.

The same applies to a claim associated with a DID. That claim is only about that DID—it cannot be transferred to another DID.

Note that the identity owner MAY be able to prove ownership of more than one DID, and thus that a claim against DID #1 is also a claim against DID #2. But that “proof of equivalence” is a separate (and thorny) issue that the DID spec authors decided to not put in DID Implementer’s Draft 01. See the Future Work section.


#3

Absolutely clear. Thank you very much.


#4

Also the new owner would need the initial owner’s private key to confirm they signed the DDO within the DID.


#5

Is there a use case you’re imagining @cbruguera?


#6

@phil Not really

Well at some point I was just wondering if a trust anchor might register a DID on behalf of the user, and then it could transfer the proper ownership when certain conditions are given. But I’m guessing there are other mechanisms to achieve that. And it makes total sense for identity to be non-transferrable.


#7

Carlos, I’m really glad you mentioned the precise use case you had in mind because that’s different!

What you are describing is not “transferring an identity (DID) to a new owner” but “registering an identity (DID) on behalf of an identity owner who is not yet able to control the private keys for it”. We call that a guardian relationship. See the definition in glossary (section 3) and section 6.3 of the DID Implementer’s Draft 01.

When a DID is registered by a guardian, it fulfills the definition I gave you because it represents one identity owner, and the guardian cannot “change its mind” and reassign it to another identity owner. So when the guardian finally turns over control of the DID to the original identity owner (because now that identity owner can control his/her own private keys), it’s not reassigning the DID, it’s just giving full control of the DID to the rightful owner.


#8

Perfect, that pretty much solves the use case.

Thank you very much.


#9

Since we’re already on the subject: are there any fields/aspects of an Identity DDO that could be modified by the owner/controller? Does it make sense to “edit” the data? Same question applies for claims… Is there something somehow editable or everything is completely immutable?


#10

My understanding is that once the DDO is written, it’s immutable and changing it involves associating the DID with a new DDO.

I asked a related question here: Updating DDOs regarding frequency.


#11

IIRC you can’t change the content of the DDO but can write a new one.

For claims, if you already possess a claim that was issued to you (e.g. by a bank), that claim will have been signed. If you change it without re-signing it, it will be invalid. So you’d need the issuer’s private key to change the claim.

For revocation of claims that have already been issued, that’s covered by the amazing work done by Jason and the team to allow anonymous revocation of claims.


#12

Sorry I have been traveling and am just now able to get caught up on this thread.

RE Carlos question, the DDO associated with a DID is by definition the “genesis claim” of the identity owner (unless written by a guardian - see below). Therefore the identity owner is the ONLY one who can edit it. And yes, the identity owner can indeed edit it at any time. As Phil says, the identity owner does not do that by changing the old DDO—it’s immutable—but by writing a new DDO that supercedes the old one. This is in fact how the identity owner does public key revocation and rotation, since that’s one of the primary elements of a DDO.

And yes, Andy is correct, if a DDO is signed, it is signed by the identity owner’s own private key, so again, the identity owner is the only one who can sign it. Note that it is not actually required to sign a Sovrin DDO because the only way to update the DDO is to sign the transaction with the Sovrin ledger, so the signature on the DDO is actually redundant.

Lastly, everything I said above applies to DIDs registered directly by identity owners who control their own private keys. There is a second type of registration by a guardian who registers a DID and DDO on behalf of an dependent who does yet have the ability to control their own private keys. See section 6.3 of the DID Implementer’s Draft 01.


#13

Thanks to all, that very much answers my question.


#14

I would like to follow up this subject with a question still remaining, very much related to the concept of “updating” identities.

(I’m assuming that identity objects are indeed “modifiable” in the sense that a new DDO object would be linked to the corresponding DID, given that the object is being “edited” by an entity which has the proper permissions/control/ownerwhip)

How would the “right to be forgotten” be implemented in this model? Have you contemplated the “deletion” of identities? Maybe a DID now pointing to an undefined or empty DDO? Maybe a DDO that is marked as “deleted” or disabled somehow? Which possible implementations make sense within the model that is being envisioned by the Sovrin community (and especially Evernym, which is currently the head of Sovrin development)?


#15

Carlos, sorry to be slow in responding—I have been traveling the past few days.

First, RE your question of whether a DDO can be updated—yes, absolutely, in fact it is one of the requirements of the DID specification that an identity owner (or a guardian) must always be able to update the DDO for a DID registered to that owner (see section 7.3).

Secondly, the question you asked about the “right to be forgotten” is actually a very important one that helped guide the development of DID and DDO architecture. The reason is that, as you point out, distributed ledgers are immutable. So if you put any PII (personally-identifiable information) into a ledger—even encrypted—it can’t be “forgotten”.

The solution comes down to this: do not put any PII into a public ledger. Rather a DDO should only contain public data that describes how you can interact with an identity owner without revealing any private data about the identity owner. That’s why the DID spec for DDOs include public keys (for securing communications) and service endpoints (for interaction) but no PII.

Thus any PII or other private data that an identity owner may choose to associated with a DID should be: a) stored someplace off-ledger (e.g., by a Sovrin app or agent), and b) shared peer-to-peer with relying parties under a link contract that gives the identity owner the right to assert the right for that private data to be forgotten

I should note that, with this design, Sovrin infrastructure is in fact ideal for implementing the right to be forgotten because a signed link contract stored with a Sovrin agent gives an identity owner his/her own tool for exercising that right at any time. Rather than the identity owner having to: a) navigate to the correct page of relying party’s website (or worse, call a call center), b) re-authenticate themselves to the relying party and c) identify the data to be forgotten, the identity owner can simply instruct his/her Sovrin agent to send a digitally signed “forget me” request to the relying party. That request will include the link contract under which the private data was shared (which includes the identity owner’s DID). Once the relying party verifies the digital signature on the forget me request, the relying party will have everything it needs to delete the private data and returned a signed acknowledgement that it did so back to the identity owner, plus the audit trail necessary to prove compliance to a regulatory body.

How’s that for Privacy by Design?

Lastly, you asked what if an identity owner wants to completely disable and revoke a DID. Once again this is a requirement of the DID spec—see section 7.4. Every DID method (definition of how DIDs are implemented on a specific distributed ledger) MUST define how to do this. With regard to the Sovrin DID method, your guess is exactly right: the identity owner simply points the DID to a null DDO. That’s “DID death”.


#16

Thank you very much!