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

Discovery, wherefore art thou Discovery?

The web seems "a buzz" these days with different flavors of "discovery". I've recently been hearing more and more need for Personal Service Discovery. This is coming from both internal and external customers. Two key questions are asked. (1) What is the user's preferred service? (e.g. picture service) and (2) Where is this user's specific service located. The two questions are not mutually exclusive. What I find quite humorous is that the Liberty Alliance has had a "Discovery Service" for quite some time that is capable of answering both those questions (and others). I wish I had Paul's witty way of poking fun... but alas I'm not that talented.

Here are a few recent proposals for "Discovery" services. I'm sure there are many I'm missing...

• XRI Resolution -- a mechanism for describing and querying personal service endpoints (among other things)
• XRD Provisioning Protocol (XPP) -- an XRI based mechanism for Service Providers to attach their service to a user's individual XRDS file hosted by the user's IdP
• "DHCP for Identity" -- "As users, our identity, photos, videos and other forms of personal data should be discoverable by, and shared between our chosen tools or vendors."
• Dynamic Federation -- service provider metadata is discovered via transformation of a user identifier
• OAuth Discovery 1.0 Draft 1 -- This is really "service provider metadata" that is "discoverable".

Interesting to me is the leveraging of XRDS as a containing structure for describing service metadata amongst a number of these proposals. Anyway my hope is that as an industry we leverage all the work that has already been done while looking for ways to make things easier for users and developers.

"Standing on the shoulders of giants" comes to mind.

Tags: Discovery, Liberty Alliance, XRI, XRDS, OAuth

YAIDO - Yet Another IdP Discovery Option

In reading through Eve Maler's slides from this year's XML Summer School, she describes the standard IdP discovery problem for an RP initiated authentication event. One of the standard options is "Client tells RP". Putting this together with the proposal by Laurent Michel on the OpenID lists regarding mobile use of OpenIDs, why not just use the convention of an HTTP header to describe the user's IdP? (I suspect this has been proposed before. Feel free to add a comment stating so). This HTTP header would not have to be sent with every request, because the identity agent could detect when an RP needed it from some additional simple HTML markup.

The RP could then do a XRDS (XRI resolution v2.0 section 6) based discovery on the presented URI from the HTTP header. This would allow the IdP to expose multiple services and protocols via a simple XRDS file. The RP would then just pick the the appropriate protocol and endpoint from the XRDS file and start the RP initiated authentication process.

One danger with this kind of a "push" mechanism is that over an untrusted channel the user is susceptible to MIT attacks. With a smart client and SSL I believe this is better than the cookie mechanism. For OpenID it's probably better to take the seatbelt and sxipper approach of just posting the user's OpenID to the OpenID login form. However, for a protocol like SAML2, identifying the IdP in this kind of a manner should improve the user experience.

Tags: IdP Discovery, XRDS, OpenID SAML