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

Identity as an Attribute

A while back I posted a couple of entries on the concept of an identity token. The idea being that a client/requester/relying party could request an identity token from the Identity Provider (IdP) when authenticating the user and then use it when accessing protected resources to represent who is making the request. This becomes very important in person-to-person sharing use cases.

One such use case that recently appeared on the OpenID specs listserv is the need to access protected <Link> elements in a user's XRD/JRD. For example, I want to allow family members to be able to discover my family photo albums but keep those links restricted from public access. The basic need is that the requesting client/service needs to "prove" to my XRD provider that they are a "family member". A very easy way to do this is for the requesting client/service to obtain an "identity claim" from the family member's identity provider and pass that along to the XRD provider. This of course would most like be in the form of some structured OAuth token.

Thinking about it this way, the user's identity is really just a 3rd party asserted attribute. 3rd party because the client is the 1st party in this scenario and will be the entity presenting the attribute to other services.

This concept of 3rd party asserted attributes is not new. There have been many discussions and posts about how to obtain an "over 18" attribute from the DMV and store it in the IdP. What makes representing the user's identity different in this case is that often, the user's identity is the key that gets them access to their resources. Thus, this identity attribute has to be recognized as just a verified identifier (i.e. like relying parties want a verified email address) and not some sort of authorization token.

My one concern has to do with whether 3rd party asserted attributes should just be bearer tokens? or whether they need some holder-of-key mechanism to ensure that only the client that is issued the 3rd party asserted attribute can present it in future requests.

Previous posts:

Protecting "discovery" information?
Open Identity Token
Open Identity Token and Personal Discovery Service (Praveen Alavilli)
Continuing the discussion...

Identity, Token, Sharing, Attribute, OAuth, XRD

OpenID Summit Day 2

Day 2 of the OpenID Summit was an eclectic mix of updates on current efforts, new proposals, and Issues. The day's agenda and related presentations can be found on the OpenID Wiki.

I found the Browser-Assisted Login presentation by Dan Mills (Mozilla Foundation) especially interesting. I believe that some level of identity agent (whether that be the browser or some other process running on the user's device) to be the best way to solve the current usability problems that users face. Their current approach leverages host-meta which defines a link to a JSON based site meta-data document (JSON instead of XML just because that's much easier for the browser to parse). Currently they don't support unsolicited assertions in their OpenID implementation. This is great work, and I believe that with a mechanism to sign the site specific meta-data document and the ability to support unsolicited assertions (protects against phising), this will be a great solution for users.

Mike Jones (Microsoft) also presented on identity agents and Microsoft's work in integrating OpenID and Cardspace. Mike outlined 3 key requirements for allowing identity agents to integrate well with web sites.

1. Web sites need to be able to publish it's requirements to the identity agent
2. Web sites need to be able to detect the presence of the identity agent
3. Web sites need to be able to invoke the identity agent

Initially I didn't think that requirements 2 and 3 were necessary but I can see some use cases where this might be required. I believe the preferred design should be totally passive markup by the web site with the identity agent invoking the user's desired/expected behaviors.

Brian Ellen (JanRain) [Challenges faced with RPX], Allen Tom (Yahoo!) [What an RP wants from an OP], and Chuck Mortimore (Salesforce) [Multi-tenancy at Salesforce.com] all talked about issues relating to being a web site that accepts OpenIDs. These talks expounded on the issues list from Day 1 and provided additional clarification.

John Panzer (Google) [Webfinger], Breno de Medeiros (Google) [Artifact binding], and Nat S (NRI) [Contract Exchange] gave explanation and status of their current work in these areas. Key take aways for me were ....

• Webfinger can be used for generic discovery of any identifier
• Artifact binding will allow OpenID to support any token type not just the current OpenID assertions. Artifact binding is also key for OpenID to support LoA2 based web sites.
• Contract Exchange provides mechanism to get contracts digitally signed by both parties.

Pamela Dingle (Ping Identity) spoke on the economic deployment of OpenID in the enterprise and it's associated services. In these environments its critical to be able to mix protocols and from a user's perspective seamlessly navigate between OpenID and SAML (for example).

Mary Rundle (Microsoft) spoke on the necessity of OpenID to engage the public policy makers because public policy can have a significant effect on technology. She encouraged the OpenID Foundation to establish a process for engaging in the public policy discussion.

Joseph Smarr (Google) gave an interesting proposal for how to make OpenID and OAuth easier for developers. This sparked great discussion and debate including ad hoc sessions. The goal of this proposal is to make it as easy as possible for developers to integrate OpenID/OAuth into their web sites.

Sarah Faulkner (Microsoft) lead a discussion on whether email address should be used as an identifier for the user. One clarification from the discussion is that email addresses are good identifiers for what the user knows (i.e. what the user can type into a web site). However, they are bad database identifiers. So OpenID should support using an email address as a way to bootstrap into a more permanent/consistent identifier for the user (this is pretty much what webfinger provides).

I also lead a quick discussion around the issues with OpenID and user logout. We didn't reach any conclusions. I see three possible "solutions" to this issue, listed in my order of preference:)

1. Train the user to log out of their OS session. If the user has checked the "Remember me" or "Keep me signed in" option then logout is useless anyway.
2. Instrument the browser to keep track of where the user goes and the browser can log the user out (either by clearing cookies or calling an API at the web site). This makes it easy for the user to choose when they want to just log out of a site (click the web site's logout link) vs log out of all sites (click a button on the browser).
3. Enhance the OpenID protocol to support a logout mechanism with the option for the user to either just log out of a single site or log out of all web sites.

The result of all the presentations and discussion is the formation of 5 new OpenID Foundation working groups. The following is taken directly from the OpenID Wiki page.

•  Discovery
• Chair: Allen Tom / Mike Jones
• Scope: URL, acct:, active client (discovery about OP and RP)
•  Attribute Schema
• Chair: Joseph Smarr
• Scope: How to ask for and get rich, consistent common extensible data attributes (attribute discovery)
•  UX Guidelines
• Chair: Chris Messina
• Scope: Guidelines for how OPs and RPs provide a consistent user experience
•  Policy & Certification
• Chair: Eric Sachs
• Scope: Define scope
•  Core Protocol
• Chair: Dick Hardt
• Scope: active client, message verification, AX/CX, OAuth, non-browser

Most of the presentations from the OpenID Summit can be found here.

OpenID Issues List

Yesterday at the OpenID Summit a number of companies presented on the issues they have experienced with evaluating and/or deploying OpenID. Here is my summarized list in no particular order.

• Value Proposition is not always clear
• Authentication isn't enough, need identity attributes (AuthN + AuthZ)
  
• The more marketable attributes the better
• Need a standard "profile" object with "trusted/verified" attributes
• Data sharing when the user is not present
• No clear way to push back activity into the user's activity stream
  
• Usability
• User's don't know their OpenID, use email addresses instead
• Depending on the site requirements, the user may still have a registration to go through (e.g. site must collect age/gender/zip)
• First time experience is different at each site
• Customer care is difficult because the user likely doesn't know their OpenID (OpenID 2.0 IDs are often machine generated)
  
• User confusion over the logout experience
• Local logout just from the site
• Global logout from all sites
  
• User confusion over the login experience
  
• Every pop-up UI is different
• Should the user "link" their OpenID to their existing account at the RP?
• Should the user create a new account at the RP based on their OpenID?
• OpenID and OAuth both have "login events" but they mean different things
  
• Better non-browser support
• Devices (e.g. netflix, xbox, zune, etc)
• Mobile devices (lose 70% of population in Japan if OpenID doesn't support mobile)
• Rich client applications
  
• Trust / Certification
• How does the RP know it can trust the OP to security authenticate the user?
• How does the OP know it can trust the RP with the identity attributes shared?
• Security and Levels of Assurance
• Need an independent security review by an expert
• Cannot meet higher levels of assurance than LoA1 without protocol changes
• Need an attribute profile to meet LoA2 requirements
  
• E-Commerce
• Who is liable/responsible if the user can't log in to their paid service because their OP is down?
• How does OpenID make the check-out process better? more streamlined?
• More e-commerce related attributes (e.g. billing/shipping address)
• Portable reputation
• User's want privacy to control what attributes/info is shared with the merchants
  
• Interoperability
• Need better / automated testing tools for core libraries and services
• OPs have to tweak their implementation for specific RPs
• RPs have to tweak their implementation for specific OPs
• URL length can cause problems for some implementations
• No way to move a 1.1 HTTP OpenID to a secure HTTPS one
• Inconsistent implementations of Attribute Exchange
  
• Ease of Adoption
• Not easy to set up based on existing libraries
• No simple JS library that enables OpenID without server development
• OpenID + OAuth hybrid has too many secrets
• Privacy
• Must protect the user's rights
  
• Needs to be under the user's control
• Activities need to be un-correlatable (if that's what the user wishes)
• Can't share email if maintaining the no correlation privacy constraint (Contact service?)
  
• User must have access to their settings and activities at each site
  

I'm sure I've missed some so please feel free to add to the list.

Email Verification and Identity Federation

Most sites today, when registering a new user, invoke some form of email verification. They ask the user for their email address, send the user an email, and ask the user to click a link in the received email. This ensures the web site has a "valid" email address for the user.  While not ideal, this works today as the user is "registering" directly with the web site.

Now enter identity federation and the situation changes. If I can log into the web site using an identity I already have, what does this mean for the email verification process? Does the web site need to still send me through that out-of-band email verification process? Or can something better be done to improve the user experience?

The answer to that question is yes, but it takes the web site changing their perspective on email verification. Instead of verifying the email address, the web site needs to verify the user (via identity federation) and use the identity protocol's attribute mechanisms to retrieve a verified email address. The difference is subtle but important.

Let use the following scenario as an example. Using webfinger as a way to bootstrap from an email address to an identity provider...

1. Alice goes to a new web site (http://relyingparty.example.com)
2. Alice enters her email address (alice@example.net)
3. The web site (relyingparty.example.com) uses webfinger to discover Alice's OpenID Provider
4. The web site starts the OpenID authentication flow with Alice's OpenID Provider requesting an email address as a required element via Attribute Exchange (AX)
   
5. Alice authenticates to her OpenID Provider and consents to sending her email address (alice.smith@example.com) to the web site. Note that Alice's OpenID Provider always returns a verified email address via AX.
   
6. The web site receives the successful authentication response and retrieves Alice's email address

Note that the verified email address returned from the identity provider is different from the one Alice entered at the site. This is the subtle difference that web sites need to consider. It doesn't matter which email address the user uses when interacting with the web site. What matters is that the web site has a mechanism to associate a verified email address with authenticated users.

As identity federation grows, and web sites adopt this approach, the user experience will improve as there will be no out-of-band messaging required to start engaging with a web site.

OpenID 2.0 Provider support live @ AOL

I'm excited to announce that the AOL Identity Services team has fully deployed OpenID 2.0 Provider support. Directed identity flows are now enabled so just entering 'aol.com' into an OpenID field will start the authentication flow. In addition to directed identity, this release also supports "check immediate" flows, SREG, AX, UI (popup browser), PAPE (as required by the ICAM OpenID 2.0 Profile) and of course the ICAM OpenID 2.0 Profile itself.

We have also improved the UI making it much cleaner and easier to follow. One feature of this new UI is a page that allows the user to choose, when first visiting a new site, whether to use their public OpenID (http://openid.aol.com/<username>) or an opaque one. Of course, this choice isn't necessary if the user provides the relying party their full OpenID or the relying party specifically requests an opaque identifier (via PAPE policy). I'd really appreciate feedback on whether this "privacy" feature is helpful to users or just adds more confusion.

In addition to the existing SREG support, the same attributes will be supported via Attribute exchange. There is equivalent support for the http://axschema.org URIs but only partial support for the Information Card URIs as there weren't direct equivalents for all of the attributes. Here is what is currently supported.

http://axschema.org/namePerson/friendly
http://axschema.org/contact/email
http://axschema.org/birthDate
http://axschema.org/person/gender
http://axschema.org/contact/postalCode/home
http://axschema.org/contact/country/home
http://axschema.org/pref/language
http://axschema.org/pref/timezone

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/dateofbirth
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/gender
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/postalcode
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/country

Suggestions or requests for specific attributes are always welcome. One point of clarification regarding email addresses and verification. The current implementation defaults the email address to the user's AOL provided email address but does allow the user to change the value returned to the relying party.

While there is still a lot to do, it feels really good to finally reach this milestone.