I think this doc should include specific instructions for registering applications with Globus/XSEDE. Specifically, there are registration settings that are vital to making this work.
(1) The Required Identity (formerly Required Identity Provider) option must be enabled and the required identity must be configured to "XSEDE". If this isn't done, then the id_token returned by OIDC probably won't be the user's XSEDE information!
(2) The Required Identity setting must be enabled BEFORE the application is made available for logins, and it must not be changed afterwards. (Set it to "XSEDE" before launching the application, and don't ever change it.) Globus is likely to make this setting change impossible at some point in the future, but even if they continue to allow it, don't do it.
(3) The Preferred Identity Profiler option should be set to "XSEDE" in order to make the behavior described in Section D (page 4) work.
(4) The application name should be chosen carefully so that it's easily recognizable to users in other contexts (the login/logout pages and various Globus account settings pages). It should probably have the word "XSEDE" in it?
(5) XSEDE has an acceptable use policy, so we should probably reference it in our client application registrations? https://www.xsede.org/web/site/ecosystem/operations/usagepolicy The place to do that would be the "Terms & Conditions" field in the client registration. This will make the XSEDE AUP available to users when their consent is requested (page 9, top figure).
The design doc for now simply asserts that the userinfo endpoint will return the XSEDE identity. The actual instructions for how to make it happen, which you have listed are part of XSEDE Identity Management Client Application Setup guide which will be updated once the design doc is finalized.
The XSEDE Identity Management Client Application Setup guide is mentioned as a deliverable in the design doc.
Sounds good to me. Thanks!