OpenID Foundation Elections in Progress

The election of two new Community Board members for the OpenID Foundation is now in progress. The current list of candidates includes:

• Axel Nennker
• George Fletcher <-- That's me :)
  
• Greg Keegstra
• David Marceau
• Patrice Vuillard
• Sébastien Brault
• Yosef Vuillard

If you are an OpenID Foundation member, please log into the OpenID Foundation and exercise your right vote! You can easily sign up for an individual membership for only $25 US.

I'm excited about OpenID's future with the release of the OpenID Connect implementor's draft specs. This body of work is important for moving OpenID from just a federated authentication solution to one that can solve many identity authentication and authorization use cases. These use cases are not limited just to non-risk transactions but can cover higher levels of assurance as well.

Adoption is going to be critical in the next two years and that's one of the reasons I'm running for one of the available board seats. Adoption is more than just OpenID Connect implementations; adoption includes moving beyond low-risk transactions into higher value use cases and really providing convenience and security to consumers. Whether this is a goal that can be accomplished in the next 2 years remains to be seen, but it's a goal worth shooting for.

Of course I'd appreciate your vote!

Facebook Registration Tool

The new Facebook registration service has created quite the "buzz". I have to commend Facebook on doing a great job of making it really simple for sites to manage registrations (just as they did with identity federation). I like the user experience; both for the user and for the integrating site.

However, for relying parties supporting 3rd party identity providers I do have some concerns regarding leveraging the Facebook registration UI for all users.

1. What happens if the user chooses to clear the form and enters new data? If the site requests password data as part of registration for these users using the "

   <code>{"name":"password",   "view":"not_prefilled"}</code>

   " option, when the user comes back to the site, where do they enter their password? How does the site instruct the user that when they come back to the site, they should use the site specific login form, not the Facebook login form?
   
2. For users who choose not to register for Facebook, but do want to access the site, where are their login credentials stored? If the site doesn't request password as part of the registration process, is Facebook asking for authentication credentials and storing them (along with which sites the user has logged into)? From working through the documentation, I believe Facebook handles all authentication (even if not storing the registration data) and provides sites with a UID (unique identifier). Effectively, Facebook is a federated identity provider for all users.
3. Supporting other federated identity providers becomes confusing. The relying party will have to support two registration forms; one for Facebook users and one for other identity providers. For example, I don't see a way for the relying party to use the Facebook registration UI for a user logging in with their Twitter credentials.
   

In the end, for sites that only support Facebook as their external identity provider, this is a great tool. For sites that support identity providers other than Facebook, the benefit is only recognized for Facebook account holders.

Facebook, Registration, Authentication

Privacy across Social Network aggregation

Social Network aggregation is a great personal service that allows me to see updates from all my social networks in one place. There are a number of services that provide this functionality: chi.mp and AOL Lifestream to name two. As long as I'm the only one viewing these aggregations, there are no privacy concerns.

However, the problem arises when content is shared (cross-posted) between social networks and then re-aggregated by the social aggregation service. Take the following scenario as one possible use case.

Alice participates in 3 social networks, statii (a real time micro blogging site), snaps (a photo sharing site), and frendz (a social network of my personal friends). In addition, Alice uses a social network aggregation site called socialview to give her a global view of all her social network activity. All of these social networks allow Alice to establish connections with her friends within those networks. Each of the social networks has it's own privacy mechanisms that allows Alice to share information publicly, or just with a certain set of friends. Even socialview allows Alice to establish relationships with other socialview users and share their aggregated social network activity streams. In addition, socialview allows Alice to cross-post status updates to both statii and frendz.

In this example, all of Alice's micro blog updates to statii are public. In addition, most of the photos she uploads to snaps are also public. On frendz, Alice is a little more careful and only shares information with friends. She does allow friends-of-friends to view her updates and any comments her friends leave.

Now, let's say that Alice uses socialview to post a status update to both statii and frendz. Let's also assume that Alice has decided that all her updates originating from socialview should be public. When Alice's status update appears in frendz, her friend Bob thinks it's relevant and leaves a comment in frendz on her status. Then Socialview, during it's normal aggregation cycle, sees the new comment from Bob and adds it to Alice's aggregated view.



This is where it finally gets interesting. Should Bob's comment be made public (given that Alice's privacy settings at socialview state that all her posts are public, and Bob is commenting on a "public" post?) or should his comment be visible only to Alice (because Bob didn't know he was commenting on a public post).

What I think is missing is a "visibility" scope attribute that needs to be attached to the activity as it navigates across social networks. In the above contrived example, this would allow frendz to make it clear to Bob that Alice's status is really public. It would also allow socialview to honor Bob's privacy settings that he only shares comments with friends when aggregating his comment back into Alice's aggregated view.

Activity Streams, Privacy, Social Networks, Aggregation

IIW #9 : Making it all work

If you haven't seen the announcements for the Internet Identity Workshop (IIW) floating around the identity listservs, it's happening Nov. 3-5 at the Computer History Museum. A lot has happened since the last IIW in May and I'm excited about the progress that has been made in the intervening months.

Thinking back to past IIWs it's great to see the progression of topics at IIW from geeky syntax and protocols to solutions and solving the problems from a user's perspective. With the recent developments around "webfinger" and XRD, some of the "glue" pieces are coming together.

I believe the next core issue to tackle in "Making it all work" is the user experience. To date we've been solving the problems mostly from a functionality perspective. However, just being "functional" isn't good enough for the average consumer. We need to make it easy and coherent (not a trivial task). By easy, I don't just mean "there aren't too many clicks" but rather a user experience that proactively helps the user with the tasks they need to perform. There are lots of nuances in the identity space and the average user doesn't grok them, so the technology has to help the user make the "right" decision.

I'm expecting discussions like this to be a key part of IIW #9.

Internet Identity Workshop
Registration

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