OpenID Foundation Elections in Progress

The election of two new Community Board members for the OpenID Foundation is now in progress. The current list of candidates includes:

• Axel Nennker
• George Fletcher <-- That's me :)
  
• Greg Keegstra
• David Marceau
• Patrice Vuillard
• Sébastien Brault
• Yosef Vuillard

If you are an OpenID Foundation member, please log into the OpenID Foundation and exercise your right vote! You can easily sign up for an individual membership for only $25 US.

I'm excited about OpenID's future with the release of the OpenID Connect implementor's draft specs. This body of work is important for moving OpenID from just a federated authentication solution to one that can solve many identity authentication and authorization use cases. These use cases are not limited just to non-risk transactions but can cover higher levels of assurance as well.

Adoption is going to be critical in the next two years and that's one of the reasons I'm running for one of the available board seats. Adoption is more than just OpenID Connect implementations; adoption includes moving beyond low-risk transactions into higher value use cases and really providing convenience and security to consumers. Whether this is a goal that can be accomplished in the next 2 years remains to be seen, but it's a goal worth shooting for.

Of course I'd appreciate your vote!

Facebook Registration Tool

The new Facebook registration service has created quite the "buzz". I have to commend Facebook on doing a great job of making it really simple for sites to manage registrations (just as they did with identity federation). I like the user experience; both for the user and for the integrating site.

However, for relying parties supporting 3rd party identity providers I do have some concerns regarding leveraging the Facebook registration UI for all users.

1. What happens if the user chooses to clear the form and enters new data? If the site requests password data as part of registration for these users using the "

   <code>{"name":"password",   "view":"not_prefilled"}</code>

   " option, when the user comes back to the site, where do they enter their password? How does the site instruct the user that when they come back to the site, they should use the site specific login form, not the Facebook login form?
   
2. For users who choose not to register for Facebook, but do want to access the site, where are their login credentials stored? If the site doesn't request password as part of the registration process, is Facebook asking for authentication credentials and storing them (along with which sites the user has logged into)? From working through the documentation, I believe Facebook handles all authentication (even if not storing the registration data) and provides sites with a UID (unique identifier). Effectively, Facebook is a federated identity provider for all users.
3. Supporting other federated identity providers becomes confusing. The relying party will have to support two registration forms; one for Facebook users and one for other identity providers. For example, I don't see a way for the relying party to use the Facebook registration UI for a user logging in with their Twitter credentials.
   

In the end, for sites that only support Facebook as their external identity provider, this is a great tool. For sites that support identity providers other than Facebook, the benefit is only recognized for Facebook account holders.

Facebook, Registration, Authentication

Congrats Yahoo! OpenID gets another RP

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

OpenID, AOL, Yahoo!, Relying Party

Identity as an Attribute

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

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

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

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

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

Previous posts:

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

Identity, Token, Sharing, Attribute, OAuth, XRD

IIW #9 : Making it all work

If you haven't seen the announcements for the Internet Identity Workshop (IIW) floating around the identity listservs, it's happening Nov. 3-5 at the Computer History Museum. A lot has happened since the last IIW in May and I'm excited about the progress that has been made in the intervening months.

Thinking back to past IIWs it's great to see the progression of topics at IIW from geeky syntax and protocols to solutions and solving the problems from a user's perspective. With the recent developments around "webfinger" and XRD, some of the "glue" pieces are coming together.

I believe the next core issue to tackle in "Making it all work" is the user experience. To date we've been solving the problems mostly from a functionality perspective. However, just being "functional" isn't good enough for the average consumer. We need to make it easy and coherent (not a trivial task). By easy, I don't just mean "there aren't too many clicks" but rather a user experience that proactively helps the user with the tasks they need to perform. There are lots of nuances in the identity space and the average user doesn't grok them, so the technology has to help the user make the "right" decision.

I'm expecting discussions like this to be a key part of IIW #9.

Internet Identity Workshop
Registration

Continuing the discussion...

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

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.

1. 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
2. Alice uploads a GPS track and some photos of a new trail she hiked over the Labor Day weekend.
3. At the conclusion of her upload, hikingtrails.example.com asks Alice if it should notify her friends about her activity.
4. Alice thinks that’s a great idea and agrees.
5. 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”.
6. Now for each of these friends, hikingtrails.example.com has to discover the “notification” service and send it the new activity message.
7. One of Alice’s friends, Bob, only exposes the endpoint and metadata of his “notification” service to a restricted list of people
8. hikingtrails.example.com queries Bob’s discovery service presenting the Alice’s Open Identity Token
9. 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

From the "Feeling rather behind..." department

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 consumer framework for Tiger

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

Clients to the rescue

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

Identity at the SP

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

Identity Meta-System SSO

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

1. User visits RP-A which only supports SAMLv2
2. User's browser has a stored cookie identifying the SAML IdP to use (existing SAML IdP discovery mechanism)
3. RP-A re-directs the user's browser to the IdP to authenticate via the AuthnRequest
4. User authentications and the IdP sets authentication state cookies in the user's browser
5. The IdP re-directs the user's browser back to RP-A passing the AuthnResponse
6. User is not authenticated at RP-A
7. User now loads RP-B which only supports OpenID
8. User's browser has a stored cookie identifying the last OpenID used with RP-B
9. RP-B invokes a check_immediate with the OP resolved via OpenID discovery (in this case the same IdP)
10. The check_immediate re-directs the user's browser such that the IdP can validate the user's authenticated session
11. The IdP now verifies that there is a previously established federation between the OpenID and SAML identifier
12. 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

AOL releases OpenAuth

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

1. Get a provider id (called a developer key)


• At runtime

2. Request an authentication token

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

3. Invoke AOL identity based service

• 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

Identity Relationships: User vs Service Provider

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

Provisioning Mobile Applications with SAML

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

1. User goes to application provider (Instant Messaging service) web page
2. Web page asks the user if they want to activate their IM account on their phone
3. User selects the link to start the process
4. The web page asks the user to authenticate their Instant Messaging account (if not already authenticated)
5. After authentication, the web site asks the user for their mobile operator and phone number
6. One the information is received the web site sends a SMS message to the phone
7. The user enters the SMS confirmation code to the web site
8. The web site sends a SAML federation message to the mobile operator providing a pseudonymous identifier and phone number for the user
9. 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.

Do we really want SSO?

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

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

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

1. User authenticates to web site of mobile application provider
2. User enters their phone #, and carrier to the web site
3. The web site sends a code to the phone
4. User receives the code and enters it into the web site
5. The web site generates a unique set of authentication credentials for the phone
6. The web site sends a binary SMS message to the phone with the mobile application identity configuration
7. 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

OpenID and reputation

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

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