Identity in Practice

Running for an OpenID Foundation Community Board Seat

2012-01-20T23:39:00.000-05:00

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

2010-12-17T12:00:00.000-05:00

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.

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?
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.
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

2010-09-23T21:47:00.000-04:00

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

2010-09-16T14:14:00.001-04:00

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

2010-08-23T09:30:00.001-04:00

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

2010-08-06T13:59:00.001-04:00

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

2010-05-19T11:15:00.001-04:00

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

2010-04-09T08:55:00.001-04:00

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.

Web sites need to be able to publish it's requirements to the identity agent
Web sites need to be able to detect the presence of the identity agent
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:)

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.
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).
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

2010-04-06T10:18:00.001-04:00

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

2010-03-19T13:07:00.001-04:00

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...

Alice goes to a new web site (http://relyingparty.example.com)
Alice enters her email address (alice@example.net)
The web site (relyingparty.example.com) uses webfinger to discover Alice's OpenID Provider
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)
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.
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

2010-03-12T17:34:00.000-05:00

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

2009-08-31T12:00:00.004-04:00

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

2009-08-14T12:30:00.004-04:00

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.

User goes to govt web site where they can log in with a LOA1 credential (id from a provider the user already uses)
The user is redirected to their consumer LOA1 credential provider and logs in
The user is redirected back to the govt web site with an LOA1 credential
The user interacts with the web site
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
The user arrives at the new site and does not have a LOA2 credential
The site informs the user that they need a more secure credential and that they can get one from the following locations
The user selects one of the providers and is redirected to that site
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)
The user selects their current LOA1 provider (the one they used when logging into the govt site)
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
The LOA2 requires some second factor authN method and the user chooses an one-time-pin sent to their cell
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

2009-04-03T09:12:00.005-04:00

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...

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.
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...

2009-03-12T11:53:00.004-04:00

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

2009-02-14T13:53:00.001-05:00

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

2009-02-13T11:02:00.004-05:00

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

2009-01-23T13:18:00.005-05:00

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

2008-12-08T12:25:00.003-05:00

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?

2008-12-03T09:57:00.001-05:00

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!

2008-11-20T13:58:00.003-05:00

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

2008-11-20T13:57:00.001-05:00

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

2008-11-11T11:16:00.003-05:00

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.

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.
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.
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.
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.
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).
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.
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
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

2008-10-03T16:39:00.005-04:00

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.

Paul logs into his SocialStream collector (with his OpenID)
The SocialStream collector discovers Paul's PortableContacts service (via XRDS)
Paul authorizes his SocialSteam collector to access his's PortableContacts service (via OAuth)
The SocialStream collector asks Paul if he wants to subscribe to any of his contact's activity feeds (retrieved from the Portable Contacts service)
Paul selects his friend George
The SocialStream collector uses the identifier(s) for George to discover George's activity service (via XRDS discovery)
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

MyActivity vs MySocialStream

2008-10-02T12:12:00.003-04:00

The recent production announcement by Gnip, Inc got me thinking about activity and the push vs poll model for tracking activity. As I see it, there are two kinds of activity that I want to track: (1) my activity and (2) my "friends" activity. Hence the terms MyActivity and MySocialStream.

In a truly open and distributed web environment, I should be able to separate these functions into any providers I desire. Right now, most social networks combine both my activity and my friends activity into a single stream and service. Thus if this service wants to aggregate activity, it has to poll each of those external services for updates and then merge them into the activity stream.

An interesting aspect of Gnip, Inc's offering is that it will push updates, even filtered updated, to an endpoint. Push seems like a better model, especially if it can be "throttled" in some way (meaning, the service pushing the updates can be configured to combine multiple updates in a 5 min period into a single push event).

If we model my activity separately from my friends activity, then it should be possible to define an API for an activity service. This activity service would accept my activity events from across the web. This activity service would be discoverable via my XRDS document so that any site I visit can discovery my activity service and report activity to it. If my friends want to track my activity, they can subscribe to my activity service. This subscription mechanism could include the use of OAuth for subscription to restricted activities. Managing who is allowed to see which events could leverage Portable Contacts for group membership. This way, whenever I'm involved in some activity across the web, that activity will get reported to my activity service which in turn will push out the event to all friends that have subscribed.

As for all my friends and their activity that I would like to see, I just need to have MySocialStream service subscribe to their activity services. This data aggregation could be displayed in any venue; opensocial gadget, web page, iPhone app, etc.

All that's needed is the specifications for the APIs and the ability to list them in my XRDS. Well, a little more than that, but it's definitely more doable today than ever before.

Tags: Gnip, Inc, Activity, Portable Contacts, OAuth, Push, Poll

Protected Sharing on the Open Web

2008-09-11T15:28:00.003-04:00

One feature I have wished for on the web for quite some time is the ability to securely share family photos with my extended family and close friends. Currently, all photo sharing sites (that I’ve been able to find) require all parties to have an account at that photo sharing site in order to securely share the photos. Note that I don’t want the current solution of “security-by-obsecurity” where a big random URL is created and emailed to the group.

I think we can build a much better sharing environment using existing and emerging specifications like OpenID, OAuth, Portable Contacts and XRDS-Simple. Here is a use case and one way it could work.

I have an account at flickr and I create an album (flickr set) that I want to share with my extended family. Previously, I’ve associated my flickr account with my plaxo account (using OAuth) to enable flickr to access my contacts (via “Portable Contacts”). Flickr needs to use XRDS-Simple to find my “portable contacts” service and OAuth discovery to set up the connection between the two services.

I tell flickr I want the new album (“Family photos”) protected and shared only with those people in my contacts lists that are labeled as “Family”.
Flickr marks the album as “protected” and remembers that those allowed to view the album are anyone who is a member of my “Family” tag at my “Portable Contacts” service.
I send out an email to my family members sending them the direct URL to the protected resource (note that flickr could also do this for me since it has a connection to my portable contacts service).
A family member receives the email and clicks the URL to the protected album at flickr
Flickr recognizes this is a protected resource and returns both the OAuth information for how to access the protected resource as well as HTML telling the user that the resource is protected and the user needs to authenticate
The family member logs into flickr using their OpenID (not currently supported)
Flickr takes the OpenID and asks my “Portable Contacts” service whether this OpenID has a tag of “Family” (basically a membership query; see previous post)
If the user's OpenID is a contact with a tag of “Family” then they get access to the album, otherwise they are denied

What’s currently missing to make this a reality are...

Relying parties accepting OpenIDs
Users knowing they have an OpenID and using them
Portable Contacts adding “membership” type APIs
Portable Contacts supporting an explicit 'urls' type of 'openid'

In finalizing this blog post, I read David Recordon's summary of the Portable Contacts hackathon held last night. The following quote shows this is very near reality, Yeah!

Brian Ellin of JanRain has successfully combined OpenID, XRDS-Simple, OAuth, and the Portable Contacts API to start showing how each of these building blocks should come together. Upon visiting his demo site he logs in using his OpenID. From there, the site discovers that Plaxo hosts his address book and requests access to it via OAuth. Finishing the flow, his demo site uses the Portable Contacts API to access information about his contacts directly from Plaxo. End to end, login with an OpenID and finish by giving the site access to your address book without having to fork over your password.

Tags: OpenID, OAuth, XRDS-Simple, Portable Contacts, Sharing, Access Control

Tagging for contacts

2008-09-11T10:33:00.004-04:00

Has any one else had this problem? You need to IM someone and you can't remember which group you filed their name under. I realize that if I just kept an alphabetized list, and I remembered their name this wouldn't be a problem. However, sometimes it not that I’m looking for a particular person, but someone on a particular team.

Basically, what I’ve found is that I want to attach “tags” to my contacts that describe attributes about that person. Then I can find people by my own “folksonomy” whenever I need to. This would allow me to “query” my contacts (or IM client) by a “tag”. So I could say, “Show me all the architects at AOL that are currently online?”. It also allows me to do queries like “Does Bob have an ‘Extended Family’ tag?”. This is really a membership query and can be thought of as “Is Bob a member of the group ‘Extended Family’?”

Combining tags with contact data allows for all sorts of interesting capabilities. For instance, my Adium IM client could query my Portable Contacts service for all contacts with at least one IM identifier present and return all IM identifiers and tags. With this information Adium could auto-create groups, show me a “tag-cloud” of who’s online, etc. Another use would be true access-controlled sharing of protected resources. I’ll have another post on that soon.

With the emerging Portable Contacts specification, I think there is a great opportunity to enable this kind of capability in an open standard. The portable contacts spec already supports both tagging and filtering. What is a little unclear from a quick read of the specification is whether filters can be combined. However it should be easy with this specification to support the queries listed above. For a membership style query, the following should suffice...

/@me/@all?filterBy=urls&filterOp=equals&filterValue=http://bob.example.com&filterBy=tags&filterOp=equals&filterValue=ExtendedFamily

Tags: Portable Contacts, Tagging, Access Control, Instant Message

Continuing the discussion...

2008-09-03T12:59:00.003-04:00

This post is in response to the thoughts Praveen posted on his blog regarding Open Identity Tokens.

These thoughts around an Open Identity Token are more focused on enabling sharing access-controlled resources than trying to duplicate existing OAuth functionality. One use case that OAuth doesn't currently solve is my desire to access a protected resource where I DON'T have an account at the service provider managing the protected resource. An Open Identity Token allows the service provider to allow access to the protected resource (not mine, but my friends) without my having to have an account at the service provider.

My vision was that an Open Identity Token could be passed as part of a standard OAuth invocation allowing multiple verifiable identities to be specified in the API call. The OAuth mechanisms bind the Consumer, the Service Provider and the Identity into a single token. This doesn't leave room for additional identities.

Some specific comments to the points raised follow...

"Bob’s discovery service" might not know Alice with the same Id (OpenID) - Bob might have only entered Alice's alternate email address that doesn't even resolve to the same OpenID that Alive used currently to sign in to HikingTrails.com

I think this problem is out of scope for identity tokens. This is really an identity "association" problem and a problem space that I believe portable contacts could grow into solving. Just like with Adium (IM client for the mac) I can merge multiple IM identifiers into a single identity, I should be able to do the same with portable contacts. I would love to see portable contacts grow into allowing membership based APIs so that a service provider could contact my portable contacts server and say... "Is this identity token a member of George's 'hiking buddies'?".

HikingTrails.com might need to go back to Alice's OpenID provider for each (notification) service that it wants to invoke on behalf of the user. Bob might use notification service A, David might use notification service B, and so on... - where A, B, etc.. totally different services.

I don't think that hikingtrails.example.com would need to go back to Alice's OpenID provider. However, it would need to go to each of her friends discovery "service" to find their notification service. One of the goals is to allow the dynamic distribution enabled by the "web". To me this is the benefit of having a discovery "service". Any person or service can contact my discovery service and find my preferred services (much like the use case you outline as the end of your post). While in many cases my identity provider may also be my discover service it doesn't have to be that way and the protocols shouldn't require that.

If the Identity/OpenID Provider provides a Open Token verification API, then it would have no way to make sure the token is being used at the same place for which it is granted. This goes back to the same problem that was solved by doing a RP Discovery in OpenID2.0.

Actually, I don't think the identity provider cares where the identity token is presented. The purpose of this identity token is to provide a "verifiable" identity (in the same vein that Amazon provides the "real name" feature). To me, the key is can the service provider that receives the identity token have confidence that this Consumer is "allowed" to send the identity token to the service provider. That's why the Consumer uses a nonce and a different hash value than is delivered to the Consumer by the identity provider.

This requires a real discovery service (process) instead of a simple XRDS (static) file hosted some where - since the services defined in the XRDS will be anyway protected, there shouldn't be any harm in saying "my notification service is here and oh btw, it's only open to a restricted list of people so you might not be able to send notification to me".

This is a great point. It does require more processing logic than just returning a file on disk. However, any protected resource requires a service, even when using OAuth so I don't see that as a big hurdle. Even if we separated the discovery information into public and non-public, it would still simplify the logic to be able to serve the non-public data based on an identity token versus a full OAuth UI experience.

Open Identity Token seems less trust worthy - of course the same problem that people attribute to OpenID but at least in OpenID case, it is not directly meant for a specific service invocation - it's merely for knowing who the user is and the RP/SP can do more things before it allows the user to do certain things.

I guess I'd argue that the trust of the token is dependent on a lot of factors. Does the service provider trust the identity provider? (this is that same trust question that OpenID faces). Can I trust the security of the protected token? (as described in my post it's probably only as good as OpenID "dumb mode", but that is pretty easily solvable). I'd also argue that there is great value in having a verifiable identity for certain operations. Yes, I can get a verifiable identity by using front-channel requests and asking the user to authenticate... again... but if it's not needed, why put the user through that experience? Also, using a Open Identity Token where a verifiable identity is required significantly reduces the number of interactions between the Consumer and Service Provider.

With an Open Identity Token...
1. Consumer accesses protected resource at the Service Provider with Open Identity Token
2. Service Provider verifies Open Identity Token with Identity Provider
3. Service Provider performs access-control check and returns response

With standard OAuth...
1. Consumer accesses protected resource at the Service Provider
2. Service Provider returns error and requests authorization
3. Consumer requests the RequestToken
4. Consumer sends user to the Service Provider 'Authorize' endpoint
5. The Service Provider uses the check_immediate method to attempt to authenticate the user (Assuming the Consumer sent the Service Provider an OpenID for the user)
6. The OpenID Provider returns that the user is logged in
7. The Service Provider invokes the Consumer's callback method (front-channel)
8. The Consumer requests the AccessToken
9. The Consumer re-tries the initial request for the protected resource (and gets access if the identity associated with the OAuth AccessToken is in the ACL)

In general in the current social networking era where things (notification) are more publish/subscribe model, not sure how important it is to solve this use case. Most of the user's anyway still use their email addresses not a notification service.

With an Open Identity Token, there is no requirement that the UserIdentifier value be the user's OpenID. It could be the user's email address, an opaque blob, a signed SAML Assertion, etc. Again, I consider the identifier association problem to be "out of scope" for identity tokens.

Thanks for the great comments. This is exactly the kind of discussion I hoped to start. One of my driving motivations in this is to enable easy access-controlled sharing such that my parents and in-laws don't have to have accounts at my personal photo service, and yet I can ensure that only the people I want can access my personal photos. I've never liked the security-by-obscurity model used for "privately" sharing my photos with others who don't use my preferred service.

Tags: Open, Identity, Token, Portable Contacts, OpenID, OAuth

Open Identity Token

2008-09-03T08:26:00.003-04:00

Assuming that an “Open Identity Token” is useful, here are some of my initial thoughts.

The identity token needs to clearly identify the identity provider that issued the token, some value that identifies the user, and I believe the party the token was initially issued to (the Consumer in OAuth speak).
The value that identifies the user must support opaque values to prevent this token becoming a global correlation handle (if desired by the involved parties). Of course, the user identifier could be the user’s OpenID.
The identity token must be signed in some way and protected from replay attacks.

If we go back to the use case from yesterday’s post, using a Open Identity Token would enable the flow to work like this.

Alice logs into hikingtrails.example.com with her OpenID
- When hikingtrails.example.com invokes the OpenID flow, it asks Alice’s OpenID provider to return an Open Identity Token
- hikingtrails.example.com receives the OpenID assertion and Open Identity Token
Alice uploads a GPS track and some photos of a new trail she hiked over the Labor Day weekend.
At the conclusion of her upload, hikingtrails.example.com asks Alice if it should notify her friends about her activity.
Alice thinks that’s a great idea and agrees.
So hikingtrails.example.com queries portablecontacts.example.com, using pre-established OAuth credentials, and retrieves Alice’s list of contacts with a tag of “hiking buddy”.
Now for each of these friends, hikingtrails.example.com has to discover the “notification” service and send it the new activity message.
One of Alice’s friends, Bob, only exposes the endpoint and metadata of his “notification” service to a restricted list of people
hikingtrails.example.com queries Bob’s discovery service presenting the Alice’s Open Identity Token
Bob’s discovery service validates Alice’s Open Identity Token and then returns the non-public service endpoint and metadata

In this flow, Alice does not have to interact via some user interface with Bob’s discovery service. Of course the identity represented in the Open Identity Token needs to be resolvable in to an identifier that Bob’s discovery service can use.

Finally, here are some initial technical implementation ideas...

I was thinking that the identity provider could construct the token and “sign” it with a HMAC_SHA? hash. The signature-base-string would be IdentityProvider:Consumer:UserIdentifier and the identity provider would construct a random value to use as the secret in the HMAC_SHA? hash. This value would need to be remembered based on the IdentityProvider:Consumer pair. What would be returned (probably base64’d) as the Open Identity Token would be “IdentityProvider:Consumer:UserIdentifier,hash”.

When the Consumer that receives the token wants to use it in an API call, it constructs a unique Open Identity Token (to protect against replay of the token) for the API call. This token uses the hash received from the Identity Provider as the secret in a new HMAC_SHA? hash. The signature base string for this hash would be “IdentityProvider:Consumer:UserIdentifier:Nonce”. What would go on the wire as the token would be base64(“IdentityProvider:Consumer:UserIdentifier:Nonce,hash”).

When a Service Provider receives the Open Identity Token, it can verify the token by sending it to the IdentityProvider specified in the token. For OpenID this would require a new extension and “API” method. Note that in the verification step, if the user identifier was opaque in the token it can be resolved into something the Service Provider can use. This allows for generating tokens that are unique to a specific context (no global correlation) while still providing the Service Provider with the data they need.

In this model, only the identity provider can validate the Open Identity Token because it is the only entity (besides the Consumer) that has the secret used by the Consumer in signing the token. All the identity provider needs to do is look up the hash it gave to that Consumer and then use it in a HMAC_SHA? hash of the “IdentityProvider:Consumer:UserIdentifier:Nonce” string and finally compare hashes.

I realize that going back to the Identity Provider to verify the token does have some drawbacks: privacy (leaking where this identity token is used), complexity and performance (an extra lookup/validation is required). But since I’m not a security expert, I’m hoping that others will be able to modify these ideas to allow for direct Service Provider validation. It’s just critical to me that the mechanism used to generate the Open Identity Token allow for both un-defined “circles of trust” (e.g. OpenID) as well as more closed or dynamic “circles of trust” (e.g. SAML). This might be as simple as leveraging the OAuth signature method and then support RSA signing.

Tags: Open, Identity, Token, Service Innvocation

Protecting "discovery" information?

2008-09-02T13:38:00.003-04:00

I’ve been thinking a lot lately about discovery of personal services (e.g. endpoint and metadata of my “portable contacts” service, endpoint and metadata of my preferred “email service”, etc). One problem with enabling discovery of this kind of information is that it leaks information about me. For example, I might not want the world to know where I keep my personal photos?

So the question is... How, in the world of open identity protocols, do I restrict access to a subset of my “discovery” information? The obvious answer is for the discovery service (or service provider in general) to restrict access based on the identity of the invoking party. However, how is that invoking identity presented? At first thought is seems like OpenID and OAuth should suffice, but it turns out this doesn’t work to well in practice.

Let’s take the following example and walk it through.

“Alice logs into her hiking site, uploads a GPS track and photos, and notifies her friends of the new information.”

Alice logs into one of her favorite web sites (hikingtrails.example.com).
Alice uploads a GPS track and some photos of a new trail she hiked over the Labor Day weekend.
At the conclusion of her upload, hikingtrails.example.com asks Alice if it should notify her friends about her activity.
Alice thinks that’s a great idea and agrees.
So hikingtrails.example.com queries portablecontacts.example.com, using pre-established OAuth credentials, and retrieves Alice’s list of contacts with a tag of “hiking buddy”.
Now for each of these friends, hikingtrails.example.com has to discover the “notification” service and send it the new activity message.
One of Alice’s friends, Bob, only exposes the endpoint and metadata of his “notification” service to a restricted list of people.

It’s at this point that things begin to break down. How does hikingtrails.example.com identify Alice to Bob’s discovery service so that hikingtrails.example.com can attempt to discover Bob’s “notification” service? There currently isn’t a binding for OAuth to be used with XRDS discovery, and even if there were, it would mean that Alice would have to have an “account” at Bob’s discovery service in order for the discovery service to be able to authenticate Alice and establish OAuth credentials. While this would only have to be done once with Bob’s discovery service, the user experience would have to be repeated with each of Alice’s friend’s discovery service. That seems like over kill for the simple purpose of identifying Alice to Bob's discovery service.

A possible solution would be an “open identity token” that could be created by an identity provider and passed to any service provider. I have some thoughts on this that I hope to expound on in another post.

Tags: Discovery, Portable Contacts, OpenID, OAuth, Access Control

Identity-based discovery for the masses

2008-08-06T13:22:00.001-04:00

The ability to link people relationships to services in a very dynamic and distributed way is beginning to emerge. Envision a world where current social network relationships enable the discovery of personal services about any particular identity.

Consider the following use case: I want to notify (via the preferred mechanism of the recipient) all the people tagged as “close friends” in my “address book” or “social network”.

The problem is that while address books and social networks can know the relationship of “close friend”, they usually don’t have any way of knowing the “preferred mechanism of the recipient” to receive notifications. What’s needed is a way to “discover” via the identifiers in the “social relationship” the personal services of any particular individual.

So, what’s changing? A “new” community specification EAUT (Email-Address-to-URL-Transform) is being completed that allows an email address to be transformed (or mapped) into an OpenID. While this, in and of itself, is valuable for the adoption of the OpenID protocol, what I find really interesting is that since OpenID relies on XRDS for discovering the individual’s OpenID Provider, the mechanism is in place to discover any other service. This really enables an email-to-personal-service-discovery path that can launch a whole new set of use cases.

Even if the user doesn’t know anything about OpenID... the user’s social network could easily retrieve the OpenID’s for all of the user’s social relationships (since most are based on email address or have access to the email address). The social network could then provide additional services based on this discoverable information.

With most of the major identity providers already providing OpenIDs, all that's needed is for these players to support the EAUT specification.

[Disclaimer for my Liberty Alliance colleagues: These capabilities are already supported by combining the People Service and the Discovery Service for SOAP based deployments.]

Tags: Identity, Discovery, OpenID, EAUT, XRDS

Friend Classifications

2008-06-03T09:08:00.002-04:00

A colleague of fine was mentioning recently that it's "hard to keep contacts separate (work/friends/family)" on all the different social networking sites. I couldn't agree more. This is made additionally hard by the fact that each "social network" site imposes their own "classification" of friends. These classifications are not mine and I have to morph my view of my contacts into these imposed rigors.

I would much prefer to be able to manage my contact classifications as "tags". Taxonomies force me into specifying that a contact can be in only one group. I have work colleagues that are also friends. If I could "tag" all my contacts with my own classification scheme and then use that when interacting with social networking sites, life would be much simpler.

I guess this is the "promise" of the "Open Social Web".

Tags: Friends, Classification, Open Social

XRDS for Information Cards?

2008-05-15T11:26:00.000-04:00

One of the topics that came up at the most recent IIW (IIW2008a) in a couple of sessions, is the concept of allowing an RP/SP to describe it's services and requirements in a passive way. The goal being to allow "Identity Agents" to provide a progressively better user experience. A user should be able to interact with the RP in a normal "dumb" browser session, but also allow tools (e.g. an Identity Agent) to provide a much more seamless experience.

In an InfoCard Capabilities session, lead by Pamela Dingle, there was some discussion about how to do this technically. The following is a proposal for one way this might be accomplished.

The "Relying Party" would need to...

define an XRDS file describing identity protocols supported, services provided, and other metadata
allow for discovery of the XRDS file through normal XRI resolution (section 6)
additionally allow for discovery by adding a
```
<link rel=”xrds.metadata” target=”location-of-xrds-file”/>
```
in the <head> section of the pages provided by the relying party

The "Identity Agent" would need to...

look in web page dom for the xrds.metadata link
retrieve and parse XRDS document
find supported identity mechanisms and endpoints
invoke card selector
allow user to select card
post card to endpoint specified in the XRDS document

What could the XRDS markup look like for an InfoCard relying party?

First we need to define some <Type> URIs to represent different metadata characteristics of the relying party relating to InfoCards. Here are some possible examples...

<Type>http://infocardfoundation.org/policy/1.0/login</Type>
This type identifies the service/endpoint describing the claims required for login.
<Type>http://infocardfoundation.org/policy/1.0/registration</Type>
This type identifies the service/endpoint describing the claims required for registration.
<Type>http://infocardfoundation.org/service/1.0/login</Type>
This type identifies the service/endpoint where the login token should be sent.
<Type>http://infocardfoundation.org/service/1.0/registration</Type>
This type identifies the service/endpoint where the registration token should be sent.

An example XRDS document could look like...


      <?xml version=1.0 encoding=UTF-8?>
      <XRDS xmlns=xri://$xrds>
        <XRD xmlns=xri://$XRD*($v*2.0) version=2.0>
          <Type>xri://$xrds*simple</Type>
 <!-- Service specification that identifies the endpoint of the infocard policy for login claims -->
 <Service>
  <Type>http://infocardfoundation.org/policy/1.0/login</Type>
  <URI>http://sp.example.com/policy/login.xml</URI>
 </Service>
 <!-- Service specification that identifies the endpoint of the infocard policy for registration claims -->
 <Service>
  <Type>http://infocardfoundation.org/policy/1.0/registration</Type>
  <URI>http://sp.example.com/policy/registration.xml</URI>
 </Service>
 <!-- Service specification that identifies the endpoint for submitting login claims -->
 <Service>
  <Type>http://infocardfoundation.org/service/1.0/login</Type>
  <URI>http://sp.example.com/login</URI>
 </Service>
 <!-- Service specification that identifies the endpoint of the infocard policy for login claims -->
 <Service>
  <Type>http://infocardfoundation.org/service/1.0/registration</Type>
  <URI>http://sp.example.com/registration</URI>
 </Service>
        </XRD>
      </XRDS>

How times change

2008-05-08T09:31:00.000-04:00

I must be getting "old" as I find the following humorous.

The other morning my daughter said she was doing a report on "family life" in the 1980's. My wife (who likes to research things) grabbed her laptop and started looking information on the 1980s. She finds a site and reads something like...

In the early 80's, the computer game "Pac Man" was released in color making all previous black and white games obsolete.

To which my daughter responds... "What's Pac Man?"

Community Convergence

2008-05-02T10:31:00.000-04:00

There has been much talk in our industry about Technical Convergence (i.e. moving toward one protocol for a particular task). However, before there can be Technical Convergence, there needs to Community Understanding and potentially Convergence.

That's why I'm excited to be attending the Internet Identity Workshop in Mt. View, CA the week of May 12. This is one of those places where Community Understanding takes place and sometimes even Community Convergence.

Hope to see you there!

Tags: Convergence, Community, Technical

Discovering OpenID Relying Parties

2008-04-09T09:49:00.001-04:00

Yesterday Paul blogged about his experience logging into Wishlistr with his Yahoo OpenID.

But, when I tried to do so, Yahoo! showed me the following warning

What would Wishlistr need to do to 'confirm its identity' to Yahoo such that users wouldn't see this (likely enthusiasm killing) warning?

I commented on Paul's blog that it might have something to do with OpenID Relying Party discovery. Section 9.2.1 of the OpenID 2 spec defines how to verify the return_to URL in an OpenID authentication.

OpenID providers SHOULD verify that the return_to URL specified in the request is an OpenID relying party endpoint. To verify a return_to URL, obtain the relying party endpoints for the realm by performing discovery on the relying party.

I tried requesting the XRDS description from Wishlistr to no avail (curl --header "Accept: application/xrds+xml" -i -v http://www.wishlistr.com ). Section 13 of the OpenID 2 spec makes it a SHOULD for relying parties to support discovery. With the adoption of OpenID 2 just beginning to ramp up, relying parties supporting discovery may be a ways away.

Please note that this is just my guess as to what might be causing the warning. There are many other possible causes as well. Though I do believe that RP discovery is a key feature of OpenID 2.

Tags: OpenID, Discovery, Relying Party

Identity API for the Internet Identity Layer

2008-04-03T16:53:00.000-04:00

Patrick Harding has a great post today on "A Model for an Internet Identity Layer". He breaks down the Identity Layer into three sub-layers. It addition he points out that...

In addition, we have found that applications developers are spending far too much time concerning themselves with the lower levels of the identity layer. App developers need to be able to leverage a standard identity API interface that interacts with the claims sub-layer. The developer should receive all the information it needs via this API directly from the claims sub-layer. This information obviously manifests as claims and as such means that application, by default, must become claims aware. Today, this likely just means user attributes or a role value, but in the future this may include actual authorization decisions. Leveraging a standard API that allows an application to plug-and–play with the identity layer offers some future proofing as the identity protocols underneath change.

Interestingly enough, Phil Hunt talks specifically about this issue his post yesterday.

You see, the idea isn't just to support identity privacy and governance, but to create an application identity API (aka Attribute Services API) that allows applications to become decoupled these issues of having to support all the protocols and technologies out there. It lets the enterprise's decide how and when applications should access identity information and by what means.

The API the Phil references is the IGF AttrSvcs API that is part of the openLiberty project. I believe this API address a key component of the "Identity Interface" and "claims sub-layer". It's going to be very important to track policy at the "Identity Interface" and the Identity Governance Framework addresses these issues.

Trust relationships in OpenID

2008-04-02T09:00:00.000-04:00

A while back I wrote the following to the OpenID general list serv.

As I see it there are 3 parties involved in the transaction: the user, the OP and the RP. There is some trust/risk factor associated with each relationship.

From the user's perspective they "trust" the OP (either because they want to spam and so are using an OP that makes "false assertions", or because they trust the OP to protect their authentication credentials and represent them correctly on the web). The user may or may not trust the RP, but by logging in they are making some level of trust/risk assessment.

From the OP's perspective the user represents some risk/value metric (too many "bad" users and the OP gets blacklisted). The OP protects that risk by potentially verifying email or cell number, supporting PAPE and other strong authentication methods, etc. The OP also has a risk/value metric with the RP though this is probably not super important right now. I can envision a smart OP warning me about authenticating to an RP that it some how determined is not "trustworthy".

From the RP's perspective, they have a risk/value metric on the user (e.g. Is the user going to be a good citizen of my community? Are they going to abuse the resources I provide? How much effort do I want to put into detecting "bad apples"?). The RP also has a risk/value metric on the OP (e.g. When the OP says they support the PAPE extension do they really do it?). Finally the RP has a risk/value metric on the resource/service they provide. From a business perspective I don't believe it's wise to blatantly "trust" the user if the resource/service is highly valuable (e.g. moving funds between accounts). Most users today don't have the sophistication to make good decisions.

Ok, so maybe I was a little unfair in my characterization of “most users”. I was trying to say that I don't believe many users know how to chose a good OP. In fact many will just use an OP they already have (which puts pressure on those OPs to be good citizens; that's a “good thing”). So, if an RP has a high trust metric with the user's OP, then they can more confidently trust the user as well. On the RP side its really an assessment of risk against the “User:OP“ pair.

Tags: OpenID, Trust

"Open" Foundation Overload

2008-03-27T13:02:00.000-04:00

With the creation of the OpenSocial Foundation, the DataPortability Group (they'll need a Foundation soon), the Information Card Foundation and of course the now established OpenID Foundation... I'm getting "foundationed" out.

I wonder if the community couldn't do something closer to OASIS and have one over arching Foundation with sub-groups working in each of these important areas. The IPR could be consistent for all the groups, but each group would have it's own "board of directors" and control the results of specifications and other efforts.

All the different focuses are important, and new areas will arise as the identity layer grows across the internet. However, convincing "management" to join multiple different organizations is a deterrent to participation.

Tags: OpenID, OpenSocial, DataPortability, Information Cards, Foundation

Is AOL exploiting OpenID?

2008-03-24T18:04:00.000-04:00

Today, Michael Arrington (of Tech Crunch) posted an article posturing that AOL (along with Microsoft, Google and Yahoo) are attempting to exploit OpenID by being OpenID Providers (OP) and not becoming OpenID Relying Parties (RP). I attempt to address a number of issues in this post below.

"By becoming Issuing parties, AOL and Yahoo hope to see their users logging in all over the Internet with those credentials. But they don’t accept IDs from anywhere else, so anyone that uses their services has to create new credentials with them. It’s all gain, no pain."

In addition to not being true (about AOL), the above statement doesn't make sense. There is little value in having to store a user's identity credentials and then verifying against them when it comes to identity management. A company's decisions around when to require a local account and when to accept 3rd party identities revolves around the risk of the resources being offered. If the 3rd party identity provider (in this case an OP) is trustworthy, then it's much preferrable to "outsource" the identity verification to that provider rather than deal with the security and privacy issues of storing credentials. Plus with OPs that support one-time-passwords, hardware tokens, etc, a RP can gain the benefit of strong authentication without having to implement the infrastructure themselves. So, it's not "all gain, no pain". In fact, requiring people to create account is PAINFUL (both for the company and for the user).

"Issuing parties make their user accounts OpenID compatible. Relying parties are websites that allow users to sign into their sites with credentials from Issuing parties. Of course, sites can also be both. In fact, if they aren’t both [OP and RP] it can be confusing and isn’t a good user experience."

Actually, I would disagree with this statement. The point of OpenID is to provide a user with a few identities (maybe one) that they can use at many web sites across the internet. This means that many sites will just be RPs and won't need to support the OP parts of the protocol. I do agree that the next wave of adoption will be more sites (large and small) becoming RPs.

For AOL, being an RP is important because it allows more people to use our services without requiring them to create yet another account with another password to remember. The more people that visit and interact with AOL services, the more successful AOL will be. Both ficlets and Circa Vie are OpenID relying parties and a substantial number of their users are 3rd party OpenIDs.

"It’s time for these companies to do what’s right for the users and fully adopt OpenID as relying parties. That doesn’t fit in with their strategy of owning the identity of as many Internet users as possible, but it certainly fits in with the Internet’s very serious need for an open, distributed and secure single log in system (OpenID is all three)."

I have two things in regards to this quote. First, it is not AOL's strategy to "own the identity of as many Internet users as possible". I've already stated why above. Second, there is another element that is key to the "Internet's very serious need" and that is "trust". Some call it reputation. It's great that OpenID 2.0 is open, distributed and secure (from a data-on-the-wire perspective). However, relying parties need to assess the business risk in regards to the resources (e.g. free storage, free domain names, free email) they are providing. With OpenID 2.0, it's possible to implement an OpenID Provider that claims using strong authentication to verify the user but in reality is not even requiring a password. This means anyone can sign up at any RP without needing an account at the OP. The RP needs to determine if the business risk to this kind of abuse is acceptable.

I believe it is this later case that is causing the larger companies to move more slowly when it comes to enabling all their services to 3rd party OpenIDs. Note that not even at Live Journal can you create an account with a 3rd party OpenID. What you can do at Live Journal is leave comments and be added to friend's lists.

[Disclaimer: For those that don't already know, I work for AOL.]

Tags: OpenID, AOL

Authentication for clients

2008-03-05T10:59:00.000-05:00

Today AOL relaunched the OpenAIM initiative. One of the key parts of this effort is supporting authentication for clients (whether those clients are native code or FLASH/AIR/Silverlight/etc). To enable this we added a 'clientLogin' API to our OpenAuth suite of APIs.

This support is to enable a user experience that comfortable to AOL's existing members. If a user installs a client application, it is expected that any authentication that is needed is done through the client. To secure this method we use the password and a session key (transfered via SSL) to sign all requests from the client application. This ensures that all valid requests are coming from a client where the user entered their password. In addition, all API calls are monitored for abuse.

For the signing mechanism we used the OAuth signature base string method. However, given that we already had parameter names (in existing APIs) that map to the OAuth parameter names, we used the existing parameter names in favor of the OAuth names. Otherwise, the logic is the same.

I realize that from a pure privacy and security perspective, the OAuth flow of "popping" a browser and having the user only enter their credentials at the "owning" IdP is better. However, for many of our customers this is an unexpected user experience. clientLogin enables the desired user experience.

Tags: OpenAIM, Authentication, OAuth

How times change

2008-03-05T10:34:00.000-05:00

A couple nights ago my teenage son was on the family computer “working” on facebook.

So I asked him “How are your friends doing?” (trying to be a good parent and get my kids to talk:) ).

My son answers “I'm trying to help Judson and Samuel be friends” (names changed to protect the innocent).

I ask, “Why, are they not getting along? Did something happen?” (rather surprised).

“No”, he answers, “they can't find each other on facebook.”

I should have known.

Valentine's one day early

2008-02-13T17:00:00.000-05:00

I'm not sure what it is about Valentine's Day and Virginia but this is the second year in a row.

More on Email to URL discovery

2008-02-06T11:40:00.000-05:00

Just a couple more thoughts on this topic.

I believe that the mapping from email domain to XRDS URL should include some addition pattern to make deployments easier. Deploying a servlet or other mechanism on the root email domain is not always easy. Having a different pattern such as xrds.my-email-service.domain would simplify deployment issues.
While it is nice that an email to URL mapping service can provide user-centric identifier management, I don't know how much it will be used by the general public. Discovering that the email provider is also an OpenID 2.0 provider would be enough to start a directed identity flow. This I believe would be more convenient for most users.

Email to URL discovery

2008-02-05T13:07:00.000-05:00

In the ongoing "world" of IdP discovery a new proposal has been made by Brad Fitzpatrick on his blog. This proposal provides for a direct mapping between an email address and a personal URL (e.g. an OpenID). The mapping between the email address and personal URL is provided by an email2url_mapping service run by the email provider. Discovery of the email2url_mapping service endpoint is found via XRI URL resolution on the domain of the email address.

Whether the user needs the full indirection capability to have an arbitrary mapping between email address and URL or is fine with allowing the email provider to be their OP/IdP is yet to be seen. It is encouraging to see consumer's UX needs being addressed.

Looking at the evidence...

2008-01-19T11:46:00.000-05:00

... it seems that we still have a ways to go when it comes to user education, user-centric identity and IdP discovery. I applaud Yahoo! and Blogger for supporting OpenID by being OpenID Providers. That is a huge step forward. However, it's interesting to note how these main stream relying party (RP) sites are implementing the user experience.

From the OpenID listserv it appears that Yahoo! would prefer RPs to put a Yahoo! logo on their site that is clickable to enable Yahoo! users (and others) to login to that site (using the "directed identity" flow).

Also, looking at the Blogger implementation of accepting OpenIDs they list 4 main OpenID providers (I'm guessing Yahoo! will be added to the list) and then a button for "Any OpenID".

Maybe lesser known, but propeller.com (an AOL property) which accepts OpenIDs uses the OpenID protocol to authenticate AOL/AIM users but presents the UI as "Sign in using my AOL Screen Name".

What I find fascinating about this trend is that it bypasses one of the benefits of an OpenID (built in IdP discovery). Basically, these main stream RP sites are using the "User picks their IdP" solution for determining where to send the user rather than having the user type in their IdP (yahoo.com, openid.aol.com, etc) or full OpenID URL. At the moment, this scales OK as there aren't that many mainstream providers, but either user education needs to get better so this mechanism isn't needed, or we need a different technical solution.

WebGuild Web 2.0 Conference

2008-01-19T11:41:00.000-05:00

I'm participating in a panel at WebGuild's Web 2.0 Conference and Expo being moderated by Johannes. The panel will be discussing OpenID and OAuth among other things. It should be a good discussion given the recent announcements by Yahoo! and Google.

Discovery, wherefore art thou Discovery?

2007-12-20T12:05:00.000-05:00

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

Soapbox: "Likely to offend some" ???

2007-12-20T08:20:00.000-05:00

I smiled at Paul's recent post of Xmas Cards. I find it humorous that in our society we quibble over such silly things. However as I thought more about it, what really struck me was the double standard that exists but we ignore all the time.

What is it about “Merry Christmas” that might offend someone?

Is it that Christmas is equated to a Christian holiday and somehow recognizing that such a holiday exists is offensive?

This doesn't make sense to me because I would guess that the majority of people who celebrate “Christmas” do not hold to the “truths of the Christian faith”. Christmas for them is a merry time of year to give to others and receive gifts from others. It's a time to enjoy family and friends. What is so offensive about that? Would people be offended if the greeting were Happy Hanukkah?

Is it that the word “Christ” appears in Christmas and hence that is offensive to some?

This really doesn't make sense as the same people who are offended by the term “Merry Christmas” probably use “Christ”, “Jesus”, “God”, etc on a daily basis as an expression or expletive. So if it's OK to use these terms in a way that doesn't relate to the object of the term, why would the rule change for “Merry Christmas”?

The double standard is that it's OK to offend people who believe in God and Jesus Christ, but it's not OK for those people to use the same terms in an honoring way because they might be offensive to those who don't hold the same beliefs.

So I'm not quite sure whether I should smile or be “offended” that “Merry Christmas” is “Likely to offend some” :)

From the "Feeling rather behind..." department

2007-12-20T07:56:00.000-05:00

A few weeks ago Johannes Ernst's posted a blog entry, in which he describes a number of tiers regarding different classes of identity relationships between a business and it's partners/customers. I like the taxonomy and agree that its a good framework for communicating both identity issues and technology relevance.

I just wanted to add that Ping! Identity's proposed “dynamic federation” would perfectly suit Tier 2. It provides good secure SAML based federation while being easy to deploy. Of course, some of those 100's of affiliates might not support SAML as their identity solution so other easy to deploy mechanisms will need to exist as well.

This multiple protocol, deployment environment is the main goal of the Concordia project. The definition of these environments as use cases and then the proposed solutions will significantly help businesses integrate their affiliates in a quick and seamless manner.

Finally, I would expect that a business would want to use a single standard technology for Tier 0 and 1 as “federating” internally is a real pain.

Tags: Identity, Dynamic, Federation

OAuth framework code checked in

2007-11-26T16:41:00.000-05:00

Ok, I've got the Mac OS 10.4.x port of OAuthConsumer framework checked in. You can get the code via anonymous svn here.

OAuth consumer framework for Tiger

2007-11-22T20:35:00.000-05:00

Just a short post to say that I've completed a Mac OS X Tiger port of Jon Crosby's OAuth Consumer framework and it should be appearing in the google code repository shortly. The back-port to Obj-c 1.x was very simple and I've tested the framework on Tiger against the version 2 ma.gnolia APIs. Start writing those cool Mac apps:)

Tags: Idenity, Web Service, Framework, Mac OS X

Happy Thanksgiving from Virginia

2007-11-22T10:29:00.000-05:00

Shenandoah River Valley

(taken Oct. 28, 2007)

"God saw all that He had made and it was very good." Genesis 1:31

Tags: Photo, Thanksgiving

Standards glue (a.k.a. conventions)

2007-10-24T20:05:00.000-04:00

While attending DIDW (ok, this is a little late for a DIDW blog entry) I heard an interesting presentation by Michael Barrett CISO of PayPal. One of his concerns is that we are getting more and more identity standards rather than fewer. In some senses we are fracturing the market rather than uniting it even though most agree that identity is critical to the success of the web and services going forward.

I've been feeling for a while that we have enough protocols to satisfy the different use cases that exist and many that will come up in the future. What we don't have is a way to use what exists as standards across a wide range of disparate deployments. This causes confusion for users and lots of work for developers. There is also the "I'll wait and see" affect in the industry as companies wait to see which "protocol" will "win".

However, getting something that covers 50% to 80% of the use cases approved as a standard and adopted is rather a long process. So what about just some simple conventions that would allow existing protocols, services, and deployments to work together? In the past I've talked about both HTML markup on the RP web site as well as specifying the user's IdP in an HTTP header via an identity agent on the user's device.

Here is another. What about a simple transform on an email address to construct an URI that can then be put through the "Discovering an XRDS document from an http(s) URL" process? This would be another way to determine the IdP in an RP initiated authentication event. This could be something like take alice@example.com and transform it to http(s)://services.example.com/idp. I'm not particular to the transform itself, just that there be a way to convert an email address into a URI than can be commonly processed to determine the IdP endpoint(s) and supported protocol(s).

Tags: IdP Discovery, Concordia

YAIDO - Yet Another IdP Discovery Option

2007-10-23T21:40:00.000-04:00

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

"Schooled" again...

2007-10-23T03:13:00.000-04:00

I'm here in Tokyo for a Liberty Alliance meeting of the Technical Expert Group. This noon we had a "pick-up" soccer (football to the rest of the world) game. Not being in the best shape our TEG co-chair made quick work of our challenges on the field:)

Here are some less incriminating pictures from the event.

Many thanks to Mikko Laukkanen for taking the pictures.

More pictures by Phil Hunt found here. I'm sure more will be appearing shortly.

Tags: Liberty Alliance, TEG, Soccer

Blessings of an early flight home

2007-10-23T01:25:00.000-04:00

DIDW 2007: Shameless Plug

2007-09-21T15:46:00.000-04:00

Like many others I'll be at DIDW 2007 next week. I'll be giving a talk on the evolution of identity at AOL. I'm very proud of the significant identity model changes that AOL has been able to make over the last couple of years. I'll be covering this and amongst other things, our continued support of open standards.

Trust in social networks and identity protocols

2007-09-21T15:41:00.000-04:00

So I've been “noodling” over this analogy for a while. People often complain that protocols like SAML are complex and not scaleable because they require “out-of-band” provisioning. In other words, in deployment something has to happen first, before the protocol becomes valuable. In the case of SAML, this “out-of-band” provisioning is what adds trust to the deployed network (hence the name circles-of-trust). (For all the SAML experts out there, please forgive my simplistic characterization).

One of the big selling points for OpenID is that it does not require this “out-of-band” provisioning and hence is easier to deploy and more “scaleable” (I believe the term is “internet scale”). However, one element missing from OpenID is trust. The ideal is that both OPs and RPs trust the user, but that is a lot of risk for especially the RP to take on in today's business climate.

So how does this relate to social networks? Well, in many social networks, both parties have to agree to the relationship before the relationship becomes valid. This might not be explicitly “out-of-band” but it is similar in concept. For example, if I invite someone to be a friend on Facebook, they don't show up as a friend until they have explicitly approved the relationship. Because of this factor, I am in essence building a “circle-of-trust” that is my friends on Facebook.

The “OpenID” example in social networks is AIM. I can add anyone I want to my buddy list (provided I know their AIM id) and they will be part of my network. I will also see when they are online and offline. The only way for a person to “block” this behavior is to reject presence information for all users except those on their buddy list.

My buddy list on AIM is definitely a social network of “people-I-know” but I don't think I could go so far as to call it a “circle-of-trust”:)

Tags: SAML, OpenID, AIM, Trust, Social Networks Protocols

AOL OpenID provider whitelist

2007-08-17T09:14:00.000-04:00

So there has been a lot of discussion regarding AOL's support for 3rd party OpenIDs and the fact that currently AOL has a whitelist of approved OpenID providers. A number of good points have been raised.

Kim Cameron writes...

What would make $$$ for AOL? To get my pretty eyeballs over there PDQ. What’s the best way to make that happen? Make it easy! Acquire new eyeballs! Acquire new eyeballs! Acquire new eyeballs! From anywhere and everywhere!

The secret? Auto-create an account on AOL no matter WHAT credential a user employs to get there. You need this anyway to manage their profile. Then get the user transparently to great experiences and start ringing up those eyeball seconds.

I fully agree with Kim that eyeballs are the desired commodity. In fact, that is the whole reason AOL is implementing open standards and allowing 3rd party identities. However, I do believe that accounts cost money (or at least can cost money depending on what that account is allowed to do at a service provider). Take a picture sharing site for example. The picture service will provide some amount of space for each account (this is true of email providers, etc). The picture service could charge for the space in which case the “real” accounts would be easily distinguished but most sites these days are trying the “free and paid by advertising” business model. Also, another indirect cost of an account comes from whether the account can publish content. Spammers love to create accounts for the sole purpose of posting one or two messages. They don't care that they are spinning through zillions of accounts. So yes, AOL is looking to get as many eyeballs as possible, but doing so carefully for this initial release.

Ashish Jain writes...

As it turns out, SignOn.com is not in their initial list. I talked to the AOL folks and they promised to add it during their update next week. Fair enough. However, this model isn’t scalable. Given the distributed nature of the protocol, it doesn’t seem right for IdP/OPs and RPs to individually contact each other to maintain this list. Isn’t there a need for an OP Reputation, a.k.a. qualification, a.k.a certification suite that the RPs can leverage?

Jeff Bohren writes...

In OpenID, there is very little perceived risk in being a provider. If a user compromises your site and uses your site to authenticate to a relying party as someone else, there is really very little consequence to you. After all you don’t have any agreements with any specific relying parties. Why not be a provider, if there is so little risk involved?

Being a relying party however is a different matter. If someone compromises a provider and falsely authenticates to your relying party, they are misusing someone’s resources. The sensitivity of these resources would make the difference between allowing unrestricted OpenID or white list controlled OpenID.

Ashish and Jeff both make great points. The crux of the issue is that all the risk is assumed by the relying party. That means the relying party needs to be able to detect “fraud” and take appropriate action. This could be done through a number of mechanisms like a “Provider” Reputation service or “fraud” detection infrastructure. The OpenID model is similar to the email model. Anyone can stand up a SMTP server and send mail. It's the receivers of the mail (ISP or individual) that have to filter the spam. In order to learn from our implementation and fix any bugs, we decided to take a cautious approach at first.

I would say this approach is actually very common in the Web 2.0 community. How many sites starting out are by invitation only? Do they do that to create buzz? Well maybe... but I suspect that the biggest reason is that it limits their exposure to invalid/spam accounts.

Finally, Carsten Pötter writes...

Is this the positive signal to send out to the community? Is there even a strategy at AOL? It seems like there is not much support for OpenID from within the company. But I may be wrong and see things too negative but I am actually really disappointed. :(

Well... I hope it is a positive signal to the community:) AOL is the first major provider to support OpenID as a relying party. As to strategy, yes there is one. It's one thing to implement the OpenID RP protocol. It's another to have all the associated infrastructure in place to detect and protect against “fraud”. As was pointed out earlier, the relying party assumes all the risk in the OpenID protocol. We are actively working on that infrastructure and process so that in the future we can remove the whitelist.

Tags: OpenID, AOL, Whitelist

The lowered expectations of web applications

2007-08-08T11:52:00.000-04:00

I find it interesting that consumers continue to put up with more and more “bugs” in the software and appliances we use. Today, in trying to publish my last post, I had to try 3 times to get blogger to accept the entry, including getting the wonderful page to the right.

While hardware appliances are better, I run into the same thing with my wide area wireless broadband connection. The first trouble shooting step is to reboot the wireless unit to see if that solves the problem.

Then just recently after getting back from vacation, I found that my satellite TV DVR service had been deactivated. When calling customer service to get it re-instated, it took the representative a couple tries to get it working. He finally had to first de-provision my DVR service and then re-activate it.

I guess the “benefit” for technologists is that we don't have to work so hard to build good products ;-)

Cardspace & Service Invocation

2007-08-08T11:42:00.001-04:00

I got thinking about Cardspace the other day and it struck me that Cardspace does a great job of authenticating me to the relying party, but the relying party can't use that authentication for service invocations on my behalf.

For example...

User browses to the relying party (RP) and is prompted by Cardspace to authenticate
User selects one of their cards (that they've previously used with the RP) and is logged in to the site
Next the RP wants to import the user's AIM buddy list in order to enhance the user's experience at the site (e.g. find other users who also use the RP)
The RP either requests AIM credentials and uses a back-channel API call to authenticate the user separately, or it redirects the user to AIM to authenticate
AIM validates the credentials and returns a service API token
The RP uses the service API token to request the buddy list
Note that the user now has two different and distinct authentication sessions (one with the Cardspace or Managed STS and one with AIM)

Now it would be nice if the RP could use the existing authentication “session” with the user (as represented by the Cardspace token) without forcing the user to re-authenticate to AIM. Of course, the RP has no way of knowing whether the token it has is valid at AOL, nor probably, how to transform the token it has into a token that is valid at AOL. I suppose that if the token is a SAML token, then the RP could look at the issuer of the token and check to see if it is the AOL STS and from that try to use the token at AOL. The problem for the RP is that it might need to interact with many different services. What kind of claims does the RP request of Cardspace in order to get a token with the desired capabilities (e.g. service invocation with either Google or AOL)?

In order to solve this problem, it is very common in today's web experience for relying party A to request relying part B's authentication credentials in order to provide a service to the user. However, I always feel very nervous about giving relying party B's authentication credentials to relying party A. As the number of identities that consumers have to manage shrinks, the overlap of an authentication session across multiple relying parties grows. The identity meta-system should allow for the re-use of the authentication session across multiple relying parties as approved by the consumer.

One workable model, though somewhat inefficient, is for relying party A to request a service invocation token from relying party B. Using OpenID as the authentication protocol, the flow goes something like this...

User browses to relying party A (RPA) and enters their OpenID to login
Relying party A invokes the OpenID authentication flow redirecting the user to their OpenID Provider (OP)
The user authenticates to the OP and is redirected back to RPA
RPA requests a service token from relying party B (RPB) using a browser re-direct
RPB requests an authentication of the user via their OP
Since the user is already logged into the OP, this authentication step could be “seamless” to the user
RPB creates a service invocation token for RPA and redirects the browser back to RPA
RPA requests the data from RPB using the returned service invocation token

All the front-channel redirects make it easy to get the user's consent as necessary. However, depending on the bandwidth of the consumer's internet connection, and the physical locations of RPA, RPB and OP, there can be some significant performance implications.

Tags: Concordia, Cardspace, Identity Meta-System, OpenID, Service Invocation

Divine IM? ... no ... Divine I AM

2007-07-11T13:16:00.001-04:00

Paul in his usual humorous way has an entry here describing some of the annoyances of IM systems. (I've recently run into something similar but that will have to wait for a different post).

Not surprisingly :), I do have an issue with Paul's “theology”. Yahweh (the God of the Bible) is a God of Relationship. IM is a rather un-relationship form of communication. In fact, I distinctly remember a conversation with someone well known in the identity industry, talking about how IM “paled” (my word) in comparison to meeting the person face-to-face. IM is useful in its own right but not one that takes the place of a personal conversation.

The giving of the Ten Commandments was not a short handoff of a “set of instructions” but rather a time where God spoke directly to the whole nation of Israel (Exodus 19-20). God then called Moses to a 40 day conversation at the end of which he received the stone tables.

Moses speaking in Deuteronomy 9:9-10...

“When I went up on the mountain to receive the tablets of stone, the tablets of the covenant that the Lord had made with you [Israel], I stayed on the mountain forty days and forty nights; I ate no bread and drank no water. The Lord gave me two stone tablets inscribed by the finger of God. On them were all the commandments the Lord proclaimed to you on the mountain out of the fire, on the day of the assembly.”

Yahweh communicated directly with the people of Israel and Yahweh still desires to communicate with each of us as well.

I do, however, agree with Paul on one thing. Too often we are “screening” out God.

Yahweh22: YT?
Moses88: I am not here right now.
Yahweh22: Moses, I know you're there, I can SEE you.
Moses88: Sorry Boss, I was screening.
Yahweh22: Well don't, it's annoying.

How can we possibly have a relationship with Yahweh (the creator of the universe; Genesis 1) if we don't listen?

Tags: Theology, Relationship

P.S. For those wanting the Biblical facts... the story of the burning bush can be found in Exodus 3-4 and the story of the 10 commandments can be found in Exodus 19-20.

Independence Day on the Potomac...

2007-07-07T21:28:00.000-04:00

"Better late than never"
(between Family and Work these had to wait till today)

Passive identity meta-system markup

2007-06-29T14:33:00.000-04:00

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

2007-06-27T14:33:00.000-04:00

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.

Even enterprise deployments have issues with the user experience. Enterprise users want a easy/seamless experience as much as consumers.
Companies have figured out to get COTS products based on different protocols to work together, albeit in a rather complex deployment architecture.
Scaleability of federation is a real issue. Scaleability issues exist in deployment configurations, administration as well as technically.
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

Sometimes you just have to go fish

2007-06-26T02:09:00.001-04:00

Shenandoah River, Virginia

Clients to the rescue

2007-06-15T15:37:00.000-04:00

So last week I blogged about issues the SP faces when trying to reach as many consumers as possible. There are things the SP can do to make this easier for consumers… but maybe “clients” are the “real” solution. Praveen Alavilli started a very interesting internal (to AOL) email thread which is in part summarized below.

For the sake of discussion, let’s assume that SPs have a way to markup up their sites with which identity protocols they support/require. Let’s also assume that the client knows which identities the user has authenticated in the current session and which identities were used with which protocol.

Using the use case from the previous post… My mother-in-law opens the browser to find a new coffee-cake recipe. She finds cooking.example.com which accepts OpenIDs. The client (browser/identity agent/etc) recognizes that the site supports OpenID and pops up a message to my mother-in-law saying “You can log into this sight using your AOL account. Would you like to continue?“. If she clicks the “Continue“ button, she starts the process of signing into the site with OpenID. If she is already authenticated, she should just get a consent page. [Note that the Versign Seatbelt and Sxipper plugins provide this kind of behavior for OpenID already.]

My problem with the current solutions is that they are all protocol specific. The client code has to look for OpenID named form elements, or Cardspace Object tags in order to determine what the site supports. In addition, SAML has no mechanism (as far as I know) to allow the SP to declare that it supports SAML. Sure the client app could try to query for SAML metadata for every web site but that is a lot of overhead where some simple markup would be so much easier. Consolidating this markup via a mirco-format or some simple <link> mechanism to a XRDS file would make this kind of client support that much easier.

Finally, if the client can detect and manage cross identity protocol interactions, then these additional features would make the user experience that much better.

Remember Identity (1)	Auto-Login (2)	Behavior
x		The identity agent would remember the mapping between the identity the user specified and the site. However, the identity agent would not automatically log the user into the site. The identity agent could present pop-up UI to ask the user if they want to log in or just enable a button in the frame of the client that the user can click when they want to log in.
	x	The identity agent would start a login to the site. The agent could just pop up UI with the current set of authenticated identities that match the supported identity protocols of the site. If there are no authenticated identities that match, it should show any identity it knows about that matches (this of course is more like Cardspace).
x	x	This is the SSO option for the client. Now when I browse the web I can be selectively, automatically signed in to the sites I care about. If the previously mapped identity is not already authenticated, the agent would start the authentication process.

(1) “Remember Identity” means that the client will remember the mapping between an identity and the site at which it is used.
(2) “Auto-Login” means that the client will initiate a login sequence without user interaction.

Tags: Identity, OpenID, Cardspace, SAML

The simplicity of symmetry

2007-06-15T14:53:00.000-04:00

When it comes to architectures I've always liked the simplicity of symmetric solutions. They are much easier to understand and it is easy to spot inconsistencies in process flow. Well... given the following story... it MUST be that symmetry is much easier for children to understand as well.

The other morning it was raining and my almost 4yr old daughter asked where her Cinderella umbrella was because she couldn't find it. My wife replied that it was in the mud room closet and was likely hanging up in the closet. My daughter went to investigate and came back in a few minutes with the following question. “Mommy can you help me hang it down?”

Principle: Don't underestimate the power of a simple solution:)

Tags: Architecture, Symmetry

Identity at the SP

2007-06-07T15:22:00.000-04:00

When it comes to identity, a Service Provider (SP) or Relying Party (RP) has a couple of key issues. One is customer facing (user experience) and another is technical (supporting multiple identity protocols). Of these two, the user experience is more important as it affects the consumer.

Take the following use case. My mother-in-law goes to a cooking web site to search for a new coffee-cake recipe. The cooking site (SP) allows for personalization and saving of favorite recipes, so she is presented with UI to login so she can save the recipe as a favorite (we'll assume that the “create the account” process has already occurred). The cooking site wants to support the widest range of people possible to access their site so they decide to support Cardspace, OpenID, and SAML at the identity protocol layer. Questions? How does the SP represent the UI so that it's not confusing to my mother-in-law? She doesn't understand anything about Cardspace, OpenID or SAML. She does understand that she has an AOL account.

Does this mean SP/RP's should be putting up icons of well known identity providers? That solution is not equalitarian and it doesn't scale. It's great that we have all these cool technologies that tackle different parts of the identity space, but it doesn't really help consumers if it is too confusing to use. I suspect most users know who they have an account with but not many know what protocol is used by their account. For example, I suspect that most Live Journal and AOL users do not know that they have an OpenID.

As for the technology side, the problem at the SP/RP is not that the issues are unsolvable (or even not currently solved). The problem is that all this code has to be written (or incorporated) and glued together to enable these different identity protocols. That is a rather significant barrier to entry. Currently, this tends to drive SPs to pick one of the existing identity protocols. From a business perspective this limits the total number of people that can use the service.

I tend to agree with Johannes, all this talk and work won't mean much if we don't make things simpler for the consumer first and the SP developer second.

Tags: Identity, SAML, OpenID, Cardspace, Service Provider

AOL supports simple federation with SAMLv2

2007-05-22T20:36:00.000-04:00

In addition to the work AOL is doing to support OpenID, we've also been working with SAMLv2 to provide a simple federation profile for our partners. This allows users to federate an account at a partner to an account at AOL so that SSO is enabled from the partner to AOL or vise-versa.

This implementation uses the “SAMLv2 Lightweight Web Browser SSO Profile” and “SAMLv2.0 HTTP POST SimpleSign Binding”. Since the current use cases are fairly restricted we simplified the process even more such that only source-first SSO, using an unsolicited <Response> message is supported.

The actual federation of identifiers is done during the registration process using existing AOL protocols. SAML is then used for the SSO Assertion between the partners. The flow goes something like this...

User goes to browser and loads site A
User authenticates at site A using the account credentials associated with site A
User clicks on link to partner site B
Site A generates the SSO Assertion for site B using site B's pre-determined federation identifier
Site A uses the http POST method to post the SSO Assertion to site B
Site B validates and verifies the SSO Assertion
User is “signed-on” to site B with site B's federated identifier

Using the Simple-Sign binding significantly simplified the development effort as XMLDSIG is one of the more complicated parts of SAML. As more tools for XMLDSIG become available this will be less and less of a barrier to adoption.

Tags: SAML, AOL, SSO

Wednesday @ IIW 2007

2007-05-17T19:54:00.000-04:00

Thankfully Wed. was not quite so intense, at least for me. The main items of interest for me were a review of Pythia (a reputation system that Phil Windley has been working on), the results of the OSIS interop event, and a discussion about user experience and identity.

Pythia
Phil Windley lead a session on the reputation system (pythia) he's been working on with his graduate students over the last year and a half. The system is based on evaluating transactions between identities. Reputation scores are calculated on a “personal” basis meaning that I can define my own ruleset for calculating reputation that might be different than someone else's ruleset. This, I think, is important because it allows me to value the information I receive about another identity according to my own view of what's important. For example, just because an identity has a great reputation within the drug culture doesn't mean that I want to ascribe a high reputation to them. Reputations are very contextual and I ascribe different levels of value to the different contexts.

In a very concrete example, there was a fair amount of discussion by relying party implementors (both during and after the session) about how to get transaction data (i.e. initial reputation) when a new identifier shows up at their site. The basic question being, is there a way for a relying party to know whether they can “trust” the 3rd party OpenID to be a genuine user. If there was a way to convey transaction data such identifier creation date, date of last use, number of “publish” transactions (meaning blog posts, comments, etc) then RPs could make a much better decision on whether to just let the identifier use their site, or whether they need to do some additional “verification” of the user. In this specific case there is immediate value in identity providers providing some additional attributes about the identifier that relying parties can use to make business decisions. For OpenID this probably means adoption of the Attribute Exchange extension or some additions to SREG.

OSIS interop event
I didn't participate in the OSIS event but was interested in the issues that arose from the event. Being an “outsider” it seems that while a number of issues were found, over all the event was a success. I think a next step is to get more RP's and IdP's involved especially where RP's are bridging identity meta-systems. Things like namespace mismatches, claim mismatches, and certificates are small hurdles that can easily be fixed.

User Experience
This was a very interesting discussion as it did not focus on computer user experience and UI for interacting online. Instead it was much more about how people use identity in the offline world and how does that map into the online world. One of the interesting points to me is that in the offline world, there is a lot of context available as part of the interaction. These could be visual clues (body language, facial expressions, etc), auditory clues (tone of voice, distance from sound, etc), olfactory clues (smell, etc) and the list goes on. In online social interactions much of this additional context is lost and hence a “distance” in the communication is created. This “distance”, or incompleteness in the context, causes some to feel safe to say anything and others to hold back and mask themselves. As more transactions and social interactions move online, it will be increasingly important for consumers to understand these dynamics. A more complete summary will likely be appearing on Heather's blog.

Tags: iiw2007, Reputation, OSIS, Offline Identity

Tuesday @ IIW 2007

2007-05-16T19:57:00.000-04:00

Tuesday was a very full day at IIW. The sessions I attended are listed below with a brief summary.

AOL OpenAuth -- Overview
Srinivas Lingutla from AOL gave an overview of the AOL OpenAuth API's and discussed the differences between the OpenAuth capabilities and existing OpenID authentication. The key additions of OpenAuth are the ability to retrieve a “security token” that represents the authentication and can be used in a back-channel way with other AOL services (e.g. instant messaging), and the consent model that is structured around the use of the “security token”.

HTTP binding for identity web services
This discussion was intended to gage interest in a standard framework for invoking identity based web services using HTTP as the core binding. The focus being support of browser based applications that make use of AJAX and XSS. The session was not well attended so the group present ended up covering many different issues relating to HTTP based invocation of services. John Panzer from AOL discussed some work he's done extending the HTTP support for authentication and authorization to support authentication use of ATOM/APP interfaces. There was some consensus that for REST based API's extending the existing HTTP mechanisms is the best solution. For AJAX based applications, this method does not work well so another method is required. I discussed the simple framework that AOL has defined for its Open Services APIs (e.g. Web Instant Messaging). We also discussed a couple of different invocation models that can be used (front-channel based vs back-channel based) with HTTP.

Rich Client Authentication
In this group we discussed the issues around allowing device specific applications (i.e. not a browser) to authenticate the user and then invoke identity based web services on the user's behalf. From the client developer perspective, the general consensus was that they didn't want to deal with implementing this and would rather the environment provide a consistent API that could authenticate the user and return the appropriate token. Of course this sort of just pushes the problem to a different layer. One idea was to look at OSIS and Cardspace as possible client side systems that could be used to do the authentication though this requires the user to adopt a new model of authentication. It is not clear to me how long that sort of user “training” is going to take.

Another aspect of client authentication is the desire to provision the authentication credentials in such a way that they are specific to the device. This way if they are compromised, they are not valid outside the context of the device. One solution here would be to use PKI provisioned through some “installation/setup” step. What that would be was not discussed, though one could use the Liberty Alliance Advanced Client specifications if willing to implement SOAP web services.

OpenID Token Exchange extension
Srinivas Lingutla also did a session on a proposed extension to OpenID that will allow relying parties (RP) to request an authentication token from the OpenID Provider (OP) at the time of authentication. The token can then be used to access identity based web services. AOL has implemented this proposed extension and demoed it during the “speed geeking” session on Monday by using an AOL OpenID to launch a buddylist using the AOL Web IM APIs. There were a number of questions around how to support different token types (simple support already present in the proposed extension), and whether some level of application id (or provider id) is required. The next steps include evaluating the other related proposed extensions and seeing if these can be combined into a single extension to support token request and validation. The proposed extension should be posted to the OpenID list/wiki in the next week or so.

What's broken with OpenID 2.0
Dick Hardt led a session on what is broken with the existing OpenID 2.0 spec. I'm sure the details will be appearing on his blog in the near future. The session of course grew beyond just what is broken to business issues and next generation feature requests. It was a very lively discussion. The “really broken” things were tackled during sessions on Wed. At the closing session on Wed. Dick promised that the 2.0 specification would be ready “real soon now”.

Tags: iiw2007, OpenAuth, OpenID

Identity issues at IIW 2007

2007-05-15T09:57:00.000-04:00

Something “new” happened at IIW 2007 yesterday. Instead of the normal “state-of-identity” talks and “introduction to the issues”, Monday afternoon focused around “speed geeking” and collective identity issues. We divided into groups and each group came up with a set of issues that they felt were important. Kaliya collected all the different issues/questions into a mind map (picture of it came be found here). Other summaries can be found here and here.

Of noticeable interest to me was the commonality of a lot of the questions/issues.

privacy
trust
reputation
delegation
user experience
interoperability between identity systems
identity relationships (parental controls was brought up and not by me:) )
and the list goes on

These issues are at a different level that just figuring out how the technology will work to do SSO or authentication. It should be a good conference.

Tags: iiw2007

Technology convergence or seamless integration?

2007-05-09T09:33:00.000-04:00

A while ago I wrote that users want convergence not interoperability. I still hold that this is true, however “convergence” in this case, is “convergence of the user experience” not necessarily the technology. Paul describes the issues very well in his recent post. For users, the experience has to be that using one identity meta-system is all that is necessary to interact with the entire set of services on the web. Forcing a user to know about which meta-system is needed for which online services will never succeed. This means that the industry has to solve the problem somehow “under the covers”.

I applaud Sun's entry into the OpenID space. However, I disagree with some that this will lead to technological convergence. The existing meta-systems are too entrenched in their existing deployments to change to something new. Some believe that convergence will come through domination of a single protocol, but I have a hard time excepting that. So that leaves determining how to interoperate between the different identity meta-systems.

I don't think this is unsolvable but it will likely NOT be simple. There are issues with token exchange, token transformation, provider discovery, etc. With a number of good choices for back-channel web services (WS-*, ID-WSF), front-channel communication (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...), and SSO (OpenID, SAML, Cardspace, WS-Fed, ID-WSF, ...) it seems the time has come for the industry to slow down the spec development work and instead focus on seamless interoperability.

Here are some starting use cases...

User uses Cardspace to authenticate to a picture services that uses ID-WSF with it's billing partner(s)
User authenticates with her college library using SAML and then wants to SSO into zooomr.com
User users OpenID to sign in to their favorite hiking site which wants to display their buddy list as part of the site experience

Tags: Convergence, Interoperability, OpenID, SAML, ID-WSF

Identity Meta-System SSO

2007-04-30T16:55:00.000-04:00

In his entry “OpenID bootstrap to ID-WSF”, Paul describes the results of a very interesting IOS session in Brussels. As he outlines, the bootstrapping possibilities are pretty straight forward. An interesting point of the second option is that the RP would need to know how to obtain the appropriate security token in order to invoke the Discovery Service (DS) as defined in the publicly available DS-EPR. In the OpenID case, the OpenID “assertion” would need to be exchanged for the appropriate token used to invoke the Liberty DS service (in most cases a SAMLv2 assertion).

It's this token exchange mechanism that I find intriguing. Does it work both ways? Can I exchange a SAMLv2 Assertion for an OpenID “assertion”? This seems doable if the user is using a single IdP that “speaks” all the identity protocols. With this kind of a deployment model, the IdP can use browser cookies and other mechanisms to maintain the authentication session of the user. An example flow could be...

User visits RP-A which only supports SAMLv2
User's browser has a stored cookie identifying the SAML IdP to use (existing SAML IdP discovery mechanism)
RP-A re-directs the user's browser to the IdP to authenticate via the AuthnRequest
User authentications and the IdP sets authentication state cookies in the user's browser
The IdP re-directs the user's browser back to RP-A passing the AuthnResponse
User is not authenticated at RP-A
User now loads RP-B which only supports OpenID
User's browser has a stored cookie identifying the last OpenID used with RP-B
RP-B invokes a check_immediate with the OP resolved via OpenID discovery (in this case the same IdP)
The check_immediate re-directs the user's browser such that the IdP can validate the user's authenticated session
The IdP now verifies that there is a previously established federation between the OpenID and SAML identifier
If the federation exists, then the IdP can return the OpenID authenticated response

This would allow seamless SSO between different front-channel identity systems, though it is dependent on “identifier federation” at the IdP. However, if the IdP's are not the same, it should still be possible, but more complicated, as the user's identity would need to be federated across the involved IdP's.

Tags: Identity, OpenID, SAML, SSO, metasystem

A knife... a real knife... magnetized!

2007-04-23T16:48:00.000-04:00

To anyone familiar with the Tray Table blog, it is certainly no surprise that a certain unnamed individual was once again traveling in 1st class. However, just a metal knife in business class? Boring... Mine were magnetized!

Not sure what caused the magnetism. Feel free to post theories in the comments.

AOL releases OpenAuth

2007-04-16T19:40:00.000-04:00

As has been blogged by Praveen Alavilli and John Panzer, today AOL released a set of http-rpc based API's for authenticating AOL identities and leveraging that authentication to access AOL services. These API's fill a niche in the existing http based web protocols by supporting the concept of authenticated service access and user consent. As many web based applications move to an AJAX model, being able to expose identity based services in a user-centric way becomes very important. Hence the importance on user consent for access to a user's data by a 3rd party application.

There are a lot of similarities in the identity processing model between the AOL OpenAuth API's and the Liberty Alliance ID-WSF SOAP based framework (authentication tokens and multi-party transactions to name a few). The similarities are intentional. The goal has been to leverage the work done by the Liberty Alliance and other internet standards organizations, and apply it to the http-rpc space for which till now there hasn't been a “good” solution. While these API's only support AOL services, the model is extensible to other protocols (as Praveen mentions in regards to an extension to OpenID).

The basics for web developers are...

Provisioning

At runtime

requires both authentication and consent from the user before returning the authentication token

requires user consent (can be remembered) before returning requested data

Much more detailed documentation is available at http://dev.aol.com/openauth.

Full disclosure: I work for AOL but not directly as part of the Authentication team.

Tags: Identity, AOL, OpenAuth, OpenID, Liberty Alliance, ID-WSF

Spring Blossoms

2007-04-15T17:35:00.000-04:00

When it is a Phish

2007-04-11T12:59:00.000-04:00

So after my experience with getting a valid notification from eBay (thanks again eBay), I received the following email supposedly from PayPal.

This one was immediately suspicious. For one, the href for the URL was a dotted quad (85.234.150.131). Two, the “whois” entry wasn't in anyway associated with PayPal.

OrgName: RIPE Network Coordination Centre
OrgID: RIPE
Address: P.O. Box 10096
City: Amsterdam
StateProv:
PostalCode: 1001EB
Country: NL

ReferralServer: whois://whois.ripe.net:43

...

% Information related to '85.234.128.0/19AS29550'

route: 85.234.128.0/19
descr: PH-Network Europe, operated by Euroconnex Networks LLP
origin: AS29550
remarks: *********************************************
remarks: For Peering and more info: www.euroconnex.net
remarks: *********************************************
mnt-by: POUNDHOST
source: RIPE # Filtered

And three, the email was not sent to the email address associated with my PayPal account.

The rest of the email looked pretty legit however, and after my experience of the previous week... I had to look closely to file this in the “scam” folder. I have to wonder if this email is in any way related to the credit card fraud of the previous week.

Tags: Phishing, eBay, PayPal

Happy Easter!

2007-04-08T07:12:00.000-04:00

"He is risen!" ... "He is risen indeed!" <><

When it's not a Phish

2007-04-06T21:30:00.000-04:00

On March 29 I received the following email from eBay (I left out the “boiler plate” text regarding how to protect yourself from fraud).

My first thought was another clever phishing scheme as I don't have a credit card on file with eBay other than my PayPal account. So I looked through the email for links or other telltale signs that would indicate a phish. I couldn't find anything so I went to eBay and logged in (not via the email of course). There were the same two emails in my eBay “inbox”. I checked my account at eBay and everything looked fine. I then checked my associated PayPal account and there were no purchases via that account. Next step was to check my credit card balance.

Hmm... there on my activity statement was a charge from snapfish.com. The immediate red lights started whirring as I don't have a snapfish account. So off to the hassle of calling the credit card company, snapfish.com etc. The result of these calls was to watch my credit card account (the first fraudulent charge was $1.33). The following day there were two more fraudulent charges from snapfish.com ($2.90 and $41.65 respectively). Now back to the phone to remove these charges from my bill, cancel the credit card and get a new card issued with a new number. The biggest hassle being finding all the companies that have re-occuring charges against that card. Yet another thing to keep track of in the event this happens again.

A BIG thank you to eBay for sending this email and helping me catch the fraud right from the start. Needless to say this experience has not been pleasant, including monitoring of online credit card statements while on vacation this week. This is my first experience with this sort of fraud and I don't hope to repeat the process anytime soon:)

Tags: Fraud, Credit Card, Phishing

Identity Relationships: User vs Service Provider

2007-03-23T11:41:00.000-04:00

There has been a significant amount of discussion and work (People Service, XFN, and FOAF to name a few) around the concept of managing personal or social relationships. These relationships are managed from a user-centric perspective and are really a one-to-many relationship between the user and the identities being managed. This allows the identity of the user to be implied in regards to the other identities and groups (e.g. it is my buddy list). The group structure provides a form of role classification that can then be leveraged for permissions and access control among other things.

However, managing relationships between identities at the service level is a little different. For a service provider the relationship is not one-to-many but rather many-to-many. For example, a hospital will want to manage which patients are assigned to which doctors. A doctor can have many patients and a patient might have many doctors. The existing social relationship mechanisms don't really fit this model as these relationships are defined from a service provider centric perspective. The hospital manages the relationships not the user; though the user is free to leave one doctor and move to another.

Where social relationships tend to be defined in a uni-directional manner (from the user to the other identity), service based relationships are often bi-directional. I don't see this as a problem as it is rather easy to model and implement. However, it is important to distinguish between these two kinds of relationships.

Tags: Identity Relationship, People Service, Social Networks

How DST cost me $5

2007-03-19T14:40:00.000-04:00

So in the US we started daylight savings time (DST) three weeks early. I'm sure most of you received the wonderful emails from the IT department that outlook entries would be tenuous for the weeks between March 11 and April 1. I figured I'd just have a few meetings that were messed up and nothing major.

However, after returning from a Liberty Alliance TEG meeting in Ipswich, UK, I got a rude awakening. I did the normal airport procedures and paid my parking fee in the terminal using the "pay-and-go" ticket I had received when entering the parking lot 7 days earlier. The parking receipt is below. Notice that the payment time is 16:25pm.

I then walked to Daily Garage 1 (about 5-8 minutes), put my stuff in my car and proceeded to the parking lot exit. Normally, you just put in your ticket and it raises the gate and off you go. Not so this time. I received a screen on the monitor stating that the "grace period" (the time between paying in the terminal and exiting the parking lot; around 45 minutes) had expired and I needed to pay and additional $5 or press the button to speak with someone over the intercom. Without thinking, I just put in my credit card and paid the $5. The receipt for that is below.

Then as I was driving home (in the surprise snow/sleet/ice/rain) I realized that there was no way my approximately 10 minutes between paying in the terminal and exiting the parking lot could have been more than the grace period allowed. The time in the machines must be off. This turns out to be the case. The time on the second receipt is 17:35pm which should be 16:35pm. I'm guessing the machines in the parking lot initially didn't adjust so they were adjusted manually. Then a "software update" came through and adjusted the times again.

Unfortunately, I have no excuse as to why I didn't think this through before paying :(

Provisioning Mobile Applications with SAML

2007-03-14T10:14:00.000-04:00

So earlier this month I described a method that would simplify provisioning a user's identity credentials to a mobile application. This method will work but requires the application provider (e.g. an Instant Messaging service) to be able to send a binary SMS message to the phone to configure the application with the necessary credentials.

A less invasive method would be for the mobile operator and the application provider to federate their identities such that when the user activated an application on the phone, the mobile operator could authenticate the user to the application provider via a SAML assertion. This is not complicated and already supported via the existing SAML protocols. A possible flow could be...

User goes to application provider (Instant Messaging service) web page
Web page asks the user if they want to activate their IM account on their phone
User selects the link to start the process
The web page asks the user to authenticate their Instant Messaging account (if not already authenticated)
After authentication, the web site asks the user for their mobile operator and phone number
One the information is received the web site sends a SMS message to the phone
The user enters the SMS confirmation code to the web site
The web site sends a SAML federation message to the mobile operator providing a pseudonymous identifier and phone number for the user
The mobile operator receives the SAML message and maps the phone number to the user's account and stores the pseudonymous identifier for the IM service

Now when the user activates the IM application on the phone, the phone communicates it's identity to the mobile operator. The mobile operator sends a SAML assertion (containing the pseudonymous identifier) to the IM application to authenticate the user. The user is now authenticated and the IM application can send back any connection information required to complete the IM session.

This model keeps the interactions between the mobile operator host services and external application providers. It also makes it much easier for users to configure their applications because they don't have to enter their credentials into the phone itself. A win-win.

Tags: Identity, Mobile, SAML

Update: In my rush to post this entry I was remiss in pointing out that this solution was discussed over lunch at a Liberty Alliance interim TEG meeting. The other principals in the discussion were Fulup Ar Foll and Alvaro Armenteros.

When phishers get lazy

2007-03-09T09:36:00.000-05:00

So I received this email at one of my email accounts this week. It's not nearly so clever as the one pointed out by Conor here. What I found interesting is that I don't use that email account with eBay and I've never sold anything on eBay. So naturally I was suspicious. I suppose it's just easier for the phishers to swamp the "market" rather than do their homework.

Hmm... I wonder if all those PowerSeller ratings are real?

Tags: Phishing, eBay

Do we really want SSO?

2007-03-07T14:58:00.000-05:00

With the recent flurry of announcements around OpenID the same SSO issues are once again being raised. Kevin Farham documents some of these in his piece on OpenID. Kevin's friend's issues are not around OpenID but rather the whole concept of Single-Sign-On (SSO).

This begs the question, "Do users really want SSO?" Unfortunately, the perception might be scarier than the reality.

"You mean, if someone knows my password they can access all my web sites?"

Well... yes and no (depending on the implementation). However, the reality is that many users have the same password at all/most their sites and so the "hacker" can already get access to all their sites without SSO.

With a good Identity Provider (IdP) and strong authentication, the user should be more secure even though a single authentication event allows access to many sites. In fact, for many users, they expect this within a "proprietary" or "closed" environment ( AOL, Google, Yahoo, MSN, etc). It's extending this SSO concept beyond the "proprietary" environment that "scares" them.

Of course part of the issue is that this kind of "cross-domain" SSO doesn't really exist in the general consumer space. The unknown always breads fear; it's human nature. To overcome this "fear", we need SSO to be common place (known not unknown), and show how SSO is "just-as-secure" as the "money under the mattress" solution.

Tags: SSO, Identity, OpenID

Simplifying Parental Controls

2007-03-05T11:52:00.000-05:00

In his blog entry "Social Engineering" Paul Madsen describes the classic "parental control" problem where the children understand the technology better than the parents:) However, this doesn't have to be the case. I can think of a number of simple solutions.

In my household, all members have their own OS user account (yes, including my 3 1/2 yr old daughter who dutifully types in her password to sign on). This works out great for them and simplifies my life as I don't have to deal with changed desktops pictures, dock apps appearing/disappearing (yes it's a Mac), etc. I highly recommend setting up OS user accounts for individuals (there can be a family one as well if necessary). On the parental control front at the very least it allows you to turn off Administrator rights for certain accounts.

Getting back to a solution.... Once signed in to my OS user account, I could click a widget/gadget/desktop-thingy to generate an assertion to my PS2 or other device authorizing the suspension of parental controls. I suppose that the PS2 could support something like Cardspace, but that seems a little overkill. Remembering the OS account password is not too difficult and should provide the necessary level of assurance as to the subject of the assertion.

Then again, a simple USB fob with appropriate credentials would work as well. Now where did I put that "key" for the TiVo.

Tags: Identity, Parental Controls

Provisioning identity to mobile applications

2007-03-02T09:25:00.000-05:00

Not to long ago I decided to try and set up the instant messaging client on my cell phone. I dutifully went through the painful process of entering my authentication credentials (loginid and password). However, when I got to my password, I couldn't find one of the characters in my password using the phone character entry system. This was rather frustrating and I gave up using the instant messaging client for a while. Later I tried a different account where I knew I could find the characters for the password and the mobile application worked.

This got me thinking that there has to be a better way to provision the identity to the phone for use with mobile applications. One possible process flow would be...

User authenticates to web site of mobile application provider
User enters their phone #, and carrier to the web site
The web site sends a code to the phone
User receives the code and enters it into the web site
The web site generates a unique set of authentication credentials for the phone
The web site sends a binary SMS message to the phone with the mobile application identity configuration
User starts up mobile application and is automatically authenticated

This should all be doable with today's technology. Of course, the next step would be secure provisioning of multiple identities for the device, where the identities are consumable by multiple applications. For this, the Advanced Client work underway in the Liberty Alliance should help.

Tags: Identity, Mobile, Instant Message, Liberty Alliance

Where's the ice?

2007-02-25T12:05:00.000-05:00

Unfortunately, predicting the weather here in VA is a bit of a trick. Instead of 1/4" to 1/2" of ice, we ended up with 7+" of snow:)

No ads for kids

2007-02-23T09:52:00.000-05:00

Consider this for a moment.... My child gets online and goes to google to do some research for a school project. Google senses that the user is a child and does not display any ads (OK, maybe I'm dreaming) or displays child appropriate ads. This kind of claim "under 13" could be tied to an anonymous identifier so that each time my child interacts with a web site, they aren't being tracked and all their actions correlated to build a profile about them (of course there are many ways to do the correlation; using an anonymous identifier just makes it a little harder). The next piece of the puzzle would be for user agents to expose this information directly to the web site through some means.

My one concern is whether "pushing" the claim of "under 13" leaks too much information. Would this enable someone to target my child because they know s/he is "under 13"? However, I fear that if the claim is not "pushed" most web sites would just ignore it and not bother to go check with the appropriate attribute provider. Maybe the only way to solve this is through legislation (any one want to sponsor a "No ads for kids" bill?). Until then Firefox2 + AdBlock Plus is your friend.

I'd be interested to hear if anyone else has ideas or even considers this a significant problem.

OpenID and reputation

2007-02-19T09:48:00.000-05:00

So the news that AOL supports OpenID finally bubbled up to Slashdot. What I found interesting is that most of the slashdot readers focused on the single-sign-on capabilities of OpenID. In doing so, there were a lot of comments regarding the privacy exposure of using a single identifier at many different sites. In fact, some were suggesting that having a unique account at every site is a "good thing". I understand their privacy concerns though that doesn't mean the user has to give up the benefit of SSO. SAML2 solves this problem just fine.

However, what is being missed by most of the slashdot community is that OpenID's are fantastic public personal identifiers. A few astute readers pointed out that in order to build reputation its important to have the same id. Otherwise, how will people realize I'm the same person on multiple sites? OpenID's provide an identifier that I can use so that people will recognize me at multiple locations. Now OpenID's are not the only kind of identifiers that provide this capability; XRI's and any consistent identifier will do the trick.

I found it interesting that while the "identity community" have no problems with the above concepts (if you've made it this far you're probably yawning), there is still a very large technical community that does not understand the ramifications of identity.

One final thought. There should be no reason why my IdP can't provide public personal identifiers in certain instances, pseudonymous identifiers in others, and temporary identifiers with claims in still others.

Tags: Identity, OpenID, Reputation

Users want convergence, not interoperability

2007-02-16T10:20:00.000-05:00

Paul Madsen has a great post today regarding the permutations that must be supported to allow for interoperability between the different identity systems. A meta-system framework is great, but implementing it can be a big problem. Interoperability is a great first step but it can not be the end goal.

Stopping at interoperability has some unfortunate consequences for each of the parties in the identity transactions.

Identity Provider: Must implement multiple protocols. This isn't so bad for IdP's because there are relatively few of them and they can get a fair amount of value for their effort because it means more people will want to use their IdP (why Paul selected ProtectNetwork over AOL).

Relying Party: Must implement multiple protocols based on the services they provide. This is much more invasive because there are a lot more RPs than IdPs. Getting lots of RPs to support multiple protocols will be difficult unless it is made extremely easy through available toolkits. Developers (people?) are inherently lazy and spending time writing the equivalent of a TCP/IP stack by hand is not something they want to do. You can also apply these same consequences to web service providers.

Users: Must have multiple identities from different IdPs and know when to use them. This is the one that will kill the internet identity layer if we don't figure out a way toward better convergence. Here is my reasoning (corrections greatly appreciated)...

Web site will need to implement multiple identity systems in order to take advantage of services available on the web
Supporting multiple identity systems means that the bootstrap problem must be solved (how to exchange my OpenID authentication for a WS-Trust binary security token)
Solving the bootstrapping problem is most easily done at the IdPs
Not all IdPs will support all the necessary bootstrapping mechanisms
Therefore, users will need to have identities at the "right" IdPs in order to use certain web sites
Those web sites will have to figure out how to inform the user that their single-sign-on identifier doesn't work at their site.

As we work toward convergence, we need to be mindful of the impacts on users. If we don't make it easy for them, the coolness of the technology doesn't matter.

Tags: Identity, Convergence, Liberty Alliance, OpenID, Cardspace

OpenID and AOL Consumers

2007-02-15T12:03:00.000-05:00

As has already been noted by John Panzer, Kevin Lawver and others, AOL is providing an OpenID URL for all AOL & AIM members. This enables a significant number of consumers with an OpenID URL. I hope this encourages greater participation amongst existing services on the web. I find that many of the services I want to try out, don't support OpenID and hence I tend not to go through the whole registration process just to see if the site offers the services I'm interested in. Greater participation by relying parties will be key for adoption and use of OpenID by the "mass market".

In the "adoption and use" department... Given that many AOL users will not realize they have an OpenID, it would be great if the help text for "what is an OpenID?" on relying party "login" screens would mention that if you have a LiveJournal or AOL account, you already have an OpenID. This isn't very inclusive so maybe there could be a link ("Do I already have an OpenID?") to a wiki page or something that could be updated as more OpenID Providers become available. This isn't that important for those who explicitly create OpenID's at OpenID providers, but is important for those consumers who have an OpenID by virtual of having an account for other services.

Tags: OpenID, AOL

Valentines Day in VA

2007-02-14T12:30:00.000-05:00

OpenID: Not all Chocolates and Roses

2007-02-13T10:21:00.000-05:00

There has been quite a bit of hype regarding OpenID within that last few weeks. One of the biggest announcements is that Microsoft will work to support OpenID with its Cardspace card selection metaphor. While there are not many details about how this will work, this is still very good news for the OpenID community. There are other major identity players also working to support OpenID for their customers.

I would, however, like to bring some practicality to all this hype. OpenID as an identity system is perfect for the blogosphere and any publicly published content. It provides single-sign-on and auto-correlation across all comments, blog posts, picture galleries, etc that I publish. However, it's the auto-correlation part that causes problems when I'm NOT wanting to operate on the web in a public manner.

There are many tasks I do online that I do not want to ever by public (e.g. my banking site, purchasing history from Amazon, etc). While OpenID provides the single-sign-on benefit I desire even for these kinds of tasks, it also inherently allows for the correlation of my activities by those sites without my consent. This is definitely NOT user-centric.

The problem this creates is that most users will not understand the impact of using a correlatable identifier at all the sites they interact with and will leak privacy information in the process. I do want to note that the OpenID 2.0 draft spec addresses this issue by allowing an interaction method where the user can allow the OpenID Provider (OP) to pick a unique identifier for them. The user will then be known by that identifier at that site. However, my concern is that while this method is supported, it's not getting much traction in the industry.

As OpenID becomes more main stream it will be important for OpenID Providers to address not just the social-web tasks of users, but also the personal tasks of users and provide appropriate privacy protection.

Tags: OpenID, Correlation, Privacy

Social Networking my way

2007-01-03T08:27:00.000-05:00

It seems that I'm not the only one frustrated with the effort and work it takes to maintain relationships between my family and friends at social networking sites. Today on Slashdot there is an article on "Social Network Fatigue Coming?" which references Steve O'Hear's blog. A few weeks ago in a similar blog entry Paul Madsen described how the Liberty Alliance People Service can help solve this sort of fatigue using published standard protocols.

I have to admit that there have been a number of sites I've been tempted to try out and yet when I consider that I will have to create an account, invite my family and friends, and have them create accounts before the site becomes useful... I just kill the page and decide I don't really need that service.

If the social networking services would adopt standards so that I could use a single account and manage my social relationships in one place I would be much more likely to use their services (and pay for them if they provided the right value).

Tags: Liberty Alliance, People Service, social networks