Pushing String

The notion of “user-centric identity” has been getting a real blog-workout lately, as Paul Madsen notes. Like Paul, I suspect it’s been used in buzzword fashion more than as a crisp concept. I can think of two different obvious ways to define it: either direct user hosting of their own identity information, or (perhaps indirect) user control over another party’s use of it.

As Robin Wilton has said a number of times, insisting on having users personally manage and host all of their own identity services is unrealistic and unnecessary — like hiding one’s cash under the mattress. This isn’t to say that various architectures that give a user this choice (for example, using your phone’s sim card as a source of credentials and attributes) would be a bad idea — on the contrary, they’re quite interesting and useful. But since this definition would clearly draw too hard a line, let’s concentrate on the softer form: user control over another party’s use. However, even this can’t be absolute.

Paul points out an irrefutable case of identity information about a user that, by rights, the user doesn’t control:

Other than the enterprise deployments above, where it can be argued that the user’s control over their identity are scoped by their employment contract, I believe all of the above can be user-centric. [emphasis mine]

There are many such cases. Some traits and characteristics (iris pattern, favorite color) are truly your own, but many of your characteristics (employee ID, role at work) are not yours to change or to obscure from others’ view, and others (uh, felony convictions?) you might only have partial control over, since some others will always have a right to access them.

So I’ve begun thinking about the proposition of user-centric identity as just the natural other half of the usual sorts of access control people talk about: you’re authenticating and authorizing applications and services to access information about you, just as they need to authenticate and authorize you to use them.

Now, because you’re a human, the technical methods for achieving this other half don’t necessarily look exactly like the methods used in the traditional half. For example, Liberty’s identity web services framework (which is normally a back-channel, machine-to-machine sort of thing) has what it calls an interaction service, which allows an identity service to check with a human to gain their consent in synchronous fashion before releasing information about them. Robin’s post linked above quotes Kim Cameron, who is commenting on the legal aspects of circles of trust:

Now, perhaps I am just a man with a hammer who sees everything in the world as a nail, but the paper reinforced my thinking that the more our systems are built to guarantee that the user is the conscious agent of information release (rather than having this done on his behalf), the better privacy is served, and the simpler our lives become from a legal and policy point of view.

I certainly agree — user consent is key, through synchronous interaction if necessary, and through application of user policy in other cases. (The Liberty paper he’s commenting on is here.)

So, a modest terminological proposal: We’re used to talking about mutual authentication in the context of setting up an online (machine-to-machine) session. Can we think in terms of mutual authentication and authorization when it comes to users and the applications and services they use?

As promised in November, I’m finally making available my new “SAML basics” slides and paper. The explorations of M. David Peterson and Russ Miles with their nuxle.us/ChannelXML project made me do it!

Since the first drafts of the SAML standard have been available, I’ve been delivering a talk called “SAML Basics” that introduced its major concepts and syntax. It has evolved as SAML has gone into new versions, as the identity management space and people’s understanding of it have grown, and as the work of the Liberty Alliance has expanded the scope of standards work in this area. For the XML 2005 conference in Atlanta, I took a tiny step back and put together a talk that covers the main SAML V2.0 (and Liberty Identity Federation Framework, or ID-FF) value propositions that are likely to be initially interesting to potential users. The talk is called “Federated Identity Management: An Overview of Standards and Concepts”. I have continued to modify my slides slightly, and will probably do more of this over time. I posted links to all this stuff here. (The entire set of XML 2005 proceedings should be available to the general public soon, I’m told.)

Russ’s UML diagrams seem sound as far as they go (I think — I’m no UML expert). I’ve been pressing for a little more use case information from the guys, which will go a long way towards determining the appropriateness of existing SAML patterns for what they want to do. Here are some brief thoughts I offered:

…from the glimpse I get from the new nuxle.us site and material provided by MD, it seems that nuxle.us would be, at the least, a SAML “identity provider” that takes care of authentication and authorization and shares such details with the other “service providers” in order to achieve single sign-on for users. If the service providers will also have distinct “accounts” for the same users rather than keying solely off nuxle.us authn/authz activity, you’d be looking at account linking across them.

In a scenario where nuxle.us and, say, ChannelXML want to safely exchange identity info about a user (such as online presence info or geographic location info) without bothering him/her in interactive fashion, that would be the world of Liberty ID-WSF (”identity web services framework”), where other stuff would come into play. For the simplest possible scenario of securing web services traffic without much of an identity exchange angle, you could be looking at plain WS-Security using SAML assertions as security tokens.

I pointed them to some potentially interesting open-source efforts: Sun’s OpenSSO, Internet2’s OpenSAML, and a French effort called Lasso. I guess we’ll see where this goes — it would be very interesting if SAML were to become a part of this new set of communities they’re putting together.

Window displays like this have stopped me cold a couple of times this holiday shopping season. Why on earth would you want a Coach bag that looks like a pair of underwear? Worse, underwear that’s currently occupied?

A Coach bag with a problem

It looks barely acceptable in its completely new state, but that little bit of slouch in the mall version makes a horrible difference.

UPDATE: I don’t know why this picture is coming out so small… Will see what I can do about that. But I now notice that it’s the “leg bands” in my photo that really give the illusion. Out of all of these choices, I don’t see one that exactly matches. The “Signature Duffel with Suede” seems to show off a nice little tush, though. :-)

UPDATE 2: It’s definitely the Signature Stripe Large Carryall. I have got to get over this obsession.

Check out this SDForum event on January 31 on the subject of Interoperability — Next Generation Architecture.

Live Music @ 9pm - “Mudcat”

My band has miraculously kept the same name for a couple of months running now, and so when we perform again at the Montlake Ale House on Saturday, January 28, we’ll still be Mudcat. If you’re in the area, come on down! Parking can get tight; it’s a fine place to have dinner if you want to snag a parking spot earlier.

That’s the name of the new WordPress theme I’m using on the blog. (It seems especially appropriate to mention it on January 1st.) Eli, my resident sys admin, kindly helped me with a WordPress 1.4-to-2.0 upgrade this morning. If I’d ever done the intermediate 1.5 upgrade step, I would have had to mess with my theme earlier, as the old one (called Silver Is the New Black) wouldn’t have been compatible with it anyway.
I’ll need to play with some of the settings, but it seems to be working okay for the moment. If you notice any problems, please drop me a line.