I think the application developer document could use some clarification on pages 2-3 as to what constitutes "Login with XSEDE" vs. "Login to XSEDE". After talking with JP, I realized that I was not correct in equating "Login to XSEDE" to a web login to XSEDE systems like comet, stampede etc. Using XUP as an example of "Login to XSEDE" was a red herring to me since I think of being able to access compute resources directly through the XUP.
Perhaps a better definition would be to say that "Login with XSEDE" means the user can authenticate to this application with XSEDE, but it is not a Single Sign-On so the user is not also logged into other XSEDE applications like the XUP, JIRA, Confluence etc. Conversely, "Login to XSEDE" means that by logging into this application the user is also logged into all XSEDE SSO applications like the XUP, JIRA, Confluence, etc.
I think the button in the Confluence screenshot in the application developer document should then be changed to "Login to XSEDE" as it uses SSO, and the XUP screenshot should be changed to "Login with XSEDE" as JP said they intended for non-SSO to be the default.
If the difference in button wording is due to one being a SSO and the other not being a SSO, I personally think SSO should be included in the text. For example, "XSEDE SSO Login" vs. "XSEDE Login". Keeping the current wording is fine though, as long as the developer document is more clear.
The difference has nothing to do with SSO. I hope you didn’t get that idea from the developer documentation? (If so, could you point out where?) There’s only one application that uses this service that doesn’t provide SSO: the XUP. The XUP team insisted on using the service in a way that (as a side-effect of their choice) wouldn’t provide SSO. This won’t likely be repeated for other applications. It certainly isn’t the reason for the “to” vs. “with” distinction.
The reason for having a “to” version and a “with” version is because some apps are viewed by users as being part of XSEDE and others are not. If the app is viewed as being part of the XSEDE system, the developer should use “Login to XSEDE.” If the app is not viewed as being part of XSEDE (e.g., a science gateway), the developer should use “Login with XSEDE.”
Things like the CSR are in a gray space between these two options. The new CSR says “powered by XSEDE,” which implies it isn’t part of XSEDE. But the relationship is very close nevertheless. In cases like these, we need to make a best guess as to which makes the most sense to our users.
Is the wording in the developer documentation unclear about this?
Is the fact that an app is running under a <something>.xsede.org hostname what determines whether users view it as part of XSEDE? Maybe we should emphasize the service hostname and not how users might view it.
Notice also that Kate's confusion/question had also to do with the (mis?)perception that the "XSEDE system" is just the HPC resources. This is a point we should scrutinize a little more and make sure that we make it clear that from a Web SSO perspective the term XSEDE System applies to any/all services available thru a *.xsede.org service name (HPC, web sites, etc.).
JP
Thanks Lee. My conclusion that the text difference had to do with SSO was from a conversation with JP and not the documentation. I understand now that the intent is the application's association with XSEDE. If the difference isn't SSO though, I don't understand why there are two separate wordings because clicking on the button does the same thing then (logs in with XSEDE accepted credentials). I think having two wordings leads to confusion and less consistency of button styling across applications. If a developer doesn't easily understand the difference, how would a regular user know?
Thank you, JP. That could be the clearest way to distinguish when to use the different buttons. I’ll make the changes to docs and let you know when they’re ready. (I don’t think I have write access to at least one of the locations.)
A new version of XSEDE Web SSO for Application Developers (v1.1) has been posted with this change, among others. Thanks for the helpful feedback.