Section F (on migration) is hand-wavy

This activity is at its heart a migration from one service to another. So Section F (migration) is an important part of the design. The rest of the document does a fine job of explaining how the new service will work and will satisfy ongoing requirements. But the new service isn't filling a vacuum: there are already thousands of people using the existing service with dozens of applications. These applications depend on the identities provided by the service for authentication, and the data returned by the service is used in their internal permissions (authorization logic and configuration). XSEDE identities are "baked into" permissions, access control rules, and group memberships in applications.

• The concern identified in Section F is one of the important issues that arises from the fact that this isn't a brand new service but is a replacement for another service, and I expected to find a specific plan for addressing it in this design document. What specifically needs to happen so that "XSEDE users continue to be properly matched to their Globus Auth identities?"
• A second concern is that any disruption of the XSEDE identity provider service (during the transition) would result in a disruption of the applications (such as the XSEDE User Portal, Jetstream, and Globus) that currently rely on it for logins. Can this transition be managed without a significant interruption of service? What needs to happen and how will it be managed?

Section F simply says that the CILogon and Globus teams will make it work. I don't think the DSR should complete without a description of the key migration & transition requirements and a brief explanation of how they'll be covered.

I don't expect the specific requirements to be terribly complicated. For example, we know which specific fields in the Globus Auth identity (ID Token) are used by most applications (preferred_username, sub) in their internal logic, and we can easily find out how Globus Auth matches identities from an IDP with ones it's seen before (eppn, eptid, with simple rules about how new ones are handled).  A discussion with the Globus team could iron out transition process questions. So I think this section could have a bit more detail and reassurance that the keys are without adding a lot of complexity or "unknown unknowns."