Pushing String

A little while back I did a podcast with Daniel Raskin on federated identity standards for Sun’s IdM Buzz blog. IdM Buzz is a font of useful information, and I encourage you to check it out, but I have to admit I delayed posting this podcast link because the filename they assigned it made my face turn red. :-)

Even though I was running on fumes when we did the recording (I give a hint as to why in the final minute or two…), I think we managed to put together some good, easily digestible information about standards that complements the new Government Computer News SAML cover story pretty well. If you found me here at Pushing String by reading that article and hunting for more info, I definitely recommend the podcast to you.

And now, here’s my chance to attempt the blog equivalent of a triple gainer: In the podcast I talk a tiny bit about my band. Recently we headed into the studio to record a demo CD (a blast and a half, and something that helped out a good cause). And what did I do while hanging out in the control room between takes? Domino knitting. Oh, yeah.

Fearless leader John in the studio’s control room (see related Flickr set here)

XPointer seems to have made its way into the heart of the Service Modeling Language! The SML spec defines an smlxpath1() scheme and everything, and seems to do it in the spirit originally intended. Wow.

…or the greatest thing since long-lasting nasal spray (to quote the immortal Dave Barry)?

Given the announcements about OpenID providers (the latest notable ones being Yahoo and the Telegraph), it seems ordinary people have a multitude of OpenIDs to choose from, alongside all their regular “non-decentralized, non-user-centric, non-open” (to coin a phrase) identifiers. Put another way, every week I experience a net gain of about 1 new online identifier, and with the recent OpenID announcements I see the trend continuing.

It’s tantalizing that the Telegraph hints (without confirming anything yet as far as I know) that they’ll accept OpenIDs from other sources. But to the extent that OpenID providers don’t do that, or do it only by carefully vetting other partners and setting up special whitelist relationships with them wherever data of non-zero value might be exchanged, the situation will look an awful lot like it does now: circles of trust getting built through contractual negotiations, accounts being federated either one-by-one (when users request it) or in bulk (where users are okay with this sort of back-channel communication), and so on.

OpenID identifiers may be decentralized in that anyone can create and dereference them, but it’s a lot harder to “decentralize” the building of trust relationships; the world has been trying without a lot of success. So we may eventually be able to get to an ATM-network-of-networks scenario, or a roaming-telephony scenario, where all the parties have worked out all the relationships and you can use your “home” identity anywhere — but I foresee having to do it the hard way, the way the financials and the telcos (and, by the way, the InCommon Federation) have done it.

The question is, does OpenID provide other benefits that outweigh traditional (including SAML!) interfaces for making this happen? In the Identity Provider/Relying Party/User adoption triangle for OpenID, IdPs are extremely heavily weighted at the moment. This is no surprise whatsoever; opening up an OpenID interface to an existing set of accounts is relatively easy and exposes you to lots less risk than accepting arbitrary “foreign” claims. The triangle needs to even out if we’re to see network effects, and for that to happen, OpenID may have to become more and more like the thing some say is antithetical to its design center: an enterprise-class framework that caters to many different trust and privacy needs.

(Jeff Hodges has just published draft 06 of his OpenID and SAML Technical Comparison — this link goes to whatever the latest draft is — and it provides food for thought on the two approaches, particularly if you know one well and want to learn more about the other.)

And the answer is none. None more black.

(Well, all right, if you insist, it could be 0.045 per cent more black. Pedant!)

…is asking, with his usual wit, for our prayers. Don is an inspiring fellow even when he’s not handed the ultimate in challenging circumstances, and he’s someone I’m proud to have as a friend. Let’s all send some positive vibes his way.

Lots of folks have already commented on the latest Liberty Alliance SAML2 interop testing results, and yes, Sun checked off all of the matrix columns with Federated Access Manager. (Have we flogged that news hard enough yet?) Now comes Gerry Beuchelt with the scoop on our efforts with Microsoft this week to test our CardSpace support. A matrix was involved there too, but I don’t think anyone took a picture of that whiteboard! We didn’t quite check off all the items, but we were close. (I can hear Mrudul thinking, “Whaddya mean we?”) [UPDATE: Whiteboard pic now available chez Gerry.]

As an aside, I was delighted to meet Jiandong in person for the first time at this deep-dive, after working, speaking, and emailing with him for some years. It’s all part of the longstanding tradition of Sun people meeting other Sun people at non-Sun locations…

Oh no:

The iPhone recently fell victim to its first Trojan attack….

Security blog F-Secure warns users to be wary, however; speaking to the modding community, blogger Jarno writes “Hopefully this serves as a warning for those who have opened their iPhones using a security hole in the system and then installing unverified software without a second thought to what they are doing.”

He continues, “This time it was an 11-year-old kid playing with XML files who created the trojan. Next time it might be someone else with more skills and with specific target.” [emphasis mine]

W3C has a working draft out on cool URIs for the semantic web that looks at how to choose URIs for RDF descriptions of both information resources (web documents) and non-information resources (such as people). The paper suggests that URIs should unambiguously refer to only one resource at a time — for example, Alice’s web page and Alice herself are distinct and should be referred to with different URIs.

This lofty philosophical topic (the whole resource-identifier/resource/representation-of-a-resource distinction still gives me a headache) gets boiled down to a fairly ordinary recommendation to use tricks like http://www.example.com/about#alice — a URI reference with a fragment identifier of “alice” — to refer uniquely to Alice the person, and to use content negotiation to retrieve an RDF description of what that particular referent actually is.

What’s more interesting to me is how “cool URIs for non-information resources” intersects with identity. I’ve noticed that the RDF world talks about people on the web, but the reality is that people do web stuff with a layer of several digital identities in between. For instance, it’s likely that http://www.example.com/about#alice, in the context of the scenario introduced by the paper, refers to Alice in her role as an example.com employee, and that she has a whole other digital life beyond the confines of example.com.

Of course, the notion of a URI referring to a digital identity maps nicely to OpenIDs… An OpenID really has three potential “audiences”: (1) it’s a machine-resolvable endpoint that OpenID consumer sites can use get the OpenID’s owner authenticated; (2) it’s often “human-resolvable”, allowing arbitrary people to follow the link and see a “home page” for that identity (anyone can go see what’s at http://openid.sun.com/xmlgrrl, for example); and (3) the string itself becomes a well-known name for its owner and provides the ability to correlate her activities across the web.

If we accept that a URI will tend to encompass only a part (a persona or whatever) of a whole person, Cases #1-2 are copacetic with the mechanism of resolving a URI to get a (possibly RDF-encoded) representation of a resource and doing content negotiation at one level or another to accomplish description-switching. Case #3 isn’t covered by the paper, in the sense that the special circumstance of URIs-themselves-as-resources isn’t touched on — though I dimly recall that RDF does deal with this as a use case. I have a nagging feeling that a complete “cool semantic web URIs” solution does need to account for this.

As I was doing all this pondering, I came across Scott Kveton’s post today on URL’s are people too … and service end-points. Aha! Indeed they are (allowing for the rhetorical conflation of the resource identifier with the resource itself, which doesn’t give me a headache). That’s really what I meant by talking about the “user as web resource” metaphor back in August. Depending on the sophistication of the metadata and the various services we choose to provide at that endpoint, a URI can, over time, do a better and better job of representing a flesh-and-blood person online.