Version 1.1 of section E.2.5 is more extensive than the previous version and introduces new requirements. As stated in version 1.1, all of the points listed are required from all clients.
Many of our clients are implemented using off-the-shelf OIDC plugins that don't provide XSEDE-specific functionality. (This is a benefit of our design because it makes adapting client applications much easier.) Putting a bunch of XSEDE-specific requirements on clients makes it harder to adapt client applications to XSEDE, which seems like a bad thing. I don't believe that all of these are necessary.
I recommend that this list of requirements be paired down significantly to include only the bare minimum that are necessary to ensure the application works with XSEDE and is secure. The remaining items should be left as an additional set of recommendations that should be implemented when possible, but not if it means the difference between an application being able (or not able) to use XSEDE Web SSO.
Item (a), for example, is a very good practice and would guard against one known corner case in using Globus for Web SSO. However, I'm not aware of OIDC plugins for applications that can provide that functionality. (E.g., Moodle, Drupal, WordPress, Atlassian apps.) Rather than exclude these or force XSEDE operators to fork the plugin code and maintain their own XSEDE-specific versions, it would be better in my opinion to allow some flexibility.
Same argument for (d) and (e).
I am unaware of a specific requirement driving item (f) in the list. Is it truly necessary? What requirement does it satisfy?
Item (g) seems to preclude application-specific user profiles. Again, is this truly necessary? Why don't we want to allow individual applications to allow users to have their own profiles specific to the application? Why shouldn't I be able to set the email address used by a Moodle training site to something different than my XSEDE user profile?