Section E.2.5 is unclear about what's required for identity mapping. It first shows the entire id_token and the available fields (which is good), then it says that the preferred_username field can be used to map the XSEDE username to a local account. But then it says that the "sub" field (a Globus-issued UUID) must be used. So what's the requirement?
I'd recommend that the requirement be stated as a list of options, instead.
First, if the application allows it, the best identifier to use would be the "sub" field (the Globus-issued UUID). This is guaranteed to not change as long as the user is registered with XSEDE. Changes to the XSEDE username and email addresses won't affect the mapping.
The next-best choice would be the preferred_username field, which has the XSEDE username. This is guaranteed to not change UNLESS XSEDE changes the user's username, which happens only very rarely, I think?
If neither the sub nor the preferred_username fields are options for the application, as a LAST RESORT, the application could use the email field, which will contain the email address from the user's XSEDE user profile. This is a bad choice for several reasons, not least of which that the chance that the user will change his/her email address in the XSEDE user profile at some point (and thus break the mapping to a local account) is unacceptably high. Another reason: Globus won't know about changes to the XSEDE-registered email address until the user authenticates using the XSEDE username/password, which the user might not do for a very long time if he/she is accustomed to using campus credentials instead. For these reasons, applications should only use the email field for mapping when no other option is available and when they are prepared to deal with frequent user login issues caused by changing email addresses.