Pushing String

Despite parts of Oxford turning into a big blue wobbly thing and punting getting canceled, the XML Summer School this year provided a great experience for speakers and track chairs and, I hope, delegates as well. Others have written about their experience. I thought I’d share some of the more interesting moments from the Web Services and Identity speakers here, with more to come as I slowly complete my reverse timezone shift.

Marc Hadley (apologies for lack of speaking photo!): The first of two speakers to strongly recommend the O’Reilly RESTful Web Services book. Make services “part of the web” rather than just working “over the web”.

Paul Downey: In addition to thinking about the services part, we should think about and exploit the web part. “Aristotle, the canonical information architect, says you must have command of your metaphor.” The contract approach is a problem and taxonomies bias things. “I don’t think there is a WS-* caching spec, interestingly enough. [pause] Please don’t write one!”

John Kemp: The same web services concepts apply to networked services that aren’t on the web per se. John generated an amazingly prescient horoscope from a Python-based web service running on a virtual phone on virtual Windows on MacOS, using an HTTP-like protocol over SOAP over BEEP (whew): “You will make a presentation about web services.”

Jeff Barr: Shared the Amazon Web Services story, which demonstrates the power of web services for fun and profit. Demoed sales rank messaging; surprise surprise, Deathly Hallows was #1. :-) Showed cool sites liveplasma, blingee, and The Sheep Market. Developers don’t ask about “SOAP vs. REST” anymore; they tend to use purpose-built AWS toolkits.

Rich Salz: “You are your key” — that is, your cryptographic key is a very close analogue to your digital identity, particularly in app-to-app interactions. On any digital signature system, XML canonicalization is the most expensive part of the processing.

Paul Madsen: In response to a question about whether he truly understands XRIs, admitted that “I don’t have any magical powers.” :-) Rudely used his speaking opportunity to look for investors in his new Web 2.0 app.

John Chelsom: An argument for holding health information in a national electronic record as opposed to paper copies all over the place is that if a breach happens, at least you know about it!

One more moment I have to share: Bob DuCharme and I have been talking for a couple of years about setting up the perfect geek photo. See, one of his daughters is named Alice, and we saw an opportunity to illustrate an important data security principle…

(More pix of the event by various people here and here, and flood photos here.)

So, what happened was, the flight I was supposed to be on right this very minute got canceled. That royally messed up my Deathly Hallows plans. But I rallied. Oh no, not gonna get on a plane surrounded by other readers all too eager to share spoilers without my own book in tow.

It turns out I’m not leaving for Oxford until mid-afternoon tomorrow. So my evening consisted of:

1. Pre-ordering HP7 at the extremely local bookstore.
2. Seeing HP5 a second time at the theater right next door.
3. Checking out the bookstore’s HP7 party, which kicked off just as the movie ended.

I’m not gonna last till midnight, so a big part of tomorrow morning will be:

4. Picking up my book.
5. Becoming unable to concentrate on anything else (except getting to the airport).

More photos from the party here.

Via Tom Scavo comes the news (PDF) that the U.S. E-Authentication program has finished revising its architecture to use SAML’s latest version, 2.0, “to better meet the authentication needs of agencies.” I noticed that this issue of the GSA Federation News newsletter also has an article on interfederation, the higher-order joining together of existing federations, and GSA’s efforts to figure this out with the Internet2 InCommon folks. This is a really important tool for achieving the ever-wider linking of accounts that I’ve been blathering about lately. (Ooh, and it’s another term I can add to my growing F-word lexicon.)

InCommon has the clearest, cleanest invitation to join a federation that I’ve ever seen — it may provide a model for how to tackle the business aspects of huge-scale account linking with accountability. That said, Georgia Marsh and her E-Authentication colleagues highlighted interfederation as an issue that’s very much alive when they spoke at the recent Concordia workshop (check out her slides for some detailed numbers on their program’s adoption levels to date). And she stressed to me yesterday that nontechnical issues such as interfederation, and the mismatches between partners’ business frameworks, trump any technical issues they find when it comes to interoperability. The cool thing is that this is now a matter of active, practical discussion.

By the way, I’ve been circling back with the use case presenters at this workshop, and I’m planning to host a Concordia telecon in the next small handful of weeks to discuss what we learned and select two or three “hot” areas to focus on going forward. If you’re not on the mailing list and want to take part, now’s an excellent time to join.

All that fruit hanging about ten feet up on the federated identity tree is starting to look more and more reachable…

I recently suggested that account linking is an identity Trend, and got some interesting responses to my query about what people think are Trends vs. Transients vs. Tropes vs. Transparents.

Separately, on the “ID Gang” mailing list (sorry, private and not linkable) over the last couple of days, there’s been a discussion about the beta service Spock and the fact that it asks you to supply your login credentials for other web accounts, such as LinkedIn. That’s not a very attractive proposition. The question was posed on the list: What’s a better way to associate profiles than this? I bet you can guess what my answer was…

The better way would be for Spock to link its account for you with those other ones, allowing a more limited version of your identity information to pass between them without Spock having to know your credential data on the other side.

This process of account linking, along with ways of avoiding sharing your “real” account identifier on each side for even more privacy, is something Liberty ID-FF and SAML have specified for a long time, and there are lots of existence proofs in the world (with a variety of technologies). You can do the linking implicitly when a new local account is created after you’ve been transferred over from your remote login site, or you can arrange to do it explicitly (e.g., by having the user opt in in real time) if a local account already exists.

Such linking would require a service like Spock to give up some control and to accept a more loosely coupled and partial-trust relationship, not just between it and another service (or between it and an OpenID provider or whatever), but also among them and the user. So an important point about account linking is that it’s more about what distribution of trust and responsibility and ownership all of the parties are willing to live with, rather than deep technology or protocol details, which means we’re immediately flung into the world of “business decisions” and governance matters.

I later commented that account linking is an essential process you have to go through to get any kind of unified identity layer, given that lots of valuable local/limited-scope accounts are already in existence. Account linking is precisely how we would begin to dissolve identity silos, the same way ATM network silos got dissolved: one relationship at a time.

Now, since “silo” came up as a Trope in the comments to my other post, as did “federation”, perhaps I should swear off both words unless I qualify every usage for the sake of clarity and cliché avoidance! Along these lines, following are additional (slightly edited) thoughts I shared in the Spock thread having to do with terminology.

Some term disambiguation is probably warranted, given that this gets close to the dreaded F-word (federation and its variants):

There are several ways SAML and Liberty use it, and an important one is to talk about federating identities (plural). To a first approximation it just means account linking (it’s a little more subtle than that because the protocols don’t actually assume that a persistent “account” or “user record” or whatever has to exist).

By the way, federating identities doesn’t necessarily imply the existence of a circle of trust (a federation of business partners who have pre-negotiated a relationship, like the United Federation of Planets) — it could be done ad hoc. Scott Cantor has often complained about the infelicitousness of Liberty having given the impression that the technical process relies on a business contract.

Sometimes this same thingie is discussed using the term identity federation (the process of linking) or (a) federated identity (the resulting link), but I’ve come to believe these are often ambiguous because there’s a narrow-scope usage and a broad-scope usage.

The broad usage, typically in the form federated identity or federated identity management, is more in this sense: technology that is capable of distributing identity information and delegating identity-related tasks (at least including authentication) across domain boundaries. The organizational distances between the parties can be arbitrarily large — it’s not enough to say just “distributed” because this is often used for multiple boxes that might live inside a single enterprise. It thus seems to me that OpenID qualifies as “federated identity” just as much as SAML does. :-)

To complete these thoughts about terminology, I think identifier namespace is a fine phrase to use in place of the sometimes-pejorative silo. OpenID has an extremely large, flat, unified identifier namespace that consists of URLs and XRIs. Most other federated identity system deployments have an identifier namespace that’s smaller than this, maybe more privacy-sensitive, and certainly not guaranteed to be something a consumer site could understand or should use directly.

Belatedly noting the good news that IBM has issued what it’s calling an Interoperability Specifications Pledge, which amounts to a non-assertion covenent on a list of covered standards. If you haven’t already checked out Bob Sutor’s post on the subject, go forth and read: it discusses this action and its implications with commenters, including the very knowledgeable Simon Phipps.

My take is that the pledge is a pretty darned good one. Like so many others (but not Sun’s), it has the “necessary claims” flaw, discussed by Simon in the comment thread, but despite that it puts in place some relatively strong protection around developers’ ability to get on with developing. I agree that the covered standards list is handily precise for its many links out to the relevant specs. (The list seems a bit, well, padded — listing the individual specs that make up SAML V1.1 and SAML V2.0, for instance, which makes it seem as though two standards are twelve. But that’s okay.)

I haven’t done an exhaustive comparison of covered vs. non-covered specs, but Johannes Ernst has noticed that OpenID is not listed. It would be interesting to know why, especially given IBM’s participation in OSIS and Higgins.

Jeni Tennison went and infected me with a notion today in her post mentioning the Ian Knot — a more efficient way of tying one’s shoelaces. (I guess I still have the capacity to be amazed by the Interweb…a whole site about shoelaces?!?) I couldn’t resist poking around Ian’s Shoelace Site, shoe in hand, practicing the Ian Knot and also debugging the bows I’ve been tying my whole life. Yes, it’s true, I’m a Granny Knot tier and I didn’t even know how horribly inefficient it was. But there’s time to change my ways.

In the same spirit of picking up new life skills, Jeni’s new one around knot-tying reminded me, very closely in fact, of one I picked up recently myself: knitting. I finally taught myself how a few weeks ago by using my newly acquired Stitch ‘n’ Bitch book (I reviewed the crocheting book by the same author here) and a great site called KnittingHelp.com.

As an aside, I remember when the computer documentation crowd dutifully defined all its SGML DTDs to have video elements in them because we were sure that, someday, documentation would actually have videos in it. It sure wasn’t happening much in 1991, or 1995. I’m glad it finally came to pass.

While crocheting gives you one nice, easy hook for pulling one loop through another, making the tricky “live” area localized, knitting gives you two pointy sticks and a whole row of live stitches at once. Yikes. Luckily, knitting has some benefits over crocheting that made it worth trying, such as that it uses a lot less yarn, and results in a less bulky/dorky fabric. (Most crocheted sweaters shouldn’t have been.) Once I got over my abject fear, I went through much the same process to try out the stitches as I just did tonight with the Ian Knot and a proper Square Knot with Ripcords.

What I’ve learned is that there are actually multiple ways to make “knitting knots”, which is kind of what knitting and purling are (or are they more like lacing?), and you might choose different ones depending on what feels right to you. Everyone knows about the English style of knitting and purling, where you feed out the yarn from your right hand, and the Continental style, where you feed it out from your left hand. But I hadn’t heard of Norwegian purling before — and it supposedly produces the same result as regular purling.

All this led me to wonder if anyone had figured out some kind of formal “knitting knot theory”, which would be helpful in working out all the different possible variations. I didn’t find any evidence of such a thing, though the Home of Mathematical Knitting has a pretty good roundup of links of the “I knitted a mathematical model” variety, and mentions someone named Amanda Redlich whose work may be related.

With a long plane trip coming up, I’m going to keep practicing the knitting thing, and will try to incorporate the Ian Knot into my life too. If anyone has managed to unify it all, let me know.

I actually own one, along with a wand that looks very much like Hermione’s, but sadly I remain a frustrated wizarding-wannabe Muggle — they don’t work. Conor knows exactly how to get my goat — seeing Order of the Phoenix three hours before I did! I saw it at a theater that offered three showings, and my companions and I (three fans and a relative newbie) were able to get excellent seats for the earliest one, having shown up an hour early. A working time-turner would have been especially handy for letting me both see the movie and sleep — at this point in my life, I have to carefully plan any outing that runs till 3am. Sigh.

I’ve already re-read the series in preparation for the arrival of Deathly Hallows, and reading book 5 again definitely added to my enjoyment of the movie. I thought they did an excellent job of hitting most of the scenes and dialog and images I was hoping to see, and our newbie movie companion seemed to enjoy it as much as the rest of us did. This Slate review is mostly in line with my thinking (and gets extra points for using the word antepenultimate correctly). Most delightful rendition: the Franklin Mint plates in Umbridge’s office, along with her general sadism. Most disappointing: the Weasley brothers’ exit from Hogwarts.

Now I have to execute on my plan to read Hallows as soon as possible after its release, both to avoid spoilers and to relieve my own suspense (heightened by having read this). Since it will be available only the day after I leave for Oxford, and I want to own a copy of the American edition, I’ve found someone living in the U.S. who wants to own a copy of the English edition — we’re going to each buy a copy, read it, and swap on my return. Now that’s optimization…

I go back to Hawaii for a visit every year, and I’d dearly love to manage it more often than that — and to spend more and more time there on each trip, so that they all sort of run together and become a permanent thing. Failing that, I try to make the most of every day while I’m there.

Eli and I just back from our latest trip, and we had a wonderful opportunity on Saturday. We joined our friend Donna and her beautiful little dog Ipo for a sunset walk up to Makapu`u Lighthouse, at the very eastern tip of Oahu, to see the full moon rise over the ocean near Molokai. (We had thought it might be a blue moon, but it turns out we were off by one.) The following isn’t much of a picture, but it was the best one I was able to get. The moon was clearly channeling the Potterverse in honor of movie 5 and book 7.

Oahu is small enough to drive around comfortably in a day, but big enough to have dozens of must-see natural formations — which always gives me a sort of “ant crawling on a relief map” feeling. Makapu`u Beach is my all-time favorite spot on the planet, but somehow I’d never gone up to the lighthouse before this trip. We actually went up twice — we all went the previous Sunday before sundown, when the light was a little stronger but the lunar-like landscape had cooled a bit from the heat of the day. You can see pretty much the whole eastern tip of Oahu from one spot here. Below, in the view to the southwest, you can see right into Koko Crater, as well as Diamond Head in the distance.

The lighthouse itself offers a more refreshing view next to all that parched lava.

Other special experiences on this trip… The opening of a new Starbucks in the lobby of the Hilton Hawaiian Village’s Kalia Tower, which included a traditional ceremony to bless the enterprise — I actually got all verklempt:

Your average sunset on boring old Waikiki beach, viewed while sipping mai tais at the venerable Royal Hawaiian hotel (helping friends Jill and Mark celebrate a very special wedding anniversary — hey, even people who live there go to these places!):

And last but not least, a stuffed-kitty-cat orgy at the Shirokiya department store at Ala Moana (anyone want to suggest a good lolcats caption for this?):

UPDATE: Because I can’t resist, and because we regaled Donna with a rendition of it on the way back down the hill… We Like The Moon!

In a few weeks’ time I’ll be at the XML Summer School, teaching and learning and, um, drinking. One of my assignments there, as Lauren explains, is to spend five minutes opining on technology themes as “trends and transients”. My approach last year was to cover somewhat more ground under the general heading Tr*:

• Tropes (technology metaphors that have perhaps become dull with overuse) — I listed “architectures” and “messages” in 2006.
• Trends (things worth knowing for the long haul) — I offered “identity layer”, “mashups and SPLJ”, and “privacy” last year.
• Transients (shiny new things that are unlikely to stick around) — in 2006 I listed the “SOAP vs. REST” controversy and the naming of things as “2.0″.
• Transparents (important things people keep looking through instead of at) — last year I highlighted “policy”.

One theme I’m thinking of including this year is account linking — that is, federating or associating multiple identities together. While I was on vacation last week, blissfully keeping away from Planets Identity and XMLhack (though I appreciated them all the more on my return!), I gather that there was a blogospheric dustup about the notion of an “identity layer” and whether it’s good, bad, or indifferent — Kermit Snelson summarizes and deconstructs the discussion nicely here. (I would also point to Interop of Twitter and Pownce by Marc Canter and Network Effects Mean Walled Gardens Are Here to Stay by Dare Obasanjo.)

What I meant when I talked about an identity layer Trend last year was a single shared means for exchanging identity information and distributing identity tasks in a secure, privacy-sensitive fashion, not a means for ensuring that everyone has One True Identity. I just don’t see the latter happening any time soon or even being a good idea. On the other hand, the task of federating identities just reflects the reality that (1) people will continue to have digital identities in different “identifier namespaces” and (2) people want a unified experience across them. (Heck, even OpenID-consuming websites doing any kind of persistent user personalization have to federate the distributed OpenID account with a local app account.) Users’ desires for linking multiple distributed identities will eventually trump “account jealousy” on the part of identity providers, and providers will have to get a lot better at doing the linking — sometimes in challenging circumstances that demand new sensitivities to privacy. I smell Trend…

What would your Tr* 2007 answers for web services and identity be?