MySpace OpenID Popup spotted in the wild

DeWitt Clinton dewitt at unto.net
Fri May 1 18:19:07 UTC 2009


I agree that browser support is ultimately the best way to address the
issue.

At SW Foo we briefly discussed an idea to drive client adoption of this not
through openid, per se, but rather by trying to standardize the flow by
enhancing HTML5 itself.  Browsers could implement this in the way they best
see fit, which would create a competitive market for the underlying
implementations (openid or otherwise).

Something as simple as:

  <form *type="login"* method="POST" action="http://example.com/login/">
    <!-- regular HTML username and password form here -->
  </form>

Where the type="login" establishes a contract that allows the browser to
replace the inner HTML with an implementation of choice that will POST a
user's credentials, after the user allows it, to the action URL in a
standardized format.   A dumb browser would ignore the type and act as a
normal login form.  Whereas an OpenID-aware browser would rely on the user's
preferred IDP to fetch profile data, and perhaps does so via native chrome,
even skipping ungainly login steps at the IDP if desired.  Other types of
browsers might support other mechanisms like InfoCards, or protocols that
haven't even been considered yet.

The important thing is to standardize both the hint to the browser that it
is a login form (i.e., the invented type="login") and the format of the data
that is ultimately POSTed to the server.

One could also extend HTTP 'WWW-Authenticate' response headers to indicate
that a particular page accepts the above login flow, so that a smart client
could negotiate the login behind the scenes without bothering the user on
return visits.

Might be nuts, I don't know...

-DeWitt

On Fri, May 1, 2009 at 10:47 AM, Brendan O'Connor <openid at ussjoin.com>wrote:

> On Fri, May 1, 2009 at 1:35 PM, Johannes Ernst
> <jernst+openid.net at netmesh.us> wrote:
>
> > If we could get the browser developers to add anything we wanted to their
> > browsers, what *exactly* would we want them to implement?
> > This is not outlandish. The Mozilla folks asked repeatedly in the past
> (and
> > we never knew what to say in response) and the security of a billion
> OpenIDs
> > is not a set of user requirements that's easily dismissed either.
> > It appears that it would be some kind of user interface element (think
> > "popup" for a minute) that could display the OP's authentication
> ceremony.
> > But where the browser would somehow "certify" that it was not a phishing
> > attempt and came from one of the user's trusted OPs. In a way that is
> better
> > than having the user to do a string compare on the URL shown in the
> address
> > bar.
> > What would such a user interface element look like? That's not limited to
> > what we can do without cooperation from the browser guys.
> > In Firefox, it could be sitting in the side bar for example. (where the
> > bookmarks are) Or ...?
>
> Why not Seatbelt? I mean, naturally, a reimplemented version, but it
> seems to solve the UI/UX issues pretty nicely. It just sits quietly
> down in my status bar, and only pops up if I try to log in somewhere--
> and it always displays my current logged in / logged out status. And
> it can be configured for any OP.
>
> <https://addons.mozilla.org/en-US/firefox/addon/5133>
>
> ---Brendan O'Connor
> _______________________________________________
> user-experience mailing list
> user-experience at openid.net
> http://openid.net/mailman/listinfo/user-experience
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-user-experience/attachments/20090501/2c606262/attachment.htm>


More information about the user-experience mailing list