Google Code Source Code Browser Released It’s just my email password…
Mar 19

Gears Future APIs: OpenID and OAuth

Gears, Tech, Web Browsing with tags: , Add comments

Single Sign On

When I was looking over Brad Neuberg’s Paper Airplane thought experiment I noticed the single sign on feature, where you login to the browser, and then you are done.

I realized that this is what I actually want. Having one signon via OpenID is really nice. It allows me to plug in “” as my identifier. However, I always have to go around finding the OpenID option (if it exists) and put that in.

What I really want is for the browser to do that work for me. If a site groks OpenID the browser should be able to pass that over without having me intervene at all. It could hide the entire login process if we came up with a microformat to let all sides know what is going on.

It would be a breath of fresh air to be able to jump through sites leaving comments on blogs, and checking out my todo list, all without me once having to actually login.

I wonder if a Gear could be made with a complementary microformat / server side handshake that could then give us single sign-on in all of the browsers.

As Brian McCallister suggests:

<link rel="openid-auth" href="..." />

Other Future APIs

Disclaimer: This is me rambling about APIs and tools that I would love to see in Gears, or the Open Web as a whole. Do you have ideas for cool Gears that make the Web better? Let us know!.

14 Responses to “Gears Future APIs: OpenID and OAuth”

  1. Ian Lewis Says:

    I read your post earlier but I started thinking about it more after reading about how journalists read about Ashley Alexandra Dupre (from the recent New York Governor sex scandal) from her public social networking profiles ( A lot of bloggers and technology people have talked about social networking sites and privacy, but essentially social networkers give up this privacy readily because it’s convenient for friends/family who don’t have a login to SNS to be able to view the site without creating an account.

    The reason I mentioned all of that is that this (given some time and some ease of use features, like bundling the browser by default) sounds like it could be a easy way for folks to maintain their privacy while at the same time being able to view profiles and blogs of friends and family without having to create logins on every site.

  2. Brian Says:

    This would be really nice. Combined with the Gears Desktop API, you could open a shortcut to an online word processor with login happening behind the scenes and perceive very little difference with opening a shortcut to a Word document on your desktop.

  3. Dimitri Glazkov Says:

    I am very interested in making this happen and I am working on a concept. Might as well spill it here: my approach (at least, what I have so far) involves using long-running (resident) worker (similar to a greasemonkey script in that it’s installed once). The worker represents an OAuth/OpenID provider. I’ll post more on the google-gears-eng list soon.

  4. Jadon Says:

    I think you are on the right track, but you have to look at the root-of-trust. You need to be able to prove you own ‘’ namespace. The thing to note is that you need some way to have a unique claim on some chunk of namespace, and that cannot be fully distributed.

    I do like the idea of having your browser contain a web server to answer requests (and suggested the same thing to Brad: Combined with the Paper Airplane model of grabbing a chunk of namespace on a first-come, first-serve basis, has a lot of potential in my mind. It could introduce some ugly identifiers used to guarantee that the JXTA space where you claim your name is truly unique. And, it would still ultimately depend on the authority of JXTA servers to be certain you aren’t being spoofed.

  5. Hans Granqvist Says:

    I like the browser to handle this for us.

    I tend to think the entire idea of a user having to login at the site is an anachronism! Once logged into the browser, the site should be able to figure out who you are automatically and whisk you to your personalized landing page directly.

    The best part is that it can be made with no change to the OpenID protocol. I wrote more about it here:

    I’d be curious to see how that could fit with your ideas.

  6. Dave Brondsema Says:

    Does the Seatbelt Firefox extension at do what you’re looking for?

  7. Brad Neuberg Says:

    [Cross-posted from Ajaxian]

    This is part of a larger idea from the Paper Airplane project called The Smart Browser where we move standardized UI more into the browser and out of web sites, such as signing in, joining groups, recent updates, etc. The browser then interacts with the remote web site through a web service/microformat, formatting its chrome UI appropriately. More details here in the Paper Airplane paper I put out a few years ago:

    An excerpt:

    “Tools for navigation in browsers progressed rapidly in the early days of the web, until they finally froze at their current state in about 1995 and have remained relatively unchanged. This is sad as the brower could standardize and embed many tools for much more sophisticated ways of dealing with web sites, especially around collaboration. It’s time for innovation.

    Paper Airplane takes this to the next level with the concept of the Smart Brower, where the browser embeds standard navigation controls across the Two Way Web Sites [Brad: Two Way Web Sites were the name of for a new kind of web-site that embedded Wiki-like collaboration deeply into the web] it creates. This section discusses how the Smart Browser makes end-user’s lives easier.

    First, Paper Airplane embeds single signon. When a user first starts Paper Airplane they authenticate themselves against the browser, using a signon dialog to unlock a public/private keypair that is stored on the local machine. This public/private keypair is linked to a handle, similar to an AOL screen name, that is globally unique. It does not establish that they are a specific person but rather that they have a particular handle. Then, as they navigate to each Two Way Web Site, the browser authenticates them in the background using these keypairs against the remote site.

    Single signon goes hand in hand with a standard way to join and unjoin Two Way Web Sites. At any site, if the site creator made it open, a user can press the Join button to become a member of this site:

    [IMG: View Mode – Edit Toolbar –

    When this is pressed, in the background the browser sends the user’s public key to the remote site to be used later for single sign on activities, editing, and site roles.

    The next standardized interface in the smart browser is a standard way to track site changes, which is a panel that appears in the left-hand sidebar when selected:

    [IMG: New Changes Sidebar –

    This panel is created by using an RSS stream from the remote site, and can track recent site edits using the Paper Airplane Editor, or if the remote site is a blog recent updates to a blog or corporate site, for example. When users go to a new site they won’t have to wonder what has changed; the Recent Changes panel makes it easy for them.

    Members of sites can also easily manage roles with the Members sidebar:

    [IMG: Members Sidebar –

    Every page also has a control so that users can tag it with a given topic, such as “important”, “todo”, or “linux”, for example:

    [IMG: Cookie Trail –

    Then, by pressing the Navigator section in the sidebar they can view all of the pages in a web site sorted by Tag, by Name, and more. This Navigator makes it possible for users to quickly jump to new adhoc categories created by other users, sorted into bottom-up categories using the tagging control. The Navigator also includes other powerful ways to view a web site: Recently Edited, which shows recently edited pages; and My Recent Pages, which shows your own recently edited or viewed pages so that you can quickly jump back to them. The end result is that structure is brought to collaborative sites in a bottom-up, organic manner rather than through top-down controls that quickly become out of date.

    The Navigator also exposes a sorting type called By Index, which takes a bit of explaining but which is very powerful. As pages are created and edited, an automatic index is created in the background. When a user views a site in the Navigator By Index, they will see an automatic index similar to the index in the back of a book or the one in Microsoft Help defining all the words, topics, and relations gleaned from the site itself. Most importantly, if your site members have used Smart Templates to create pages that have simple semantic information in them, then we now have higher-level metadata to hook our index on to. The index can be an extremely powerful way for users to look into “the back of the book” in a sense and jump right to the page and section they need to read or edit. Having an index to view a site is one of the payoffs for using Smart Templates when editing and creating your collaborative site.”

  8. Kevin Fox Says:

    +1 for the browser being able to auto detect and negotiate OpenID logins, this would be awesome. I would love to just login to my OP once and then seamlessly go from site to site without having to login all the time.

    There seems to be a movement toward buttons on login pages such as what ClickPass ( is doing… I also see Facebook and Yahoo buttons popping as well and am wondering what the best solution really is… plugin or button or some combination?

  9. Pascal Van Hecke Says:


    already commented this at Ajaxian:

    this can already be achieved without the autodiscovery I think.
    By convention the URL input field has the name openid_url:



    I had the idea of writing a Greasemonkey script to do a one-button or even automatic login but never came around it, maybe someone else will pick this up?

  10. Pascal Van Hecke Says:

    Example should have been:
    < input name=”openid_url” value=”http://” size=”40″ type=”text” >

  11. David Recordon Says:

    I’d love to work with you on making this sort of thing a Gear. I was chatting with Brad last week about it a little as well.

    There is a way in the OpenID Authentication 2.0 spec to discover a Relying Party which probabally could be used to make this work. I think Yahoo! is one of the few sites that actually publishes this discovery information today.

  12. John Says:

    So, for OAuth specifically, Gears should be able to look for a WWW-Authenticate: OAuth header (on a 200 or 401 response) and know that there’s an OAuth login possible. Show a login button to the user (or other UI that’s outside the page), and asynchronously retrieve an XRDS file (proposed extension) from the URL to find out where to to send the user if they _do_ want to log in.

  13. aircraft parts Says:

    The thing to note is that you need some way to have a unique claim on some chunk of namespace, and that cannot be fully distributed.

  14. 墨尔本 Says:

    OpenID rocks!
    Thanks for sharing.

Leave a Reply

Spam is a pain, I am sorry to have to do this to you, but can you answer the question below?

Q: Type in the word 'ajax'