Passive identity meta-system markup

In talking to a number of people both internally to AOL and externally (most recently at the Burton Catalyst conference) I've become more convinced that in order to enable intelligent identity agents in client devices, service providers (SP) need a standard way to passively describe what identity meta-systems they support. This passive description allows “dumb-mode” browsers to act in the current way, while allowing “advanced clients” to provide more sophisticated user experiences as described in my recent entry on “Clients to the rescue”.

It's important to note that OpenID and Cardspace already provide this passive description albeit in an implicit rather than explicit way. In OpenID the login text field should be named openid-url, and in Cardspace there is the <object type=“application/x-informationCard“ .../> tag which intelligent clients can search for in the DOM. However, “cool” dynamic web design can make finding these implicit descriptions difficult. And AFAIK, there is no best practice/recommendation/suggestion to do this passive description for SAML.

So I'm advocating an explicit markup in the HTML that would allow identity agents the ability to determine the identity meta-system characteristics of the site. This metadata would be used to make the user experience as seamless as possible while still protecting the user-centricity of the different protocols.

I don't think this needs to be complicated. For many web sites the description of protocols supported could be done with an XRDS or SAML metadata document. Reference to this document could then be done through <link> tags.

    <link rel=”metadata” class=”saml” href=”http://path/to/sp/metadata”/>
    <link rel=”metadata” class=”xrds” href=”http://path/to/sp/xrds”/>

The next step might be to use something like a microformat to describe the actual login form.

    <div id=“signin-openid“ class=“login-openid“>
     <form action=“http://ficlets.com/signin/openid.signin“ method=“post“ id=“openid-form“>
        <ul>
            <li>
                <label for=“openid-url“>Your OpenID:</label> <input
                    type=“text“ name=“openid“ id=“openid-url“
                    class=“text-field login-openid-identity“
                    value=““ /><input type=“submit“
                    value=“Login“ class=“submit“ />

                <i>Ex: http://your-username.livejournal.com/,
                   http://your-username.myopenid.com/</i>
            </li>
        </ul>
     </form>
    </div>

The <div> that contains the login form could then be referenced by id (or maybe just use the id of the form itself) via another <link> tag.

    <link rel=”login.form” class=”openid” target=”signin-openid”/>
    <link rel=”login.form” class=”infocard” target=”nameOfDivId”/>

The goal of these examples is to show a possible method for explicit, passive declaration of capabilities. I'm sure there are many ways to optimize and improve the concept... but hopefully this is enough to make the suggestion concrete.

[Credits: Many thanks to Kevin Lawver for microformat suggestions/corrections.]

Tags: Identity Meta-System, Cardspace, OpenID, SAML, User Experience

Clients to the rescue

So last week I blogged about issues the SP faces when trying to reach as many consumers as possible. There are things the SP can do to make this easier for consumers… but maybe “clients” are the “real” solution. Praveen Alavilli started a very interesting internal (to AOL) email thread which is in part summarized below.

For the sake of discussion, let’s assume that SPs have a way to markup up their sites with which identity protocols they support/require. Let’s also assume that the client knows which identities the user has authenticated in the current session and which identities were used with which protocol.

Using the use case from the previous post… My mother-in-law opens the browser to find a new coffee-cake recipe. She finds cooking.example.com which accepts OpenIDs. The client (browser/identity agent/etc) recognizes that the site supports OpenID and pops up a message to my mother-in-law saying “You can log into this sight using your AOL account. Would you like to continue?“. If she clicks the “Continue“ button, she starts the process of signing into the site with OpenID. If she is already authenticated, she should just get a consent page. [Note that the Versign Seatbelt and Sxipper plugins provide this kind of behavior for OpenID already.]

My problem with the current solutions is that they are all protocol specific. The client code has to look for OpenID named form elements, or Cardspace Object tags in order to determine what the site supports. In addition, SAML has no mechanism (as far as I know) to allow the SP to declare that it supports SAML. Sure the client app could try to query for SAML metadata for every web site but that is a lot of overhead where some simple markup would be so much easier. Consolidating this markup via a mirco-format or some simple <link> mechanism to a XRDS file would make this kind of client support that much easier.

Finally, if the client can detect and manage cross identity protocol interactions, then these additional features would make the user experience that much better.

Remember Identity (1)	Auto-Login (2)	Behavior
x		The identity agent would remember the mapping between the identity the user specified and the site. However, the identity agent would not automatically log the user into the site. The identity agent could present pop-up UI to ask the user if they want to log in or just enable a button in the frame of the client that the user can click when they want to log in.
	x	The identity agent would start a login to the site. The agent could just pop up UI with the current set of authenticated identities that match the supported identity protocols of the site. If there are no authenticated identities that match, it should show any identity it knows about that matches (this of course is more like Cardspace).
x	x	This is the SSO option for the client. Now when I browse the web I can be selectively, automatically signed in to the sites I care about. If the previously mapped identity is not already authenticated, the agent would start the authentication process.

(1) “Remember Identity” means that the client will remember the mapping between an identity and the site at which it is used.
(2) “Auto-Login” means that the client will initiate a login sequence without user interaction.

Tags: Identity, OpenID, Cardspace, SAML

Identity at the SP

When it comes to identity, a Service Provider (SP) or Relying Party (RP) has a couple of key issues. One is customer facing (user experience) and another is technical (supporting multiple identity protocols). Of these two, the user experience is more important as it affects the consumer.

Take the following use case. My mother-in-law goes to a cooking web site to search for a new coffee-cake recipe. The cooking site (SP) allows for personalization and saving of favorite recipes, so she is presented with UI to login so she can save the recipe as a favorite (we'll assume that the “create the account” process has already occurred). The cooking site wants to support the widest range of people possible to access their site so they decide to support Cardspace, OpenID, and SAML at the identity protocol layer. Questions? How does the SP represent the UI so that it's not confusing to my mother-in-law? She doesn't understand anything about Cardspace, OpenID or SAML. She does understand that she has an AOL account.

Does this mean SP/RP's should be putting up icons of well known identity providers? That solution is not equalitarian and it doesn't scale. It's great that we have all these cool technologies that tackle different parts of the identity space, but it doesn't really help consumers if it is too confusing to use. I suspect most users know who they have an account with but not many know what protocol is used by their account. For example, I suspect that most Live Journal and AOL users do not know that they have an OpenID.

As for the technology side, the problem at the SP/RP is not that the issues are unsolvable (or even not currently solved). The problem is that all this code has to be written (or incorporated) and glued together to enable these different identity protocols. That is a rather significant barrier to entry. Currently, this tends to drive SPs to pick one of the existing identity protocols. From a business perspective this limits the total number of people that can use the service.

I tend to agree with Johannes, all this talk and work won't mean much if we don't make things simpler for the consumer first and the SP developer second.

Tags: Identity, SAML, OpenID, Cardspace, Service Provider

Users want convergence, not interoperability

Paul Madsen has a great post today regarding the permutations that must be supported to allow for interoperability between the different identity systems. A meta-system framework is great, but implementing it can be a big problem. Interoperability is a great first step but it can not be the end goal.

Stopping at interoperability has some unfortunate consequences for each of the parties in the identity transactions.

Identity Provider: Must implement multiple protocols. This isn't so bad for IdP's because there are relatively few of them and they can get a fair amount of value for their effort because it means more people will want to use their IdP (why Paul selected ProtectNetwork over AOL).

Relying Party: Must implement multiple protocols based on the services they provide. This is much more invasive because there are a lot more RPs than IdPs. Getting lots of RPs to support multiple protocols will be difficult unless it is made extremely easy through available toolkits. Developers (people?) are inherently lazy and spending time writing the equivalent of a TCP/IP stack by hand is not something they want to do. You can also apply these same consequences to web service providers.

Users: Must have multiple identities from different IdPs and know when to use them. This is the one that will kill the internet identity layer if we don't figure out a way toward better convergence. Here is my reasoning (corrections greatly appreciated)...

• Web site will need to implement multiple identity systems in order to take advantage of services available on the web
• Supporting multiple identity systems means that the bootstrap problem must be solved (how to exchange my OpenID authentication for a WS-Trust binary security token)
• Solving the bootstrapping problem is most easily done at the IdPs
• Not all IdPs will support all the necessary bootstrapping mechanisms
• Therefore, users will need to have identities at the "right" IdPs in order to use certain web sites
• Those web sites will have to figure out how to inform the user that their single-sign-on identifier doesn't work at their site.

As we work toward convergence, we need to be mindful of the impacts on users. If we don't make it easy for them, the coolness of the technology doesn't matter.

Tags: Identity, Convergence, Liberty Alliance, OpenID, Cardspace