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.

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

User experience and Levels of Assurance

The US government recently (Aug. 10th) held an Open Government Identity Management Solutions Privacy Workshop to discuss Trust Frameworks, Levels of Assurance and Privacy. At this workshop the government introduced a process for the adoption of any identity technology and a process for the adoption of any Trust Framework as managed by a provider (e.g. a Trust Framework Provider [TFP]). Both documents can be downloaded from the above link.

One of the key points brought out at the meeting is that user experience (UX) is critical as users navigate government web sites that potentially require different levels of assurance (LOA) (see OMB M04-04). While the workshop was focused on issues related to LOA 1, the need to solve the multi-LOA problem came up over and over. I believe UX and transitioning between levels of assurance is one of the critical issues to solve.

While specific technologies may be restricted to certain levels of assurance, the user experience should be agnostic to the technology required to implement any specific use case. In this context I'd like to propose the following multi-LOA use case as one possible way to provide a good user experience.

1. User goes to govt web site where they can log in with a LOA1 credential (id from a provider the user already uses)
2. The user is redirected to their consumer LOA1 credential provider and logs in
3. The user is redirected back to the govt web site with an LOA1 credential
4. The user interacts with the web site
5. The user clicks on an option on the web site that directs them to a new site (or a service within the existing site) that requires a LOA2 credential
6. The user arrives at the new site and does not have a LOA2 credential
7. The site informs the user that they need a more secure credential and that they can get one from the following locations
8. The user selects one of the providers and is redirected to that site
9. The LOA2 provider asks the user if they want to use existing LOA1 providers as a factor in the LOA2 credential
   • here I'm thinking that an LOA1 credential could be used in bootstrapping to the LOA2 credential)
10. The user selects their current LOA1 provider (the one they used when logging into the govt site)
11. The user goes through some identity proofing process (note that this could happen off line if necessary).
    • The point is that the user ties their LOA1 identity to the LOA2 provider. This helps with seamless transition between levels
12. The LOA2 requires some second factor authN method and the user chooses an one-time-pin sent to their cell
13. The user enters the one-time-pin and the LOA2 provider issues an LOA2 credential and redirects back to the requesting web site

I'm sure I've left out some critical steps or places where the above does not comply with assurance framework requirements. I would appreciate feedback as to whether the general idea is viable. I would hope that one goal of this effort would be to protect the user (as much as possible) from having to increase the number of identities they manage.

ProtectServe and "Social relationship" authorization

In a post today, Paul highlights a form of authorization that is not yet fully fleshed out in the ProtectServe architecture...

Ultimately, I think User's need to be able to define authorization rules for their identity attributes in terms of both

1) the requesting actor (Consumer in OAuth/ProtectServe, WSC in ID-WSF)
2) an individual with some defined social relationship to themselves

ProtectServe's AM is designed to simplify for User's the definition and management of the first type of authz rules, Liberty's People Service the second.

Of course the mention of ProtectServe is referencing the recent work of Eve Maler and team regarding a proposal to help simplify authorization management for users in the "distributed web".

I believe that it should be possible to extend the Authorization Manager (AM) to leverage social relationships as a mechanism for the user to control access to protected resources. One of the use cases Eve mentions in this post is ...

Making an album’s worth of photos from the latest vacation available to some group of friends and family, but reserving a few in the same album for a more select group

Paul correctly points out that the Liberty Alliance People Service is built for just such a task. As it turns out Portable Contacts provides very similar functionality and is based on OAuth (the same base as ProtectServe). The Portable Contacts (PoCo) specification allows for grouping of contacts in an arbitrary manner using tags so the examples Paul gives are easily mapped. One missing feature of the current PoCo spec is that it doesn't support "membership queries" which means that more information is leaked to the Service Provider than necessary.

Let's look at this use case in more detail. Assuming that Alice has created a resource at her photo service for the vacation photos, and also assuming that Alice has identified the desired set of individuals in her PoCo service with a tag of 'VacationPhotos', all Alice needs to do is associate this tag with the desired resource. So let's assume this is possible within the AM. Finally, let's assume that Bob is one of the individuals with a 'VacationPhotos' tag in Alice's PoCo service.

The basic flow is that Alice sends Bob the link for the protected vacation photos. Bob clicks on the link and is taken to the photo service via his browser. The photo service check with the AM to determine whether the resource is protected or not. Since the resource is protected, the photo service asks Bob to authenticate. Based on Bob's authentication, and his membership in Alice's 'VacationPhotos' group, Bob is given access to the photos.

The interesting twist with this particular use case is that the "Consumer" is really a user (i.e. Bob) who wants to view Alice's vacation photos. So when Bob tries to access the vacation photos resource that Alice shared with him, he accesses the service provider directly. At this point the SP checks with the AM regarding the authorization rules for the resource. However, Bob doesn't have a Consumer "token and secret" with which to sign his request to the SP. Instead he is accessing the SP directly via his user-agent. What Bob can do is authenticate himself to the SP using some authentication means. This is necessary as an identifier is required to determine membership in Alice's 'VacationPhotos' group.

This leads to the question of who should manage the relationship with Alice's PoCo service to do the "membership" check? I can see two options...

1. The AM maintains the authorization requirement (e.g. consumer must be member of Alice's VacationPhotos group) but the SP does the actual membership check. In this model the SP needs to set up a ProtectServe based relationship with Alice's PoCo service. Then when the SP authenticates Bob and has an identifier for him, it can check directly with the PoCo service determining membership based on the "contract" received from AM. This means that the SP must be able to interpret and process the "contract" on behalf of AM.

2. The AM maintains the authorization requirement and also does the membership check with the PoCo service. In this model, the SP will need to forward Bob's identifier to the AM in order for the AM to perform the "membership" check and determine the state of the authorization. Or the SP could redirect Bob to the AM but I would that such a UX would most likely confuse the user. I do think there is a interesting privacy question on whether the SP should be allowed to forward Bob's identifier to the AM without Bob's consent.

I'm not sure which method I like better. Maybe others have better solutions. Thoughts?

Update: Corrected my ProtectServe typos:)

Betrayed...

I've been wondering about the current economic crisis and where its headed; who's behind all the problems and is there an end game? Then I saw this...


and I realized that my good friend is planning the conquering of the world ;-)

Happy Valentine's Day

Red & White for Valentines Day, originally uploaded by GFletch.

For the last two year's I've posted a picture from this bush in our front garden on Valentine's Day. The last two years there has been snow or ice either on Valentine's Day or the day before. However, today is bright and sunny and no snow. So this picture comes from the last week in Jan.

OpenID UX Summit Musings

First, a huge thank you to Facebook for hosting the summit and live streaming the event. I wasn't able to attend in person, and being able to watch the wrapup and presentation of the OP and RP breakout groups made missing the event bearable.

Second, I think that for the OpenID Provider UI there needs to be a way for a RP to influence the UI. Basically, there would be one UI that is generic and totally related to the OP. This would be the default UI shown in the pop-up browser window. However, if the RP has a relationship with the OP, there should be a way for the RP to invoke the pop-up browser window such that some of the UI is customized to the RP. One feature I really like of Facebook Connect is that it gives clear UI context to what the user is doing.

I know for some OP's, its important to only allow customization from RP's that are in a relationship with the OP. This could easily be accomplished by using 2-legged OAuth and associating the UI customizations to the OAuth Consumer Token. The RP would then construct the 2-legged signed URL and load it into the pop-up browser window. The OP would verify the signature and make the necessary customization.

Here's one mock that should look familiar... (my apologies if this is what was discussed and drawn on the whiteboard. I couldn't "read" the whiteboard over the live stream. Final caveat; I'm no UI designer :)

In the default case, the RP's realm string would be displayed along with some generic text and a generic image representing the RP site. The OP image on the right would of course be unique to the OP.

In the case where an RP could provide customizations. The RP realm could be replaced by title text, the description could be specific to the relationship the user is establishing with the RP, and the RP image could be specific to the RP. To make these customizations work from a security perspective, the RP would need to obtain an OAuth Consumer token (and secret) via an out-of-band process (normal OAuth). The RP would then provide the OP with the necessary customizations during this provisioning process. These customization could include, RP realm, UI title text, UI description, and RP image. At UI display time, the OP retrieves the necessary customizations based on the OAuth Consumer token and displays the UI to the user.

With this kind of a model, the UI stays consistent and familiar to users, but also provides RP's with some ability to customize the content to their needs.

OpenID protected sharing at chi.mp

I got a very pleasant surprise today when reading the Chi.mp release notes for release 1.9. The following extracted from the email...

OpenID. Your visitors can authenticate with their OpenID to see privileged content on your site.

I was very intrigued with how they provided this support based on my desire to see OpenID used specifically for this purpose. I have a previous blog entry on the topic here. Basically, Chi.mp uses the concept of "Personas" to segregate content in any way the user chooses. Then contacts are assigned to specific "Personas". As yet, I have not been able to find a way to assign a contact to more than one Persona but that doesn't really affect functionality.

Another very nice feature of their implementation is that if a user goes to my public profile page and logs in with their OpenID, I'm notified that the user has attempted to connect with me. This is a very nice interface as Chi.mp uses SREG support to collect information about the user. Now I can review the "connect" requests and had them as contacts assigning them to a Persona (if I choose). You can try this out with my Chi.mp profile here :)

The only problem I ran into was trying to add a contact via the web page because there was no place for me to enter that contact's OpenID. I'm sure this can be added easily.

Props to Chi.mp for moving beyond "security by obscurity" when it comes to protected sharing of personal information, and also not requiring all my friends to create a Chi.mp account.

Tags: OpenID, Sharing, Chi.mp

Social Networks and Strong(er) Auth

I've been thinking about strong(er) authentication mechanisms recently and the slow uptake by the mass market. I was registering for an online brokerage account recently and was required to enter an email address. I thought through the many email addresses that I use and decided to use the one that has a strong auth mechanism attached.

One of the reasons for this decision is that my ever expanding Facebook world has a lot of information about me that might or might not be relevant to a "password reset attack". I recently found a bunch of childhood friends on Facebook and that has been wonderful. However, it also means that all the information about elementary schools attended, childhood friends, etc is exposed to all my other friends on Facebook. From an information perspective, I don't have any problems, but it does concern me from a security perspective.

Rather than think through what information is available on Facebook, and whether any of that information was used with the "Security Questions" for the email account, I chose to pick an email address that can only be accessed via a 2nd factor authentication mechanism.

So, my question/thought is, "Could social networks be the forcing function that drives consumer adoption of strong(er) auth technologies?"

Tags: Social Networks, Strong Authentication, Facebook

Is it really aggregation vs federation?

In a post this past Sunday Om Malik suggested that user's want aggregation not federation. While I totally agree that user's want aggregation (e.g. having all their relevant information in one place) I don't believe aggregation is in conflict with federation. Rather the two concepts are orthogonal.

I associate aggregation with API access to my data distributed across the web. The exception is closed networks like Facebook that provide all the services within a walled garden environment. So for aggregation to work in the "open web", it must be able to access my data whereever I've chosen to place it. This requires explicit user consent (ala OAuth) for the aggregator to access my personal data at different services.

Now in order for me to grant consent, and for the aggregator to be able to access my personal information, I need to authenticate to the service provider of my data. This authentication step is simplified by using federation (e.g. an OpenID valid at all my different service providers).

So federation really enables a safer, more secure, aggregation capability for users.

Tags: Federation, Aggregation, OAuth, OpenID

OAuth and SREG and MapQuest! Oh My!

This has been a great week for AOL and our efforts to support the "Open Stack". While our progress is not as fast as those more nimble and lightfooted, I still believe the progress is significant.

Yesterday, the AOL Mail Gadget for iGoogle was announced. This gadget uses the OAuth capabilities of the iGoogle container to access OAuth based AOL Mail web service APIs.

Also yesterday, AOL announced it's preview support for the SREG 1.0 extension to OpenID. As in my message to the OpenID general mailing list, there are still a number of user experience issues that need to be resolved around SREG/AX support and I hope that our initial implementation will help consolidate the necessary industry best practices.

Finally, today MapQuest launched a new feature called My Mapquest which allows users to store addresses, driving directions, phone numbers for "Send to cell", and even the ability to estimate fuel costs for a trip based on your personal vehicle. My favorite part of this new capability is that anyone can use it because it supports OpenID. I believe this is the first web site from a major provider, that isn't a blogging product, to support OpenID as a relying party. (Feel free to correct me in the comments).

Tags: OAuth, OpenID, Open Stack, MapQuest, SREG

Fall Kaleidoscope

Fall Kaleidoscope, originally uploaded by GFletch.

The leaves are nearly all gone where I live, but here is a reminder from just a couple weeks ago of the glory of fall.

Important topics at IIW2008b

If I've got my timing right, this entry will post about the same time as the schedule for IIW is being created by those attending. Unfortunately, due to circumstances beyond my controll, I'm not able to attend in person. But that doesn't mean that I'm not actively following the discussions as best I can remotely:)

Here are some key issues that I'm hopeful the community will be able to address during the next two days.

1. User eXperience (UX) for Relying Parties (RP). This is a critical element of making OpenID understandable and valuable to the "masses". There has been quite a bit of work on this recently and I'm excited to see what will develop from the face to face meetings on this topic.
2. XRDS and Discovery. This is really important for the "open stack" and deals with the concept of describing meta-data for resources. As it relates to "personal service discovery", the meta-data is about a user's OpenID and points to the related services of that identifier. This is crucial for connecting services to a user and allowing the kinds of "dynamic discovery" the make the "open stack" work.
3. OpenID TX Extension. This extension being proposed into an OpenID working group is about adding a layer of trust to OpenID transactions. Right now it focuses on tying transactions to contracts between parties but hopefully the working group will extend this to adding a "trust fabric" to OpenID.
4. Email as an OpenID identifer (or as a pointer to an OpenID). This is part of the UX discussion in that many/most? people don't know they have an OpenID but they do know their email address. With Microsoft and Google supporting OpenID (at least in beta) most people have an OpenID. So this discussion is about how to leverage this with users to increase the adoption of OpenID.
5. Email verification. This is slightly related to #4 but also different. In the SREG and AX models, an RP can request an email address but it doesn't know whether the OP has verified that email or not. In some cases, if the RP is talking to an OP that supports email and the returned email address is "managed" by the same company as the OP, then the RP might consider that email address verified. However, Yahoo! and others are looking to support an OpenID extension that would allow an RP to directly verify an email address with the email provider (providing the email provider is also an OpenID Provider; or at least supports this extension).
6. OpenID + OAuth "Extension". This topic is addressing how to allow a Consumer to both authenticate a user and get an OAuth access token and secret in a way that the user only has to authenticate and authorize once. There are a number of significant issues with this effort especially if the extension tackles allowing one SP/OP to verify/validate another SP/OP's tokens. Right now, this effort is focusing on allowing the OP to present not only authentication but also authorization UI so the flow is simplified for the user.
7. OAuth Extensions...
   • Custom Response Data Formats
   • Session Extenstion
   • Problem Reporting
     Especially the new parameter that is linked with the "Custom Response Data Formats" extension that allows the consumer to request the error response in a particular format.
   • Language Extension
8. OAuth support for Mobile/Desktops/Appliances/etc. This topic deals with a simple mechanism for mobile apps or appliances to participate in the OAuth flow even if the device doesn't have browser support and very limited input capabilities.

Tags: iiw2008b, OpenID, OAuth, Open Stack, XRDS

Subscribing to Activity streams

Yesterday Paul asked a good question about subscriptions and identifiers in this push model for activity. If we take an explicit use case regarding how Paul subscribes to George's activity feed, the key is that Paul has to have at least one identifier for George that can be used to discover his activity service.

Leveraging XRDS, OpenID, OAuth and Portable Contacts this should be doable. Here is a graphic and flow.

1. Paul logs into his SocialStream collector (with his OpenID)
   
2. The SocialStream collector discovers Paul's PortableContacts service (via XRDS)
   
3. Paul authorizes his SocialSteam collector to access his's PortableContacts service (via OAuth)
4. The SocialStream collector asks Paul if he wants to subscribe to any of his contact's activity feeds (retrieved from the Portable Contacts service)
   
5. Paul selects his friend George
6. The SocialStream collector uses the identifier(s) for George to discover George's activity service (via XRDS discovery)
   
7. The SocialStream collector subscribes to George's activity service
   
   • If subscribing to a public feed, no other information is needed
   • If subscribing to a protected feed, then OAuth can be used to determine if Paul is allowed access to the feed
   • Membership determination can leverage Portable Contacts tags as described here

Tags: Subscription, Activity, XRDS-Simple, OpenID, OAuth, Portable Contacts