The right way to go about it

On my way to go watch bad American Infomercials last week, I spent a lot of time in the airport, in this case the Vancouver airport. The usual time-honored geek-at-an-airport rituals were observed: the scurrying around with lowered head, looking for the elusive power outlet behind a seat, the plugging in of as many gadgets as the outlets allow, and then the groan that comes forth as you open your browser to see how much you get to pay for internet access for today’s airport tenure.

Many of you have probably had the airport wifi experience. You get online just enough to be given options for payment — 1 hour, 1 day, 1 month, or ongoing support. If you already have an account with the wifi provider, you are off to the races. If not, you have to (1) Register. (2) Pay. (3) Get a username and password that you will never remember. (4) Use it once. My favorite at SFO was always the fact that the usernames stuck around but that you (or at least I) couldn’t recover the password, so you had to end up appending numbers to the end of your usual username choice to get a new account for every visit. If you were optimistic enough to pay for multiple visits at once, well good luck getting in on the second visit. The experience is uniformly time-consuming and frustrating.

And so, as I started my browser and saw that Wifi was managed by Telus (not Bell, my own provider), I braced myself. Suddenly — at the bottom of the page, I saw the following:

Canadian wireless providers have created a provider centric wireless service offering, where instead of having to give your information to whatever provider happens to run the hotspot, you can alternatively authenticate to a wireless provider you already have a relationship with, and and do the deal there. Once negotiated, your provider deals with payment on your behalf, your internet access charge shows up on your monthly bill, and you gain access to Vancouver airport wireless service, never having had to pull out your credit card or fill in a registration form.

Yes!!! This is exactly the experience that I want to see! Instead of having to hand over my data & credit info to someone I had no reason to trust, I instead chose an entity with whom I already had a relationship to act on my behalf. The transaction was easier for me, and I assume profitable both for Bell and for Telus. Wins, all around.

This is what needs to happen in general on the internet. By whatever means. I of course have my technology preferences, but it is the end result that matters the most.

Alrighty then – let’s talk roles.

In my post on user context decisions in the Enterprise, I built on a foundation that perhaps should have been better defined before drawing conclusions. A few people noticed it, and I think they make great points — so let’s step away from the fancy schmancy terms and look at [my conception of] the underlying issue.

Here is my problem with current technical definitions/applications of roles. In most organization, roles are expected to be true of a given person 100% of the time. Jenny is *always* a “production accountant level II” if that role is present in her profile.

Roles are indeed in the domain of the “identity weenie” — but alone, roles are nothing but a maintenance nightmare – they exist to be leveraged. Rules on the other hand, are the problem of the “authorization weenie” and are written (for example) as a WAM policy that says “All Production Accountant Level II resources can access the accounting SharePoint instance”. When you collect roles into a profile and collect rules into a policy and then evaluate for a given user, resource, and point in time, what you eventually get is an entitlement, ie “Jenny should get into the accounting SharePoint instance”. The goal is to have transitive logic between roles and rules, such that two different people can take on the two different statements being made. Jenny’s Manager can authoritatively state (through a workflow approval) that Jenny is indeed a production accountant. The owner of the Accounting Sharepoint instance can authoritatively state (through an authorization policy) that all production accountants should have access to their site.

This is, of course, just my interpretation of the verbage. Heaven knows there are many many other interpretations out there, I could be waay behind the times. Still, the basic logic I’ve just outlined forms (I believe) a simplistic basis for most identity projects out there. All of it is based on the idea that whatever set of roles are present for a given account at a given time are all simultaneously true.

What happens when the system detects the static presence of two conflicting roles? What happens if one role is “truer” than another at some point in time?

There is no simple way to say that John is a broker 100% of the time, but 50% of the time he represents Client A and only Client A, and the other 50% he solely represents Client B. There is no way to represent mutual exclusivity of roles in a single user profile (that I’m aware of).

In the case where two roles are assigned to the same person, but should never be simultaneously applicable, Enterprises have limited choices. If, however, there is a layer in between the consumer and the provider that lets you mask roles based on user-chosen context, in my mind this problem goes away. I don’t see how you can do it without the user part — but perhaps I’m just not thinking hard enough :)

I hope I’ve now managed to dig myself in sufficiently deep that pretty well anyone will be able to take potshots — have fun :)

Making it Work

Well, now that we’ve had some time in the clouds (so to speak), I feel like getting back to earthbound reality. I’ve been playing for a while with an interesting beta offering — an Identity Provider called SlashID.

SlashID calls itself an ‘untrusted’ provider – my interpretation of that is, you don’t have to trust that SlashID will accidentally or purposefully betray your data to anyone – because they store that data in encrypted format, with your user password as the key, and the unencrypted key is never in reach of SlashID servers. Similar to a service like HushMail, this should mean that SlashID is incapable of abuse or negligence (other than losing or corrupting your data en masse, I suppose).

Of course, there still is trust needed – you have to trust their code to not contain backdoors, legally coerced hacks, and so on (queue the evil music reminding us of HushMail’s recent issues). There is an excellent response to this and other issues (such as the relationship between SlashID and OAuth, or OpenID Security) on the SlashID blog, if you’re interested.

SlashID uses its own protocol specification, and they have a lot of information available on why they’ve gone in this direction, but what I like about this company, is that this is not a company who is trying to blindly make a business out of a technology — they understand the service they want to provide, and the value proposition for that service — and they are leveraging the technology that they feel is going to get them to their business objectives. I feel like this is a healthy, healthy approach.

I’ve got the SlashID Relying Party code running on one of my test blogs right now, so if you want to try out the service there, be my guest. One day, when I move my blog to my own domain, I’ll enable my blog as a permanent SlashID client. You need to register for a user account at SlashID before you can authenticate; once that is done, you can use your credentials at login screens where you see this logo: Just remember — these guys have NO way to get your account back if you forget your password, so make sure it is recoverable by you, yourself.

I think that one of the biggest problems facing SlashID right now is identical to that of any company trying to offer mainstream products or services based on crypto: how do you make both the general user and the RP app owner understand the underlying paradigm well enough to make secure decisions and understand the consequences of their decisions, while still providing a user experience that isn’t too terrifying?

I’ve had a great time working with the SlashID guys on this – they are responsive and very interested in feedback, so if you have any to pass on and aren’t sure how to communicate it, drop me a line and I’ll make sure to pass it on.

Since you all probably won’t want to run off and register your own website while checking this stuff out, let me know if you’d like to see/play with either my RP setup at SlashID or on my blog — otherwise I’ll end off with a few screenshots of what it takes to set up a relying party with this technology (click on the image to get a bigger version)…

Configuring Attributes passed from IdP to RP at the IdP:

Configuring Crypto at the RP, via a WordPress Plugin:

Where does Philosophy end and Problem Solving begin?

This is my response to a current blogosphere conversation on user centricity in the Enterprise, started by Patrick and carried on by myself, Nishant, Johannes, and Matt

I have a lot of passion about the tools I choose to work with. I believe in working on and with tools that further us as a democratic society. I believe in using tools constructed such that the easiest way to implement are ways that by default tend towards preservation of user privacy, minimization of data retention, and smallest attack surface.

I also, however, believe that the tool has to fit the task at hand. Part of choosing a tool in an Enterprise is deciding whether the tool is capable of adherence to internal policies – this may include privacy controls, platform support, cost, improvement in end-user productivity, regulatory compliance, and so on.

If you take all of the tools out there that have had the ‘user-centric’ tag associated with them, and try to shoehorn any one of them into an Enterprise based on the moniker alone, I will laugh at you, as one IT professional to another. Really, I will. The idea that ‘user-centric’ has to mean anything at all in an Enterprise context, just makes no sense. My advice to Enterprise decision-makers is simple: take the tools and find out if there is a story that those tools can tell that brings value to the organization. If the story is there, adopt the tool. If the story isn’t there, walk away. Whether or not the marketing term applies is, to me, utterly inconsequential.

I can tell you a story for OpenID in the Enterprise. I can tell you a story for the Identity Metasystem in the Enterprise. I can tell you a story about Liberty in the Enterprise. If any of the stories match your goals for your business, fantastic. If they don’t – no problem. There are a large number of stories, but there are infinitely more business scenarios to match them to.

If you try to tell me that using a tool such as the Identity Metasystem to accomplish something other than a user-centric philosophy is wrong, I will also laugh at you. If these tools were built properly, the philosophy should be inherent, not resultant – in other words, you should get user centricity as part and parcel, the kernel of the technology that makes it user-centric shouldn’t be subtractable — but user centricity doesn’t have to be the actual problem that is solved along the way.

I would like to see Enterprises adopt technologies such as the Identity Metasystem for no other reason than because it helps their business to succeed. The fact that as a welcome corollary we lay the plumbing for users to also have greater control in other aspects of their internet life, and for future developers and/or administrators to perhaps begin to be able to architect their applications around a claims-based security architecture, thereby perhaps one day furthering the beliefs I spoke about at the beginning of this entry — well that’s just gravy. I feel it is possible that we can get to a place where such a thing just might work, which gives me faith that maybe we can begin an organic upwards security spiral, with identity at the center and acting as a foundation and inspiration for other areas of this industry.

User-Centric Implications

I’m very excited to see Patrick Harding from Ping is blogging – he’s always got great conversation starters.

I’d like to continue a conversation which Patrick started with his entry entitled “User-Centric Identity Within the Enterprise” – Patrick made the following points about user centric identity, and stated that he is trying to go past technology issues, to underlying definitions, and relate those definitions back to an Enterprise employee world. You need to read the whole article – don’t depend on the bullets, but this is the gist:

  • User centric implies user control
  • User centric implies self asserted information
  • User centric implies user choice of identity provider
  • User centric implies simplicity and SSO
  • User centric implies identity for Web 2,0
  • User centric implies user privacy

I suppose the question is what it exactly it means for ‘user centric’ to imply something. Obviously use of a user centric technology is not limited in any of the ways that Patrick has described – at least with information cards, it is perfectly possible to build a tightly controlled set of RPs that are locked down to a single Identity provider serving managed data only, and heaven knows that its possible in general to use user centric technology to create things that aren’t simple, don’t do SSO, have nothing to do with Web 2.0, and in no way respect the privacy of users. But to run with Patrick’s idea of looking at the value of popular user centric tenets with respect to the Enterprise, I have a few thoughts.

  • User Control
    • Perhaps it is true that most companies will be doing the choosing with respect to what data is sent where — however, the same features that aid user control also could serve an Enterprise belief in transparency.
  • Self-Asserted Information
    • Self-asserted information is already commonly used in Enterprises – it is just called “profile self-service”. Most Enterprises I visit are very busy trying to set up interfaces for employees to self-assert address changes, name changes, and so on in order to reduce help desk overhead, so I’d have to say that there is a place in the Enterprise for this concept.

Hopefully this is a useful and construction addition to the conversation – I look forward to many more along this vein now that Patrick is around.

Breaking the TOS before you even start

Today I actually for just ONE single minute paused to seriously contemplate the consequences of lying on a Web 2.0 registration form.

The site that caused this momentary lapse in common sense was Facebook:

Facebook DOB error

It turns out that I don’t want to supply my correct date of birth to Facebook. I would have been more than happy to assert that I was over 13 — but a complete DOB is just too much information. And yet — if I lie, I’m violating the terms of service:

Facebook: “…you agree to (a) provide accurate, current and complete information about you as may be prompted by any registration forms on the Site (“Registration Data”); (b) maintain the security of your password and identification; (c) maintain and promptly update the Registration Data, and any other information you provide to Company, to keep it accurate, current and complete;”

I started wondering – does this mean I can’t register a pseudonym on Facebook? Am I only legally able to register my “real” name? And if this is the case, what about all the other sites that I have pseudonymous names registered at?

Who knows, IASNAL (I am *so* not a lawyer) but if you were to ask me, it seems like the majority of accounts I have registered at the following sites are already in violation of the TOS:

Flickr: “…provide true, accurate, current and complete information about yourself as prompted by the Service’s registration form”

Multiply: “…provide certain limited information about you as prompted to do so by the Service (such information to be current, complete and accurate)”

Slashdot: “personally provide true, accurate, current and complete information on the SourceForge Site’s registration form (collectively, the “Registration Data”) and (2) maintain and promptly update the Registration Data as necessary to keep it true, accurate, current and complete. If, after investigation, SourceForge has reasonable grounds to suspect that any user’s information is untrue, inaccurate, not current or incomplete, SourceForge may suspend or terminate that user’s account and prohibit any and all current or future use of the SourceForge Sites (or any portion thereof) by that user other than as expressly provided herein.”

Google Mail: “5.1 In order to access certain Services, you may be required to provide information about yourself (such as identification or contact details) as part of the registration process for the Service, or as part of your continued use of the Services. You agree that any registration information you give to Google will always be accurate, correct and up to date.”

One site where I chose not to lie (and see no point in a pseudonymous account), is LinkedIn. I gave correct naming information to LinkedIn, but was not required to enter a date of birth, and so had no reason to pause during registration. I find it interesting that sites like Slashdot and sites like Facebook or LinkedIn have similar terms of use, even when usage is obviously quite different.

What do you all think? Do these TOS’s technically ban pseudonyms but not enforce? Does it matter? Oh, and if I ever remember to get around to finishing that Facebook registration, I hope to be at least a hundred and two years old, don’t be shocked…

Mystery Solved; Questions Abound

I must say – I feel privileged to have learned a lesson today.

At this year’s Catalyst conference, I saw Jonathan Schwartz speak at the Sun hospitality suite. Jonathan’s vision of the future is that one day, systems he deems as “uninteresting” such as e-mail systems, ERP systems, and such will be outsourced to Web 2.0 darling companies, who will host these boring but necessary functions, so that companies can focus on the sexy stuff.

The exact logistics of such a strategy were left to everyone’s imagination, although what was implied was that such a strategy would result in fewer servers being maintained, and fewer IT staff to do the maintaining. In other words, a CxO’s wildest dream.

Risk & Liability involved with such a strategy were not discussed.

Now – as it turns out, I happen to be a student of Mr. Schwartz’s methodology, on a very small scale. As someone who did not wish to pay for or maintain a server from which to publish my personal blog, I contracted with a Web 2.0 darling company called to host my blog alongside hundreds of thousands of others. It is and was a steal of a deal — they maintain the machines & the software, and I get to blog for free!

Today, however, I feel that I may have encountered the fly in Mr. Schwartz’s enthusiastic ointment. As you may have seen from my last blog entry, I was the subject of some syndication feed shenanigans this afternoon. Apparently so were a lot of other people.

During the course of administering their many separate hosted accounts, the staff installed software that mixed RSS feeds up for some unknown number of blog accounts, resulting in content from one persons’ blog being published under the name of someone else.

I can’t help but wonder – did somebody get my content? Was it a swap, or an off-by-one? I don’t suppose I’ll ever know.

How about a quick post-mortem cost assessment based on the following factors:

  1. Probability of loss of reputation due to my identity being associated with someone else’s content or vice versa.
  2. Probability of loss of income or other tangible asset due to either my identity being associated with someone else’s content or vice versa.

In my case, there was little cost. A few people might have come to erroneous conclusions about my personal life – but for the most part, my reputation and income stream were not affected. Additionally, it is technically possible that a bunch of strangers saw my content and assumed it belonged to someone else. Heh, more power to them if they were able to make sense of it.

But. What if this wasn’t my personal blog affected. What if this was, instead, my corporate ERP system affected? Or my corporate Email system? What happens when a hosting company mixes up the account identifiers of two different companies’ finanical accounts? What could the possible cost be, in both reputation and income, of your company’s confidential data being temporarily disclosed to another company’s users? Or of your company’s identity being temporarily associated with somebody else’s confidential data?

Can’t happen you say? Surely those kinds of hosting companies would be more careful? Yeah. You keep on believing that. It will be impossible until the day it happens. Then it will be irreversible.

Here be dragons. Mark my words.

Not mine

Information Cards @ Catalyst 2007


there will be an Information Card Interop Event at the Burton Group’s Catalyst 2007 conference in San Francisco on Wednesday June 27, 2007 from 6 – 9:30pm.


all of the cool kids from the world of information cards will be there, and ready to show each other, the Burton analysts, and most importantly – YOU, the folks who might just want to use this technology to solve a few important problems, just what this technology can do – not in theory, but in demonstrable practice.


we’ve already started — everyone got together at the IIW conference in Mountain View on May 15, 2007, and started testing combinations – 11 Relying Parties, 7 Identity Providers, and 5 Identity Selectors (also known as Identity Agents) all worked together to see what combinations of 4 different token types, 2 different managed card authentication mechanisms, and 10 different required claims, of varying types.


the Pamela Project is participating in the Interop — please make a point of dropping in to say hi, I’ll be hanging out in the Relying Party section, and I would love to talk to you.

So are you coming out to see us?


The Devilish Details

Mark Dixon is asking what some common success/failure factors might be for Identity Management projects.

To me, talking about success/failure of an IdM project is like talking about success/failure of a home plumbing renovation. Technically the project is a success once the water starts flowing — but the real story is in how long you went before you could take that first shower, how much $$ you had to lavish on the project, and whether you had to rip the drywall out again a week later.

I think the essential problem lies in the fact that IdM tools are built and sold on the strength of their ability to handle common, well-understood business scenarios, but the companies that try to implement such tools are messy conglomerations of systems and process with almost as many exceptions as there are rules.

My experience has been that the companies most likely to get into trouble are:

  • Companies with long & varied histories of mergers & acquisitions.
  • Companies with fractured lines of communication between different provisioning entities.
  • Companies with executives who *think* the business processes are straightforward but don’t take the time to dig any deeper.
  • Companies who are afraid or unable to take action when business process problems become evident during attempts to automate.

My strongest advice for companies starting IdM projects is: know your business processes and survey your repository content & structure to determine conformance to those processes before you try to assign a cost or a length to your project. Otherwise, what’s really happening is that you are giving your IdM project a bad rap – because they are having to perform both a business process audit and a technical implementation of the results all in one go, and when that happens, timelines slip.

Look at the small things – that is what will drag you down. Look at things like identifier life cycles across different systems, like identifier length limitations, especially on legacy systems, look at case sensitivity and encodings (ie Latin-1, UTF-8) of both names and identifiers across systems (especially mail systems, and even if you don’t believe that anyone in your company has a name that uses fancy characters), look at how geographically diverse your AD forest is and understand what the processes for choosing the fileshare that home directories & mailboxes get allocated onto, as well as whether those allocations or other business process decisions depend on departmental or locational data. If they do depend on departmental or locational data, is that data actually present in reliable format and in a consistent way from a data repository? This last question is CRITICAL – because if the only way a user gets placed on the right fileshare, or into the right groups is due to the fact that the person who enters the data into the system “just knows” where the right place is… well that’s tough to emulate in a system, and you had better anticipate a little consternation from the deployment team.

The bottom line is, garbage in, garbage out:

  • the complexity of your IdM project is directly related to the complexity of your business processes, especially those that are non-standard, or that have multiple originations.
  • the initial length & cost of your project will be related to how much/badly your company diverges from the common scenarios covered by IdM tools.
  • the likelihood that you will stay on-time and on-budget within that project depends on how close your initial understanding of the gotchas and exceptions are to the reality of your specific situation, and how good you are at forecasting what time will be needed to deal with all the things out there that you haven’t found yet.

Not that I have strong opinions on this subject or anything :-D