I've trouble understanding security in DID migration

[X-Ryl669]

Maybe it's not clear, but it seems to me that if a user is using a third party service to host his DID document, then the third party service can, anytime, modify the document by generating new key pairs (and thus, creating a valid new DID document that's erasing the previous history of the user).

Imagine GoDaddy used as a domain name manager + web hosting. What prevent them from creating a new @alice.com user that's wiping the previous one, by changing the DNS entry (not even required if it points to their own webserver) and webserver ?

[dholms]

The DID method that we're proposing (did:plc) requires that operations be signed by a keypair that is declared in the DID document: either the signingKey or recoveryKey

The signingKey is held by the user's personal data server, and the user can decide for their recovery key to be held by either their personal data server or by themselves. It's obviously greater responsibility to hold the recovery key yourself, but it protects you against an adversarial pds.

The recovery key has a 72 hr recovery window during which it can "supercede" any operations done by the signing key.

A PLC DID is comprised of a list of signed operations, where each operation must be signed by a current valid key. And the did identifier is derived from the hash of the genesis operation.

This constrains the PLC node to two attacks:

• denial of service: rejected valid operations
• misordering: reordering operations & serving an "invalid" key rotation fork (this is the identity equivalent of the double spend problem)

But the PLC server is not able to forge operations or rotate the users key out from under them.

A PDS is able to "steal" a user's username (just as, for instance, twitter is now). All links to a user at the data level reference the user's did for this reason. But this would dramatically reduce trust in the PDS and the user can always migrate to a new server in that event and keep their social graph & data.

Does that help clear things up?

[AaronGoldman]

I think you are combining two distinct ideas.
The handles are not the same as the DIDs.

@alice.com is a Handle
did:plc:7iza6de2dwap2sbkpav7c6c6 is a DID

When you do a search for a user you would use the handle.
You find a user and decide to follow them.
It may be the handle, phone number, email, or any other means of search that lead you to a publisher but the identifier that is added to your following list is the DID.

Imagine that you used the Twitter "find my friends" feature and found some handle by their phone number. Now they change there phone number. You are still following them even though someone else may now have their old number. It is irrelevant the identifier in the following list is the DID.

A practical example of this is when @Potus was renamed to @potus45 and a new @Potus was assigned
@potus45 => 822215679726100480
@Potus => 1349149096909668363
anyone that started following @Potus from 2017-2021 actually followed 822215679726100480 this account was renamed and any new following of @Potus is a follow of 1349149096909668363
You are actually following UserIDs

In the DID did:plc:7iza6de2dwap2sbkpav7c6c6 the 7iza6de2dwap2sbkpav7c6c is a hash of the first version of the doc. That contains keys and only someone one of the keys can can rotate the keys. so even @alice.com is transferred you still control did:plc:7iza6de2dwap2sbkpav7c6c6

[dholms]

closing for now. feel free to keep the discussion going :)

[X-Ryl669]

But this would dramatically reduce trust in the PDS and the user can always migrate to a new server in that event and keep their social graph & data.

I don't think the user can migrate to a new server if the PDS is the server that's being in charge of the domain name. Because what people will refer to is the username (Aaron used "Handle") not the DID's hash. Ok, they'll see the social graph on the computer where they have interacted with the previous Handle. But as soon as they start a new device, or simply have to give the contact to someone else, they'll send the Handle to a third party. The third party will use that handle and land on the wrong/stolen PDS's identity, right ?

Said differently, a large PDS server might not be tempted to steal a username/handle for its reputation. But:

1. It cans
2. If it does, by simply laziness, I doubt all users will migrate from it. It happens to other, it won't happen to me
3. There's no way a user can get back his/her handle (even if the user changes via his/her recovery key the DID document and sign it, the handle is not managed by the user, right ?)

so even @alice.com is transferred you still control did:plc:7iza6de2dwap2sbkpav7c6c6

Ok, but for an external point of view, you've been stolen the handle. Any new person won't be able to find you since the handle is the "human usable name".

That begs another question: how do you prevent a cyber squatting of handles ?

[dholms]

Yes it's true that if your handle is stolen, you will need to use a different handle. Which is to say, there's still some disruption that occurs if your identity provider attacks you.

However your social (follows) graph is constructed from DIDs so you will keep all your follows & followers. Your display name & profile picture will remain the same. It should be fairly reasonable for your followers to intuit your new handle.

If someone steals a username "for their reputation", they get a new account with 0 followers with that username.

That begs another question: how do you prevent a cyber squatting of handles
Yup this happens in literally any publicly defined namespace 😅
It can be mitigated slightly by making the bar for getting a handle slightly higher: email verification for instance.
However, remember that our handles are namespaced by domain (for instance dholms.bsky.app). If the bsky.app namespace is sufficiently full, users would likely want to register to a different domain