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

How DST cost me $5

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

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.

When phishers get lazy

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?

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