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

Concordia workshop @ Burton Catalyst

Yesterday I gave a presentation at the Concordia workshop (a pre-conference event to the Burton Catalyst conference) on issues consumers face when dealing with the user experience exposed to them by different identity meta-systems. Good summaries of the workshop can be found here and here.

A number of points stood out to me as I listened to the different presentations.

1. Even enterprise deployments have issues with the user experience. Enterprise users want a easy/seamless experience as much as consumers.
2. Companies have figured out to get COTS products based on different protocols to work together, albeit in a rather complex deployment architecture.
3. Scaleability of federation is a real issue. Scaleability issues exist in deployment configurations, administration as well as technically.
4. Solving how to federate between federations is an important task that needs clear best practices.

Overall, it was a very productive workshop. Expect more information to appear on the Concordia wiki shortly.

Tags: Concordia, BurtonCatalyst2007, User Experience, Federation

Sometimes you just have to go fish

Shenandoah River, Virginia

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

The simplicity of symmetry

When it comes to architectures I've always liked the simplicity of symmetric solutions. They are much easier to understand and it is easy to spot inconsistencies in process flow. Well... given the following story... it MUST be that symmetry is much easier for children to understand as well.

The other morning it was raining and my almost 4yr old daughter asked where her Cinderella umbrella was because she couldn't find it. My wife replied that it was in the mud room closet and was likely hanging up in the closet. My daughter went to investigate and came back in a few minutes with the following question. “Mommy can you help me hang it down?”

Principle: Don't underestimate the power of a simple solution:)

Tags: Architecture, Symmetry

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