Finalizing `Move` Operations: Take Two

[benpate]

I'm withdrawing my proposal in #54 for sending private keys from the source server to the target server. It makes sense to me that users may need to wind down many things on the source server, and that the target server should not try to automate this process.

But we still need to solve the two fundamental problems that #54 would have addressed.

Here's My Use Case

I'm an end user who has just completed the process of copying all of my records from the source profile over to the target profile. I've checked it over and everything is mapped perfectly, and I'm ready to close down my profile on the source server. The spec should enable a single, consistent workflow that doesn't require me to re-enter URLs or usernames. Here what this step currently looks like in Emissary:

Problem # 1 (the little one)

I want to click the blue "Move Your Account" button and bounce over to my old profile on the source server where I can wind down the account. But as the spec is now, this target server doesn't know where to send me. The target server could just send users on their current profile pages, then let them find their own way around the source server to wherever the "export" tools are located. But this process should be better than that, and should get users directly to their next step in the workflow.

Problem # 2 (the big one)

In the current spec, the target server never tells the source server what the new address will be. So even once I get back to my source server, the current spec would require me to manually enter the address that I'm moving to. This is one weakness of using OAuth that wouldn't be an issue with HTTP signatures.

Proposed Solutions

At some point in the process, the source server SHOULD publish a forwarding URL for the target server to use for that blue button, and the destination server MUST send the new profile address to the source server.

1) Source servers add a startMigration endpoint to Actor profiles.
This endpoint could be published in the endpoints property alongside the other data-portability-related endpoints we're adding in this spec. It would take a POST, including the OAuth bearer token and a parameter that includes the URL of the target profile. We should require that target servers call this immediately after receiving OAuth tokens, and before retrieving records from the source server. This way, at any future step in the process, the source server can display this information to users signing in to their old profiles.

2) Source servers add finishMigration endpoint to Actor profiles.
This endpoint could be published in the endpoints property alongside the other data-portability-related endpoints we're adding to this spec. It would simply be the URL on the source server where the user could close down their account and initiate the Move announcement, so it would be a GET endpoint that target servers would forward users to when they're ready to finalize their migration and they click that blue button above.

With these two additions, I believe we will have a clear workflow for users that keeps their private keys secured on their original servers. I'm happy to write this up as PR if there's a consensus on these changes.

[lisad]

Yeah this would all be great. I just wonder if it should be a core part of LOLA or part of the next iteration. It depends how much work implementors are ready to do.

[benpate]

There's two separate issues that I bundled together because I'm proposing similar solutions (using endpoints).

I think LOLA should include the startMigration endpoint (or something similar) because otherwise, the source server has no way of knowing where the data is going -- which means that it can't issue a Move at the end of the process. Without this, the user would have to manually enter their new address, which seems error prone at best.

The finishMigration is a nice-to-have, and could be a follow-on, or a related FEP if you want to go that route. Fortunately, it's just a URL that directs the workflow to its final step, so it's very easy to implement. And, it's pretty easy to work around if the source server doesn't publish this value. I'd suggest adding it into LOLA as a "SHOULD" recommendation, and saying that target servers "SHOULD" just redirect users to their old profile home page if it doesn't exist.