[security] browser integration?
Chris Messina
chris.messina at gmail.com
Thu Apr 5 23:33:02 UTC 2007
As far as I know, it's not been decided and I don't know where the
conversation is, but this sounds more like a short-term hack... it's
similar to what MyOpenID demands now if you activate Safe Sign-on.
I think the better approach is to think about a chrome-level interface
that takes some inspiration from CardSpace and uses the card metaphor
where users choose from a visual list of identities (served by one or
more iDPs) that they want to represent them at a given site.
Bookmarklets are easy for those of us who understand that clicking
something in our bookmark bar can do more than just open links; I'm
not sure it's reached widespread understanding that this basic piece
of interface can be used to launch scripts and the like...
I'd still like to see more thought (I should do this as well) put into
OpenID in the browser, but I'd essentially like to see a mashup of
CardSpace with Apple's Keychain management interface. Oh, and single
sign-*out*.
Chris
On 4/5/07, John Fraser <showdown at attacklab.net> wrote:
> Hi,
>
> New here. Has the shape of Firefox's OpenID support been decided yet?
> If not, here's an anti-phishing suggestion that should be easy to
> mock up with bookmarklets.
>
> The idea is to move away from redirection and towards proactive,
> out-of-band login. Users would log in to their OpenID providers
> *before* signing in to RPs -- ideally with a single click in the
> browser's chrome on a page with an OpenID prompt. The browser would
> contact the user's OP and submit a checkid_setup request on behalf of
> the current page (opening a new window if necessary), autofill the
> OpenID URL on the RP's page, then leave it up to the user to submit
> the form. Once that happens, the RP would authenticate exactly as it
> does now -- but it should never need to redirect the user to a login
> screen, since the OP already knows to approve its request. It's kind
> of like making an extra trip to myopenid.com and clicking "allow
> forever."
>
> OPs could implement this right now, and use bookmarklets to make it
> user-friendly. They'd need to add an extra parameter to
> checkid_setup, which would tell the OpenID server that "approve once"
> should actually mean "approve on the next attempt," and that it
> shouldn't redirect the user. None of this requires any change to the
> RP; it's all between the OP and the OP's bookmarklet -- in fact, it's
> only worth standardizing if browsers really are going to get in the
> game.
>
> There would be some hacky implementation details (like identifying the
> "next attempt," since you don't have access to trust_root), but it
> should be possible to build something that works pretty well right
> now.
>
> - John Fraser
> _______________________________________________
> security mailing list
> security at openid.net
> http://openid.net/mailman/listinfo/security
>
--
Chris Messina
Citizen Provocateur &
Open Source Ambassador-at-Large
Work: http://citizenagency.com
Blog: http://factoryjoe.com/blog
Cell: 412 225-1051
Skype: factoryjoe
This email is: [ ] bloggable [X] ask first [ ] private
More information about the security
mailing list