On Wed, Jun 9, 2010 at 1:58 AM, Ben Laurie <[email protected]> wrote: > On 8 June 2010 18:38, John Panzer <[email protected]> wrote: > > On Tue, Jun 8, 2010 at 7:07 AM, Peter Watkins <[email protected]> wrote: > >> This is a great example of why this should be in-browser. With an > >> in-browser > >> solution, a user could be prompted each time an RP asks for XAuth > tokens, > >> and could decide at that time which IdP tokens to reveal, and whether to > >> always reveal the same set to that RP, etc. Users would only be prompted > >> about the tokens they actually possess, and the RP sites they actually > >> viist -- solving the privacy/disclosure NASCAR problem efficiently. > > > > I think this would be a poor UI too -- it's well known that most users > will > > simply end up clicking "OK" in this situation, and the experience is > worse. > > But without getting into that argument: You could implement essentially > > the same UX using JS -- the RP doesn't get the data sent back via > > postMessage() unless the xauth.org JS says it can. You could probably > have > > a better UX with an in-browser solution, but not a qualitatively > different > > one. In other words, this is not a strong differentiator for in-browser > vs. > > JS solutions. > > > I don't quite understand what you mean by "click OK" in this case? The > user will be presented with a choice of IdPs and will have to choose > one - there is no "OK" to click. However, having the user choose which > IdP to present to the RP seems like a win to me, regardless of whether > this is in-browser or xauth JS. See http://www.links.org/?p=938. >
My interpretation: In the common case, the user would have exactly one IdP and would be choosing whether to tell the RP about it -- so in effect it'd be an OK button.
_______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
