Ben Laurie blathering

Is IdP Discovery The Next Big Thing?

I’ve been thinking. Even though us fans of user-centric identity like to think of it all being in the hands of individual users, it seems to me that in practice many users will delegate management of their identity data to a third party. They’ll do this for a variety of reasons, the main one being convenience, though the need to be always on may be a driver in the end, too.

So this leads to an interesting question: when I first arrive at a site, how does it know who I’ve chosen to be my IdP? When I turn up at Unicorns-R-Us, how do they know that they should go to Amazon to verify that I’m logged in and that I’m the same guy as shopped there last time?

This question is, of course, the question of IdP discovery, and although we’re not worrying about it much right now (at least in the user-centric world – I know Liberty has worried about it forever), I predict that we’ll be worrying about it a lot, Real Soon Now.

But why is it an issue? There seem to be all sorts of obvious options…

1. The OpenID approach: you (the user) give a URL to Unicorns-R-Us, and at that URL can be found further information about your identity. Clunky and weird for the average user.

2. Cookies. The first time you visit Unicorns-R-Us some miracle occurs that informs them I am an Amazon user and they set a cookie so they’ll always know in future. Two problems here, the first being that we still have that first encounter to solve and the second being that this works fine until you switch to my laptop and then you’re screwed.

3. Client-side component. This works well, and solves the first encounter problem, but still suffers from the issue of me switching to a machine without the component installed – or with it installed, but not yet initialised. Will I know how to initialise it, since that’s probably something I’d only do once a year or so? It can’t be too easy, or that’s clearly a security risk.

I’m starting to run out of ideas here, and so far none of them have worked really well. I suspect that in the end we’ll end up with the OpenID approach (“ask the user”) but with something more friendly than a URL and with a flow that often requires no effort on the part of the user. But its an interesting question that I don’t have a good answer to – and a good answer is key to a user-centric identity world.

I predict that figuring out standards and a good user experience around this problem will be one of the major pieces of the user-centric identity puzzle over the next couple of years.


  1. There’s also the Shibboleth approach. It’s similar to OpenID except that all you reveal to an RP is the hostname of your IdP. You don’t also reveal a username. This makes it more difficult for RPs to correlate information and track you.

    I’m not saying it’s the greatest approach, just that it’s another one.

    Comment by Eric Norman — 16 Dec 2007 @ 20:00

  2. With OpenID 2.0 you can do the same thing as Eric said for Shibboleth, just provide the URL of your provider (or click a giant “AOL” button). Still not the best experience if there are lots of different providers.

    I think browsers really need to get involved, but like you said suffer from the “not at my machine” problem.

    Comment by David Recordon — 17 Dec 2007 @ 1:44

  3. It’s puzzling why figuring out someone’s identity provider should be any harder than figuring out their email provider. Identifying yourself should be no harder than typing in your email address. I predict that either OpenID URL’s will evolve to be as easy and familiar as email addresses, or someone will figure out how to map email addresses to OpenID’s and we will just use (possibly throwaway) email addresses.

    Regarding setting your current identity, it seems like your browser should display who you are logged in as (as many web pages currently do) and you should be able to change this by clicking on it?

    Comment by Brian Slesinsky — 17 Dec 2007 @ 5:45

  4. A people DNS would be the answer. Essentially, the problem you’re trying to solve is the same problem encountered when people wanted to make the Internet friendly. Folks can’t remember an IP, but then can remember

    The biggest problem I see, with even the current DNS architecture, is it’s a single point of failure – the root dns servers. A distributed approach, similar to that of Gnuetella (pass the football), would ensure fail-safedness and eliminate a single point of failure.

    If you’re going to solve it for people lookups, might as well solve it for overall xri:// end-point look ups though. (btw, fwiw, fuck Knol)

    Comment by johnny fry — 17 Dec 2007 @ 5:50

  5. My browser has a third-party cookie management plug-in, that allows me to control that aspect of my interaction with sites. It’s pretty simple. I dare say the same sort of mechanism could be used in respect of identifying oneself to a website i.e. according to my rules. Not with cookies – just the type of mechanism.

    Comment by robin — 17 Dec 2007 @ 7:38

  6. Options
    4 – Why not both. A secure(?) client-side component that is stored at your “preferred” IDP (or whomever). So when you get your new machine you initiate a transfer (WEB Service request?) form your preferred IDP to your secure client-side component?

    Comment by James S Willeke — 17 Dec 2007 @ 13:52

  7. Brian Slesinsky touched on it up there.

    A much better identifier for people to use is an “email address”. The structure of an email address leads to uniquely identifying an individual (assuming no sharing of email address, but then, if its being shared, ostensibly you can treat the identities the same way anyway), while still supporting inherent delegating of the identification process.

    The biggest downside I see to it is that it becomes hard (impossible?) to move your delegation, unless you’re using your own domain part, which raises the bar almost to the same level as using a URL (ie, the user has to go get a domain registration and make it useable somewhere).

    And the reason that I put the “email address” in quotes up there is because I think email makes an absolutely terrible infrastructure to support this (I doubt I’ll get much argument on this), but there is an infrastructure that uses the same identifier format that would be great for supporting this…XMPP/Jabber.


    Comment by Jeff McAdams — 17 Dec 2007 @ 15:25

  8. Obvious solution: ID in the browser. If you hit a site that needs your ID, and you are not logged in to your ID provider, browser tells you you need to login to your ID provider, and the browser, not the web site, prompts you select an ID provider from a list of ID providers known to the browser, or enter a new one. You login. Thereafter, on each website, browser can log you in. If your ID provider is, then you get logged in at as

    Comment by James A. Donald — 19 Dec 2007 @ 3:43

  9. New root domain for IdPs? Then the user can specify the IdP using just “ids-r-us” which will be converted to “http://www.ids-r-us.idp”. Also has more control over who is admitted to be an IdP.

    The RPs can also sell the screen real estate to IdPs of their choice and make them into huge buttons for easier access.

    Comment by Zeev Lieber — 24 Dec 2007 @ 17:17

RSS feed for comments on this post.

Sorry, the comment form is closed at this time.

Powered by WordPress