Pushing String

Great news about Higgins and its first steps on the road to SAML V2.0 support! Some of the input from use-case contributors at the Project Concordia table included concerns about how identity selectors might tie into their current use of SAML and Liberty Web Services, and I’m sure Higgins will prove to be a useful test bed for scenarios these deployers have in mind.

This news bears on a topic I’ve been mulling over for some weeks now. In Concordia we’ve been discussing the different tradeoffs involved in making different entities “smarter” to handle multiple protocols. Scott Cantor has spoken eloquently in favor of the smart-relying-party method of improving interop in heterogeneous environments, by making what amounts to a do-everything toolkit available for service providers to install and use. I think it constitutes one good use case, but SURFnet chooses the smart-identity-provider approach using a translation hub/proxy instead, and George Fletcher has proposed some ways RPs and clients could get smarter together — these are valid too.

Scott’s comments highlighted the tension between APIs and protocols in providing consistency, repeatability, and interoperability in deployments. (In this post’s title, “I” stands for interoperability rather than identity.) Interop is something you measure between actual implementations (such as products, open-source projects, and other technology stacks), but protocols are a key part of managing and encouraging interop. I told a little story in the OASIS workshop to illustrate this tension…

A solution for cohesive treatment of pretty much any technical problem often starts as a proprietary API (or two or three).

In order to promote cross-platform and cross-language support, a message-oriented protocol gets created, either by fiat or by some open standardization process, to match it. (Sometimes a protocol is created without a nod to any existing API, of course.) As the saying goes, “The truth is on the wire.”

But in a highly distributed environment, inevitably such as those where federated identity is needed, the cost of getting all your partners to build and deploy support for handling these messages can be prohibitive. So some sort of common or standardized API, often associated with an open-source project, gets built that makes deployment easier. This is usually complicated by the need to create an API for each language or development environment. (By the way, I don’t mean to knock standardized APIs — such as those defined through the Java Community Process! — for their interop value. I’m just working through what happens when protocols appear on the scene.)

But then some competing protocols show up on the scene, which offer a different mix of capabilities or conceptually slice up the world in a different way.

So next we see an abstract API — enter Higgins! — created to unify or blur the distinctions between them. As a natural consequence, “glue code” is added, which is a huge convenience but which also adds distance between the deployer and the contract they enter into by using any particular message protocol.

Now multiple abstract APIs come onto the scene that purport to cover the same ground (I guess these would be the Lone Gunmen :-) ). Do they choose all the same protocol options in exactly the same way? Are translations back and forth happening similarly in each stack? What about the handling of impedance mismatches, where, say, one protocol has more features than another? Are some good ideas for consistent treatment buried in different pots of glue rather than being exposed on the wire?

Really, when a deployer chooses any one implementation stack, it amounts to a product decision — and the answers to these questions are important factors in figuring out exposure to lock-in. This is why documenting glue behavior is important, whether in profiles, extensions, gateways, translations, or even just descriptions of best practices.

It’s my hope that deployer-driven Concordia use cases can highlight specific needs for additional protocol guidance…which is useful grounding when architecture astronautics beckon.

One topic I discussed briefly in my talk last week (slides still pending, sorry) was the larger question of “identity for what/whom?”. One of the things we often forget when discussing “user-centric” identity is that many non-human entities have a unique identity, and it’s useful to strive for identity systems that can unify the handling of human-mapped identities and other-mapped identities — corporations, departments, devices, software applications, etc.

Even if you stick to just human-related identities, one thing that has always bugged me slightly about the phrase “user-centric identity” is that it presumes a user of some networked client device, when we know perfectly well that lots of humans spend considerable portions of their day offline, by choice or not. I don’t know anyone who actually prefers to be online to pay a bill that comes to the same exact amount every month. They just want to be able, in their own sweet time, to audit the payments that were automatically made. Not to mention the many scenarios where an emergency or sudden change in state might call for you (or someone else you know) to be roused from sleep or a meeting to answer an important question (with “Sell! Sell!” or “Yes, you have my consent to operate” or “No, that unusual purchase was not made by me”). I think Mike Jones now considers me the “break-glass scenario queen” since he readily tossed such topics to me in Barcelona last week :-), but in reality offline scenarios are all around us.

Back in August I jokingly tried out the phrase “user centricity by polling” in dealing with users when they’re offline. But now I realize that the description I’m after is more like “human-centric identity”. It comes with both online and offline scenarios and still needs to allow for (real-time or not) informed consent and attribute exchange.

I thought of this when reading Will Norris’s post OpenID is not a provisioning engine. He riffs on a scenario from James Henstridge where you can propagate a new shipping address to every service that needs to know it. (Actually, I think the shipping address scenario advances to a technical assumption a little too fast. The timing need not be when the address changes but rather just in time when a service finds itself needing to ship something to someone.) Will discusses why OpenID and its Attribute Exchange extension are not intended to meet the use case of immediate attribute update in between user login sessions, and what sorts of push and pull technologies might be needed to solve it. He provides a very interesting perspective, delving into options for managing this process at a variety of points on the stack-layer and “lightweightness” scales.

I would submit the Liberty Web Services framework for consideration as another option. It adds identity semantics on top of web services — to give one small example, it standardizes WS-Security token representations for the identities of the person asking, the service asking, the service being asked, and the person that service is about. (Notice that right away we’re in a world that includes both human and non-human identities!) It also defines special web services to meet those sophisticated offline use cases, such as the Interaction Service, which allows for person-polling using a mechanism chosen by them (such as SMS). My ID-WSF Basics preso from January provides a gentle introduction to the framework for anyone interested to learn more.

(Paul Bryan has heavily influenced my thinking on the “identity for what/whom” issue. Thanks, Paul!)

We moved xmlgrrl.com to a new host today and also upgraded to the latest WordPress version, so this is just a test entry… But while I’m at it:

I accidentally killed my Treo 680 a couple of weeks ago and now I’m trying to figure out what to do next. The iPhone turns out not to be an attractive/complete PalmOS replacement device (yet, anyway — no to-do list app?!?), and I’m not liking the price of a new Treo sans contract. Consider this a smartphone bleg. Anyone got advice on a phone/PDA option that syncs smoothly with Palm apps, works on the AT&T network, and doesn’t cost both an arm and a leg? Or am I just hosed?

While some Sun colleagues headed to Tokyo for the Liberty Alliance meeting, others of us went in the opposite direction — to Barcelona for the Burton Catalyst conference. I spent all day Monday in the OASIS IDTrust workshop, which was quite interesting; this is the Member Section of OASIS that was formerly the PKI Forum. I spoke on some of the problems of heterogeneity in today’s federated identity world and how Project Concordia is taking a run at them, and at the end also participated in a panel with June Leung, Tony Nadalin, and Andre Durand. (OASIS will be posting all the workshop slides soon, and I’ll point to them when they’re available.)

The conference went into full swing on Tuesday, and has been chock-full of good content. (And, of course, good food. Barcelona can be low-carb heaven, with all kinds of savory meats and succulent seafood on offer. Unfortunately for me, there’s also a lot of good chocolate, usually buried inside high-carb-hellish items.)

The first night of hospitality suite action was really hopping. This is where the second OSIS interop session was conducted, and Sun participated this time, testing out a managed card provider/IdP that was built as an extension to OpenSSO. Gerry Beuchelt did a lot of work behind the scenes, and Mrudul Uchil, a senior engineer on the Federated Access Manager team, brought it all together on-site. What an awesome team! Daniel Raskin, Sun’s product line manager for federation and access management, was also on hand. You can see the results of the IdP test case here [UPDATE 1 Nov 2007 12:33pm: Mrudul has updated that matrix with the latest info], and here are some pictures (click to enlarge).

Get Card

Here’s What You Posted

Daniel Raskin and Mrudul Uchil

Daniel pointing sincerely (not in photo-op fashion!) at something on the screen

I’m still mulling over everything I’ve been learning at this event and will post additional semi-ordered thoughts soon.

Early vintner returning from the kill

We’re waiting for a hot fix or two, but our long-planned kitchen remodeling project has shipped. And no engineers needed to be shot — though we were getting pretty testy towards the end there, what with half the apartment inaccessible due to plastic swaddling.

Celebration corks

I went way overboard with the photos (Eli doesn’t call me Hermione for nothing), but if you’re a glutton for detail, I recommend the following viewing experiences. (Or go to the whole Flickr collection for time series from every angle…)

Series #1 (slideshow)

Series #7a (slideshow)

Series #7b — the backwards series (slideshow)

Kitchen moments (slideshow)

Big thanks to Nick Meyer of New Face for the awesome job!

Okay, last time I talked about this workshop I was speaking in Pirate so it’s worth making the point a little more clearly, in standard English this time. If you’re going to the Burton Catalyst conference later this month in Barcelona, you really owe it to yourself to sign up for the associated (free!) OASIS workshop. The title is “OASIS Identity and Trusted Infrastructure Workshop: Evolutionary Milestones”. I’ll be speaking there, and now with the latest Concordia workshop under my belt, I can comment on what we’ve learned from deployers about their multi-technology priorities and concerns, and what we’re doing to facilitate high-value choices among the various standards and interop efforts. (I rather like Paul Madsen’s take on how to categorize all the efforts, and hereby second the motion to standardize his boilerplate.)

Lately the faster I go the behinder I get. All the juicy news from Digital Identity World has been remarked on already (including who was hanging out at what bar), but I wanted to point out a favorite item or two.

The 2007 Liberty Alliance IDDY awards are out. The recipients this year are all doing truly interesting things. At a DIDW talk in which the winners got to describe their deployments, Chuck Mortimore discussed how Rearden uses federation to improve the profit margin for its customers, and eBIZ.mobility’s Ram Banin described how they’re harnessing existing payment-processing systems to open up online services. NTT’s Kenji Takahashi essayed a demo of the very cool SASSO system, a personal identity-provider-on-a-phone that lets you achieve strong auth and data-sharing control when you engage in a PC-based web interaction. And Bill Young of the New Zealand State Services Commission showed how NZ is coordinating identity-based services while giving citizens the control they need (and the privacy they deserve according to law). Together these case studies demonstrate the depth and breadth of what’s possible today — something a lot of people may not be aware of.

After the conference closed on Wednesday, some three dozen people participated in a Project Concordia workshop. We heard from Bill Young of NZ here too, along with other deployers who offered advice on solving problems that arise from having to mix technologies. (I notice that the NZ goals have some similarities to the BC government goals shared in an earlier Concordia workshop and at DIDW.) Our subsequent technical deep-dive helped us prioritize the biggest pain points for all these folks — metadata, IdP discovery, and a concern about integrating CardSpace into existing SAML deployments all bubbled up — and we began to plan next steps for improving the situation. Make sure to check out the workshop notes (and consider participating if you aren’t already!).