Pushing String

Nice TechTarget article describing Pat Patterson’s work on Lightbulb. (Watch out, though — as of right now, they still have the OpenSSO link wrong. Try here instead.) He’s everywhere these days!

Everything is happening so fast, I’m definitely feeling one of those “singularity moments” coming on. Johannes made a great volley in our little game of ping-pong (blig-blog?) but I haven’t even had time to read it properly. Hopefully I can respond in a thoughtful manner tomorrow. (”Picks apart”, huh? You asked, I merely answered! :-) )

Hey! Jonathan Schwartz likes unconferences. He also likes startups itching to break out of the pack. (Tim comments here.) Indeed, the two seem to be a natural fit. I’m just impressed that he can get through the whole post without invoking the long tail — or the participation age.

If you’re in a startup and plan to be in “tomorrow’s Fortune 500″, check out Jonathan’s post to find out if you qualify for some wicked good deals Sun has on offer.

Fascinating bit of analysis from the ConsortiumInfo.org Standards blog, as part of a status check on the ODF implementation strategy in Massachusetts:

Q: It seems like anyone who supports ODF in government disappears, how to say, quickly. Is supporting ODF a career-ender?

A: No. While it’s true that two Massachusetts CIOs took stands of principle and resigned their positions (on which more below), neither individual was fired or forced out. In fact, the open standards policy that includes the ODF conversion was originally endorsed by Massachusetts Governor Mitt Romney. Romney has consistently supported that policy in general, and (once it entered the news) the ODF conversion in particular, from the time it was first announced until this day. His administration promptly issued public statements after each resignation stressing that the conversion to ODF would move forward. It’s been common knowledge that Romney is considering a run for the U.S. presidency, so supporting ODF can hardly be considered to be a dangerous move for a public official. Decommitting from it, however, might be seen as giving in to special interests.

UPDATE: Oops, I was behind in my reading after returning from vacation. It looks like the giving-in has already begun.

Eeugh-Buh, that is: the second 2006 Internet Identity Workshop, more commonly known as IIWb. It’s being held next week in the Bay area. If you’re attending but haven’t added your name to the list, better do it soon! I’m arriving in town on Sunday night and am really looking forward to this one.

Johannes mentioned that there are a bunch of ideas swirling around on mashing up OpenID and SAML. Some of my recent posts have been poking at perceived impedance mismatches between the two technologies, in order to learn where they’re usefully complementary. I’m really excited about the possibilities here, and like Johannes, I’ve been pleased at people’s willingness to work together, whatever their mental starting points. So let me respond to the challenge he posed (”If you have an opinion on this, why don’t you blog about it?”), taking the positive side.

If we (somehow) mashed-up SAML and OpenID: Who would care, other than technologists? Why would they care? Actually, technologists who are in business to compete with each other would typically be just as happy to have competing protocols, though I think this stance is very short-sighted. My customers tend to resist deploying multiple technology stacks that do the same thing; mashing them (uh, the technologies, not the customers) up to unify common functions can potentially simplify deployment and give the benefits of the union of the use cases served by the technologies in question.

What problem does this solve that cannot be solved any other way? It’s always possible for a technology provider to offer coverage of multiple technologies, which can give interop in the context of their product (or open-source library or whatever). But that’s less universally interoperable than actual protocol-level bridges that everyone can implement equally. Also, the very notion of mashups involves play and experimentation, and we should be pushing this opportunity out to the individual level wherever possible. Providing a framework for doing this can be very “generative” (that is, we’ll learn more interesting use cases as we go, from every quarter). Plus, it’s just more fun this way. :-)

How valuable is a solution to that problem, compared to the cost of delivering the solution? I guess we won’t really know until we try. But every time I’ve been involved in what could be called “convergence” activities in the context of open standards development (and I’ve been doing it since 1991), it’s been gratifying and worth the effort — and it resulted in increased adoption. Hey, OpenID has already undergone a rapid mashup cycle with LID and Yadis, and SAML did the same (though admittedly not quite that rapid) with the Liberty Alliance federation framework and Internet2’s Shibboleth. If we discover that OpenID and SAML have any use cases, requirements, and solutions in common at all, isn’t it worth exploring them?

Johannes thoughtfully addresses the questions I posed on OpenID identifier matters. Here are a few more thoughts in response.

I suspect the world doesn’t have enough aggregate experience yet to know how people will use their (one or more) identifiers; the promise implied in the notion of having many URL-based identifiers governed by oneself hasn’t been thoroughly explored yet. So the NetMesh answer to question 1 is probably reasonable for now, but might break down if people become enamored of inventing their own pseudonyms for various purposes.

I generally agree with Johannes’s comments about the difficulty of keeping users safe from themselves. I was poking at this issue because in the SAML universe, the user would typically never touch a pseudonym, so we have this as an existence proof of good privacy management. That’s where my second question was crucial: If OpenID is happy to allow users to provide only their identity provider’s URL to the relying party, then a bunch of good privacy things can flow. Thus, I think I disagree with his point about privacy levels in the pseudonym case vs. the well-known URL case.

To explain this, I need to delve into the universe of URL-based identifiers further. Here’s the taxonomy that’s currently floating around in my head:

• A digital subject is (to make a simplifying assumption) a natural person, such as…me, Eve Maler.

• A digital identity is a set of identifying info about me represented by a single identifier (OpenID makes this a resolvable URL). It presumes a set of “profile management” (attribute/claim provisioning) tasks that I undertake with the provider of the identity verification (authentication) services through that identifier, whether that IdP is on my own server or someone else’s. I can choose to share this identifier with relying parties in order to get verified (and, with technologies such as SAML today, also get my identifying attributes shared across). One of my digital identities might be keyed off of a URL like, say, http://www.xmlgrrl.com/eve.

• I, a digital subject, may have multiple digital identities, keyed off of different identifiers, which may be verified/managed by the same IdP or by different ones, and which only I (a human) can correlate — any one IdP cannot 100% safely calculate or assume “they’re all Eve”.

• A persona (I’m clearly insane getting into the persona swamp again) is a “view” onto a particular digital identity, managed by the IdP for that identity, keyed off of an alternate identifier supplied by me and associated with various bits of policy about what info about me can be shared and with whom. The value of these would presumably be that humans will know about their own persona URLs and supply them to RPs, and so these would be well-known, not secret. I don’t think we have much experience to speak of regarding persona URLs, but people do this with email addresses all the time (and most of us have multiple ones) — e.g., I declare on my site that if you send mail to eve-at-xmlgrrl.com, I will deem it to be bloggable unless you indicate otherwise. I can imagine using http://www.xmlgrrl.com/xmlgrrl (vs. …/eve) to correspond to the sharing of a relatively “safe” set of attributes with a relatively broad set of RPs.

• An IdP always has a well-known identifier to facilitate my ability to avoid sharing an identifier of my own directly to an RP; as Johannes points out, this is a feature of the emerging OpenID 2.0. (If we were talking heavyweight web services, the IdP identifier would serve as something like an “endpoint address”.) Hmm, extending the notion of personae, I can imagine IdPs having “personae” (alternate URL identifiers) that would correspond to different sets of per-IdP policy that I want to activate (e.g., logging or RP authentication) when supplying that URL to an RP, but now I’m getting into generalizing-from-no-examples territory…

• A pseudonym is an identifier that is designed to be secret and to be the key for a particular triple of an IdP, an RP, and a digital identity for some short or long period of time. The IdP knows which digital identity (or persona) is being invoked, but the RP only knows the pseudonym, which allows it to talk about “the same” identity with the IdP (and no other web app) — it’s anonymous correlation of a limited sort.

Johannes says:

…the relying party necessarily needs to have some kind of “handle”, relative to the identity provider, that uniquely identifies my account there, as opposed to somebody else’s. (Otherwise I would get their shipments, or they my invoices.) By concatenation of the identity provider URL and the local handle, we arrive at the same privacy (or lack thereof) as in case of using the identity URL in the first place.

If the “handle” has to be a URL (e.g., it’s constructed by doing the simple concatenation described above), then yeah, this is inherently not particularly private — though I can imagine constraints that the protocol could place on the RP’s sharing of the URL, rules about doing mutual auth when resolving it, etc. But I see no structural reason for it to be a URL; the RP can get it from the IdP as part of the exchange of identity verification information. (This is, in fact, how SAML does it when a pseudonym is requested.) Since the purpose of a pseudonym (defined to be secret) and a URL (the currency of the open Web) are at odds, there might be a bit of relief in relaxing the notion that a pseudonym has to be a URL, while assuming that persona URLs can always be made public.

So, what do folks think about this idea? In the meantime, it’s back to yarn-hunting for me. :-)

I can only imagine what sorts of attention this post title will generate, but here I’m merely providing a short book review (she said, batting her eyes innocently).

While visiting my husband’s family in south Florida, I found a good local yarn store in which to perform a yarn hunt. By the time we arrived in town I had managed to generate a blanket and three scarves for gifts, and with yarn purchased at the LYS, I’ve already created a fourth scarf while hanging out on holiday. (Pix to follow eventually, I hope.) I also found a copy of the new book Stitch ‘n Bitch Crochet: The Happy Hooker. (If you thought I was referring to this book, get your mind out of the gutter.)

I now own several dead-tree-based resources that explain the basics of crocheting, as well as having studied numerous websites and recently borrowed Crocheting in Plain English from Lauren. No one resource seems to have all the answers nor does a perfectly good job of the ones it does provide. Plain English has a wonderful friendly style and good advice about crocheting paraphernalia, whereas Happy Hooker is breezy — okay, even saucy — in style and excels at the explanations and pictures for basic stitches and other tasks. (I’m afraid the English isn’t quite Plain enough for me in the other book when it comes to actual instructions.) Neither bothers to reverse the explanations and pictures for the left-handed — which I am — but I’m used to that now and I just reverse everything in my head. Isn’t that one of the tests for Mensa or something?

Hooker is the first book that’s gotten me to try fringes and add new yarn in the “approved” fashion. Here’s a passage that provides one key piece of information, without which I’d been having a rougher time than necessary. It’s from a section called Swinging Singles:

If you examine the last row of stitches you made, you’ll see that a single crochet stitch is three-dimensional and, seen from the front, looks like a V with another V lying across the top of it, sort of like a lid. In fact, you can think of your crochet stitches as being a bit like a to-go cup of latte from your favorite java hut. A single crochet stitch is a short shot, while later on you’ll learn to make taller stitches — more like those grande and venti cups. They’ll always have that lid on top, though, just like all good coffee does. Also, observe that the “cup” Vs are not stacked directly on top of each other, but are a bit offset, which is probably just how you’d stack ‘em, too, if you had to make a wall of coffee cups.

Hooker suffers from the same structural difficulty that lots of other crochet books do: Many complex crocheted items look kind of frumpy, no matter how beautiful the models you put them on, so lots of the patterns are things I probably wouldn’t make (a cowboy hat??). But it does offer a skull pattern that can be applied to sweaters and bags, and even has some fun with a purposely ironic crocheted anarchy symbol. These patterns ratchet up the coolness factor quite a bit. If I’m ever going to get past crochet kindergarten, I think I’ll have to do it with a Jolly Roger sweater.

Especially if you read Planet Identity, you’ve probably already seen Pat’s and Dennis’s [UPDATE: and how can I forget Hubert’s??] excellent posts announcing Open Federation, which is the addition of code for identity federation and identity-based web services to the OpenSSO project.

In order to make this something other than a “what they said” post, I just wanted to point out some interesting bits in the newly available documentation.

The architecture doc has all kinds of hardcore goodies, and its Section 3.2.3 illustrates the multi-protocol (dare I say metasystem-y?) nature of the code base:

Open Federation Library provides a pluggable framework for Identity Federation and Web Services. Followings are the list of industry standard supported in Open Federation Library implementation:

1. Liberty ID-FF 1.1 & 1.2, including SP/IDP extended profiles.
2. Liberty ID-WSF 1.0 & 1.1.
3. OASIS SAML 1.0 & 1.1.
4. OASIS SAML 2.0.

Features to be supported in future releases of Open Federation Library:

1. Liberty ID-WSF 2.0
2. WS-Federation Passive Requestor Profile
3. WS-I Basic Security Profile

To achieve extensibility and customizibility, a list of Service Provider Interfaces are provided in each standard implementation to satisfy different deployment use cases. A set of common Service Provider Interfaces used by all components are also defined to integrate with existing authentication, configuration, session, logging and data store infrastructure.

And it’s interesting to peruse the table of contents for the use cases doc, which includes these federation use cases:

UC001 : Persistent Federation
UC002 : Attribute Federation
UC003 : Transient Federation
UC004 : Transient Attribute Federation
UC005 : Transient Attribute Federation without Individual SP Account
UC006 : Attribute Federation with Auto-creation of SP Account
UC007 : Bulk Federation
UC008 : Single Sign-on Initialized from Service Provider
UC009 : Single Sign-on Initialized from IDP (Unsolicited Responses)
UC010: Single Sign-on with Attribute Sharing from IDP
UC011: Single Sign-on with Attribute Sharing from SP
UC012: Single Sign-on with Attribute Sharing from IDP side Application
UC013 : Single Sign-on with J2EE Declarative Policy Integration
UC014 : Single Sign-on with Web Agent Integration
UC015 : Single Sign-on with Authentication Context Mapping
UC016 : Single Logout
UC017 : Name Identifier Registration
UC018 : Federation Termination
UC019 : IDP Proxy
UC020 : Name Identifier Mapping
UC021 : IDP Discovery/Introduction
UC022 : Establish Trust
UC023 : LECP/ECP

and these identity services use cases:

UC001 : Web Service Authentication
UC002 : Discovery Query
UC003 : WSP Registry with Discovery Service using B2C model
UC004 : WSP Registry with Discovery Service using B2E model
UC005 : ID-PP Query
UC006 : ID-PP Modify
UC007 : RedirectRequest based Interaction
UC008 : Developing and Deploying Web Service Provider

Check it out…

I remarked last month on the effort by the San Juan Preservation Trust to “save Turtleback Mountain” on Orcas Island. Well, it looks like they’ve done it! I think this is a great model for conservation, a lot more agile than a one-size-fits-all government program. In fact, this project was taken over from the Nature Conservancy at one point when the latter decided to focus on what they felt was a more pressing need according to their lights. Local folks had an incentive to get the local effort going…and they succeeded. Well done.

In honor of the property’s being opened up to hikers in about two weeks, I suppose it’s finally time for me to come into compliance with Washington state law and choose an outdoor recreation. Seriously — as soon as I moved here, everyone from friends to colleagues to doctors asked, “So, do you hike? bike? snowboard? what?…” The answer was No to everything.

(We did acquire bicycles, which gave us some protective coloring, but I haven’t ridden a heck of a lot yet. Mine is an Electra Townie that looks like the silver-and-red one here. It’s wicked comfortable — and it looks like it should have an old-fashioned banana seat and handlebar streamers. Don’t worry, I forbore getting the wicker basket with the plastic flowers. If I actually climb on the bike more than twice this winter, I may have to declare it on my state-mandated Metronatural Recreation Attestation Form.)

There’s been an interesting discussion on the OpenID general list (the thread starts here under ‘concerns about each user having a unique “URL”‘) about the need to allow a user’s identifier to be private. If you someday have a grand convergence of all your identities onto The One True URL Representing You, you may be sharing more information with OpenID-enabled web apps than is desirable.

Of course, secrecy of unique identifiers is an old idea, entwined with anonymity/pseudonymity goals. No one wants The One True URL to be of the form http://www.us.gov/SSNs/123-45-6789. And in systems that are cross-domain but don’t need to be Internet-wide, often great care is already taken not to uniquely identify users, such as in the Sun-BIPAC usage of Liberty Alliance-based federation and web services. So this definitely seems like an interesting confluence of use cases in the URL-based and SAMLish areas.

I last tackled this topic under the name Pseudonym picking, where I tried to do a compare/contrast between OpenID and SAML on this point based on what I was learning from Drummond. Unfortunately, I did an extraordinarily confused job of it. Reading it again, even I don’t understand it, which is pretty bad. But since I ended up giving it another try in the mail thread, I thought I’d share some of that here in case it’s useful. So consider this a sort of V2.0.

Here’s my understanding of the different motivations you might have for not supplying a particular URL that uniquely identifies you directly into the OpenID dialog box at a web app:

…there can be two reasons why you might want to tell the relying part what IdP to go to but not hand the relying party your identifier at that moment. The first is that you can do what I might call “late binding” of your choice of digital identity over at the IdP, which lets you pick the specific persona you want to use. The persona might or might not be associated openly with a natural person…

The second is that you never want the relying party to have a “real” identifier of yours, so that you can arrange with the IdP to pick “a one-time URL/XRI generated by the IdP just for this relationship”. This pretty much follows the textbook definition of a pseudonym…

Note that once you go into persona-land, there’s a continuum of possibilities about how private that URL really is. OpenID seems to leave the pattern of repeat usage of URLs entirely up to you.

And here’s my attempt to map these situations to SAML:

The typical SAML single sign-on flow doesn’t involve the user handing the relying party their identifier; only when redirected from the relying party to the IdP they authenticate as “someone” — and of course, if they have multiple digital identities managed by that IdP they’re free to choose whichever they want at that point. This matches the first situation above: late binding of identity-choosing. It would be similar to users always supplying merely an OpenID Provider URL to relying parties. SAML doesn’t prevent your providing additional information to the relying party, like the desired identifier to authenticate you against, but it’s not needed in order to have the relying party ultimately “let you in”.

If instead the user agrees to the relying party and IdP setting up a special relationship with each other and her, explicitly for her benefit (called “federating” in SAML), the identifier that passes between those parties is typically a privacy-preserving pseudonym (one-session or long-term), and the user never sees or picks it. This sounds quite close to the one-time URL/XRI situation above, except for the user knowing/not knowing the pseudonym.

(My original post had a couple of graphics showing the SAML use case for privacy-preserving federation and one of its technical options for achieving it.)

Now for a little probing into the OpenID functionality…

First question: If I already know what public persona I want to use with a web app, can I give them the persona URL directly? (I’m assuming that if I’ve got a bunch of them and can’t keep them all straight, it’s useful just to get over to my IdP and pick one from some kind of drop-down interface or something.) I have to say that I find the SAML flow more elegant: the web app initially doesn’t need to know anything more than where to take me to get me authenticated properly, and the resulting “yep, she’s authenticated” info that flows back to them in due course will include whatever identifier of mine is appropriate for them to see.

Second question: Is there a way to ensure that I, the user, can’t abuse/ruin a “private” identifier created for security purposes? It’s cool to let me be in control of the pattern of repeat usage of persona identifiers so that I can organize my online interactions on a per-persona basis, something I already do with email-based identifiers at a number of sites. (Perhaps it could also allow me to detect inappropriate “identity leakage”, similarly to subscribing to magazines with a phony last name — “Name on the subscription? Put me down as Eve O. Bscuresports-Quarterly” — and doing list salting.) But if I want to ensure that an identifier never gets reused, it seems best if I never know it, particularly if it’s in easy-to-remember URL/XRI form.

This time I think I haven’t lost myself along the way, but if I’ve still lost you and you’re masochistic enough to want a V3.0 (or sadistic enough to want to take a cluebat to me), let me know!

MORE: Johannes discusses the essential nature of having yourself be addressable on the web to exist. Though it took some time for me to get my head around it, this now makes a ton of sense to me in the open-Internet context (and heck, that’s why we made the very first design goal of XML be XML shall be straightforwardly usable over the Internet). However, if you want to allow for an anonymous-authorization use case or for any level of privacy at all with something like OpenID, is it sufficient to make the identity provider addressable?

A sordid tale of broken hearts and broken encryption. Sometimes it’s fun to be an Eve in this business and sometimes…it just hurts.