Pushing String

Neato — a QRCode pillow that talks about itself. (H/t JeffH.)

Jeff Jarvis answers Steve Baker’s question in fascinating fashion, imagining a commercial flight experience that’s designed to be more social not only in meatspace terms but also on a digital basis. I think we’d all benefit from his suggestions. And the notion that customers become members of an airline community is not so far-fetched: Virgin Airlines explicitly goes for this effect, and I recently participated in a focus group for United Platinum Executive members where we all expressed an oddly fierce devotion to the company.

Jarvis’s photo brings back memories of those halcyon days when my family used to rush up to the lounge to get the good hanging-out seats and the free packs of playing cards on the UA HNL-LAX run. Of course, they couldn’t compete on price back then so they had to think up other advantages. (A 20-ounce latte to the first person who can find me an online video of the old Western Airlines ad: “Coffee beans, cha cha cha…”)

It’s been a little quiet around here — I haven’t pushed much virtual string lately. Business travel, vacations, holidays, laptop-switching, and various other home IT projects have kept me busy. I’ll try to make it up to all (three) of you in 2008. But I had to post here at least once more in 2007, to mark my third blogiversary.

I have managed to do some literal string-pushing in recent weeks, learning a technique called modular knitting. Ooh, I thought, modular?! — that’s cool. It turns out that one of its alternate names, domino knitting (as popularized by Vivian Høxbro), is a little closer to the truth because you knit small mitered squares and then immediately form new ones on the edges of old ones as you go. So it’s not modular in the sense of knitting a pile of granny-square-like objects and then arranging and joining them however you wish; everything is the same size and adheres to a “contract” specifying well-known interfaces but gets locked into its predestined role pretty quickly. That’s when I started thinking of it as SOA-enabled. (I crack me up.)

I’m still a knitting newbie. I’ve managed to master the knitted cast-on bit and the double-decrease bit and and the picking-up-stitches bit, but knitting over yarn tails and carrying multiple colors continue to elude me, which limits my options. I need to get the advice of experts who are sitting right there with me — and luckily, I’ll have many such chances at the Madrona Fiber Arts Winter Retreat.

In trying to learn more about modular knitting, I stumbled on this account by the Girl from Auntie of its origins, which explains that — gasp — a woman named Virginia Woods Bellamy patented the basic technique under the name number knitting (U.S. Patent No. 2,435,068). The GfA’s explanation of how this patent might have come to be granted applies just as much to the expansive software patent world (and is equally unsatisfying as an explanation). What’s really crazy is the long list of patents that cite this one. I couldn’t find any discussion of patent licensing terms that might have been offered by Bellamy while it was still in force, and can only hope she didn’t sic any lawyers on any knitters.

The GfA seems to be an accomplished knitter and writer, most of whose writings don’t seem to be online anymore — a shame. She apparently used to offer an essay on copyright for knitters, which along with her knitting patent thoughts would have made a great addition to Lauren’s commentary on the subject, but it doesn’t seem to be available now. I did poke around a bit and found this hilarious pattern of hers, which starts out with:

AGREEMENT RELATING TO A RAGLAN PULLOVER

This RAGLAN PULLOVER KNITTING PATTERN dated this 22nd day of December, 2006 (hereinafter referred to as the “Pattern”) being designed by the girl from auntie (the “Designer”) and entered into by you, an individual knitter (the “Knitter”).

RECITALS

WHEREAS Knitter is currently in possession of, or intends to acquire, approximately eight hundred (800) yards of bulky weight yarn;
…

Now that’s a knitting contract. Happy new year, all!

We’ve been discussing the problem of “dynamic web single sign-on” in the Project Concordia workshops and calls, knowing that the Ping Identity folks were planning to come forward with a proposal and anticipating that others would have feedback and possibly counter-proposals to offer.

Patrick Harding has posted some details of the Ping proposal just today. We’re hoping to refine some “dynamic”-related interop scenarios in the upcoming Concordia workshop on December 3 before IIW 2007b begins (if you’re attending the workshop, please add your name to the new participants list!). The timing is good to have some technical proposals to chew on.

For context, here’s some of the discussion we had on our recent telecon about this proposition:

Scott [Cantor] comments that Shib’s overriding interest is in getting products to interoperate. All the problems Patrick was talking about, Shib doesn’t have! (Except for IdP discovery.) He’d like vendors to be implementing “usable SAML products”. The most straightforward way of doing this is to separate the considerations of run-time trust operations and metadata exchange operations.

Shib is interested in creating a profile (likely in the SSTC) that deals with these considerations separately, constraining run-time behavior severely and makes metadata exchange a more open field for trust authority model experimentation. They want metadata to become self-describing and therefore implicitly trusted, which means getting rid of the PKI runtime (OCSP, revocation, CA, etc.).

Shib believes that everyone’s trust model approaches need to be accommodated, and can be if metadata is self-describing. Patrick agrees. Handling metadata out of band, manually, is a killer.

Eve asks if the intent for IdP (and metadata) discovery is for a user to walk up to a new SP, plug in their personal email address, and have the SP contact an IdP they’ve never talked to before in order to get metadata to allow them to set up a new relationship. Patrick says that in a B2B context, typically there has indeed been a business relationship already set up, and all that remains is to get the technical relationship set up. SPs already often see email addresses in the clear — but Eve notes real-life B2B use cases where the user’s identity must not be revealed. Is having a user simply provide a raw domain name feasible? Patrick observes that using information cards can also take care of discovery.

Scott comments that WAYF services don’t tend to scale across use cases where an SP interacts with a large number of communities. Unless we reinvent DNS, solutions tend to fall apart pretty quickly.

Eve puts in a plea for individual pieces of the problem to be solved individually (fine-grained) and then perhaps aggregated into larger chunks (best practices, conventions, profiles, deployment profiles, whatever) to solve particular interop problems. And we should look at doing some interop testing of some of these solutions at RSA, if we can. That will mean identifying one or more clearly distinguished scenarios, and possibly feeding them into any profiling efforts at the SSTC or elsewhere.

Here are some questions off the top of my head.

• It looks like Patrick’s mention of an “optional” email-address-based mechanism for deriving the metadata location is a nod to my plea for separating the pieces of functionality — I was particularly worried about depending on the sharing of PII like an email address to make this work (e.g., Sun’s most famous enterprise-outsourcing federation is with BIPAC, and there we keep the individual identities of Sun employees shielded from the service provider). Others have discussed just having a user provide the domain name of the IdP (sort of like in OpenID directed identity) rather than their personal email address. What’s most practical here?
• Scott has an interest in preserving the ability to use many different trust models. Does Patrick’s proposal achieve this? If not, how should it be changed?
• Is the scenario set/problem space correct? I don’t think it’s practical to dramatically extend it, but my BIPAC example above is straight down the line of the stated scenarios to be covered, except for the expectations of privacy.
• Something I’ve talked to Patrick and others about is how we can take the opportunity to ease negotiation around required/handled attribute namespaces through metadata. What scenarios should be included to cover this, if any?

It’s killing me that I won’t be at the workshop (I’ll be on vacation next week), so I expect y’all to figure everything out by the time I get back. OK? OK.

Running From Camera managed to inspire me — to start posting at TrayTable again.

The slides from the OASIS workshop at Burton Catalyst last week are up; mine are here. I’ve added a note about this to my publications page, where many of my previous talks are also available.

Dee Schur and the steering committee of the IDTrust Member Section of OASIS did a great job running this event! It was a pleasure working with them all.

Thanks to Tim, I just checked out the new blog by Stephen Fry. Who knew?? Fry’s blessays (as he self-consciously calls them) are charming and relevant to readers of tech blogs. This is just wonderful — more Fry! (Or will blogging be the siren call that distracts him from writing novels?…)

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?