[OpenID] One-Click OpenID: A Solution to the NASCAR Problem
Francisco Corella
fcorella at pomcor.com
Wed Feb 15 22:23:56 UTC 2012
Dick,
> The ad-hoc HTTP header and ad-hoc HTML tag are not needed to solve the
> NASCAR problem. By adding code to the browser, you could work with
> existing OpenID providers and RPs.
>
> We did this with Sxipper 4 years ago. Sxipper remembered your OPs,
> detected an OpenID login form, and allowed the user to select which OP
> to use at the RP. It remembered which OP you had used at that RP last
> and put it on top. It detected when you logged into an OP to add it to
> the list of OPs available.
>
> Detecting RP forms and OPs was non-trivial, and some additional HTML
> markup would have made it easier and more robust.
Our approach doesn't use markup for detection. The markup we use is
an <idp> element in the RP's login form whose value is the data
associated with the IdP, i.e. the identity provider, a.k.a. OpenID
provider, a.k.a. OP, that the user wants to use for this particular
transaction. The brower is free to use any method it wants to
determine which OP the user wants to use among those recorded in the
user's preferences.
It's not a good idea to detect an OP automatically, as you seem to say
Sxipper used to do, whether the OP is detected using a heuristic or
using explicit markup in the OP's site. The user may very well use a
site that offers an identity provider service, and even have an
account at that site, without wanting to use the identity service.
For example the user could use Yahoo as an email service provider
while using Wordpress as an OpenID provider. It would be wrong to add
Yahoo to the list of identity providers just because the user logs in
to Yahoo to process its email. In our approach Yahoo has to offer its
identity service to the user, and the user has to accept it explicitly
by clicking on a link or button. In response to that click Yahoo
downloads identity provider data in an ad-hoc HTTP header, causing the
browser to add Yahoo to the list of identity providers in the user's
preferences, after asking the user's consent.
> As I stated before, this does not solve the problem for users without
> an enhanced browser.
As I said before in response to your earlier statement, the relying
party can easily detect whether the browser is enhanced or not, and
fall back on an ordinary OpenID interface if it isn't.
Francisco
>________________________________
> From: Dick Hardt <dick.hardt at gmail.com>
>To: Francisco Corella <fcorella at pomcor.com>
>Cc: Markus Sabadello <markus.sabadello at gmail.com>; Chris Messina <chris.messina at gmail.com>; OpenID General <openid-general at lists.openid.net>; Karen Lewison <kplewison at pomcor.com>
>Sent: Tuesday, February 14, 2012 11:29 PM
>Subject: Re: [OpenID] One-Click OpenID: A Solution to the NASCAR Problem
>
>
>
>
>On Feb 14, 2012, at 11:01 PM, Francisco Corella wrote:
>Everybody:
>>
>>Before telling me that what I'm proposing has been done before, please
>>read what I'm proposing.
>
>I did.
>
>
>The user clicks on the button and is
>>automagically redirected to her preferred OpenID provider, even if the
>>relying party has never heard of it.
>>
>
>
>got that the first time, see below
>
>
>>Hint: if you want to criticize this, you could criticize the fact
>>that it requires an ad-hoc HTTP header, and ad-hoc HTML tag, and new
>>browser functionality.
>
>
>The ad-hoc HTTP header and ad-hoc HTML tag are not needed to solve the NASCAR problem. By adding code to the browser, you could work with existing OpenID providers and RPs.
>
>
>We did this with Sxipper 4 years ago. Sxipper remembered your OPs, detected an OpenID login form, and allowed the user to select which OP to use at the RP. It remembered which OP you had used at that RP last and put it on top. It detected when you logged into an OP to add it to the list of OPs available.
>
>
>Detecting RP forms and OPs was non-trivial, and some additional HTML markup would have made it easier and more robust.
>
>
>As I stated before, this does not solve the problem for users without an enhanced browser.
>
>
>-- Dick
>
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-general/attachments/20120215/a07d7fe9/attachment.html>
More information about the general
mailing list