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!

Running for an OpenID Foundation Community Board Seat

I'm excited to announce that I am running for one of the available OpenID Foundation Community Board seats. While I've been a long time advocate of OpenID and open identity solutions in general, this is my first time seeking to serve the identity community is such a role. My self-nomination is now up in the OpenID Foundation Membership area. If you are so inclined, I'd greatly appreciate your "seconds" to make me an official nominee and of course your votes in the upcoming elections. :-) Here is my self-nomination statement:

I am an advocate of open identity solutions for the Internet and I believe that OpenID Connect has the opportunity to be a key identity protocol for the Web. 

I have a long history with OpenID, starting with AOL (my employer) being one of the first major identity providers to support OpenID 1.0. I contributed to the OpenID 2.0 specification along with a number of the OpenID 2.0 extensions. I’m now an active contributor to the OpenID Connect specifications. In addition, I have experience participating in a number of industry standards organizations (OIDF, IETF, OASIS, Kantara Initiative) working on identity related protocols and specifications. 

As a member of the OpenID Foundation Board, I will work to ensure both technical excellence in the specifications and broad adoption of the OpenID protocols. 

Thanks,
George

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

OAuth and Signatures

First, if you have not yet read Eran's most recent post on the subject, OAuth 2.0 (without Signatures) is Bad for the Web, click the link and go read it now!

With that background, I just want to add a couple thoughts. There were two OAuth sessions at the recent IIW East conference in DC. In those sessions we discussed two places where signature are "needed" to enhance the existing OAuth 2.0 draft protocol: signing messages and signing tokens.

• Signing tokens is important for interoperability especially looking forward to a time when tokens issued by multiple Authorization Servers are accepted at a given host.
• Signing messages is important because it provides a mechanism to ensure that the entity making the API call (and presenting an access token) is really the entity that is allowed to make the API call.

With some careful and thoughtful work, I think it should be possible to define a single signing mechanism that can be used for both use cases. If you haven't yet read Nat Sakimura's signature draft, please read it and provide feedback to the list.

+10 to Eran's blog that signatures are a critical component of making OAuth useful now and in the future!

OAuth, IIW, Signing

Congrats Yahoo! OpenID gets another RP

Just a quick shout-out to Yahoo! for releasing in beta OpenID relying party support for Yahoo! Stores. Now new store customers can sign-in and purchase products using an identity they already have. Check out this blog post for more details.

OpenID, AOL, Yahoo!, Relying Party

Webfinger enabled for @aol.com

Being able to discover meta-data about an identity (via the identity's identifier) is an important piece of the Federated Social Web. Evan Prodromou recently wrote...

An important part of identity is addressability – having a machine readable address that computers and people can use to find you, and only you.

As a way to enable "addressability" for AOL users, Webfinger discovery is now available for all email addresses in the aol.com domain. Discoverable information includes the identity's OpenID provider and profile URL.

webfinger, OpenID, AOL