1) The number of combinations that that single UI is expected to support is daunting
- whether the user is new or existing
- whether the user is local or federated
- whether the user enters an email address, an OpenID, or a domain
Is it over reaching to expect that a single textual change to the Buy.com UI model (which was designed to support only a fraction of the number of combinations) will adequately support the additional ones?
2) It's by presenting an email address to the RP that the User drives IdP selection (or kicks off a local registration/login). And choosing an IdP can be equivalent to choosing a persona.
But the suggested prompt of 'Enter your email address' doesn't, I think, make this as clear as it could, i.e. that a consequence of whatever email the User provides will be them presenting a different persona to the RP (different values for shared attributes etc)
Clearly Users are more and more comfortable presenting different email addresses in different contexts, but I'd argue that their current choices are driven more by spam routing than by the desire to present a different view of themselves appropriate to a context.
3) although the doc refers to OpenID, there are many references to 'trusted IDPs' - implying that the RP has a whitelist.
If the RP didn't have a whitelist to check provided email addresses against, the RP wouldn't be able to tell the difference between
a) a user trying to create a new local RP account against their email provider address
b) a user trying to kick off OpenID SSO through an unknown (to the RP) OP
because in both cases the User would select the 'No, help me log in' option.
4) A paragraph about trust models and assurance requirements seems out of place in a proposal for UI
How an RP indicates to the User 'Sorry, I can't do business with the IDP you suggested' would be an important piece (and one ripe for IDP placement battles)
"While Google has had good results with this user interface, it still requires the RP to trust the IDP. In some cases, it will be difficult for the RP to trust any IDP. For example, Google offers the Google Checkout service which lets users pay for purchases they have made on other websites. This requires Google to meet many special certification requirements that traditional e-commerce site do not need to worry about, including special certification on how we authenticate our users. Online banks similarly have certification requirements on how they authenticate their end-users."
5) The doc suggests there is a privacy risk associated with opaque identifiers
If the IDP supports using opaque identifiers ..... The primary privacy concern of this option for some users is that if they are logged into the same IDP on two different machines, then RPs can track their activity across those two computers. Of course some users may not want to be tracked in that manner, while others will consider it a helpful feature to make their Internet experience more "portable" across computers
I'm missing something. In a non-federated case, if the User didn't want the RP to track them across computers, then they'd have to create different RP accounts for each computer. In a federated scenario, if the User wanted the same privacy, then they just need to ensure that the IDP provides a different opaque identifier each time they access the RP.