My first thought after I saw this article? “What a cute cap, and such a pretty color — I bet I could crochet that in no time.” Help me…
Actually, so that this post wouldn’t be a total waste of time (though you be the judge), I dug up some patterns that might just do the trick:
Lady’s Skull Hat
Cool Crochet Skull Cap
Men’s Hat with Optional Chin Strap (with a picture that must be seen to be believed — just picture Calvin Broadus in this!)
Drummond Reed responds to my point of OpenID confusion kindly and informatively. It sounds like inputting the IdP’s address is precisely what the new draft does allow, along with having the user pick an identifier:
starting with OpenID Authentication 2.0, a user will have two options for logging into an OpenID-enabled site: with their personal identifier, or with the identifier of their OpenID provider (IdP). If the user chooses the latter option, the IdP will let the user choose the identifier they want to share with the site — anything from a specific persona to a one-time URL/XRI generated by the IdP just for this relationship.
This is an interesting way of going about things, no doubt driven by the essential notion in this system of a URL-based identifier that represents your digital identity. URLs are, of course, not only strings but also nominally communication endpoints, so if the user doesn’t know their URL, I guess it would defeat the purpose because they couldn’t give it out to people or services for use by them. Oh wait, if you share a “specific persona” I guess that means you are happy sharing one of your usual identifiers (in which case, couldn’t you have put that into the login field in the first place, saving a cycle), and then it’s not actually a pseudonym? And a one-time generated URL is a kind of a pseudonym, so you’re effectively saying you want to limit this relationship to just this small IdP/SP “circle”? So maybe that latter step is akin to SAML’s expectation that many scenarios will require user consent to the federation, though the notion of the URL/XRI also being a communications endpoint seems to go unused.
SAML’s use case for privacy-sensitive federation depends on an IdP and an SP being able to forge a unique triple that includes a pseudonym for the user, but the user doesn’t pick it or know it or share it, and of course SAML lets identifiers be in any format, including email addresses, plain strings, etc. (Particular deployments narrow that choice way down, of course.) Here’s SAML’s assumption about federation and its privacy requirements. This is a use case diagram taken from the latest draft of the SAML V2.0 Technical Overview; if it looks squished, click to enlarge:
This use case drives several different flow/pseudonym options, but a fairly vanilla approach is to (a) use a persistent pseudonym so that the relationship between the providers in serving the user lasts beyond a single session (vs. a transient pseudonym that lasts only for the session) and (b) ask the user in real-time for consent to the relationship (enterprise federation might not do this step since they can rely employer/employee relationship policy and contracts for this). Here’s how the flow for this might look; note that it doesn’t label the types of transport bindings used, but typically it’s HTTP redirect or POST:
I think Drummond and I are duty-bound to hang out in a coffee shop sometime soon and figure out all the common touchpoints between OpenID and SAML, because at the very least it will save some Babel-like confusion!
[UPDATED to fix extra space in diagrams. Also note that I’m in the middle of changing the sample provider URLs used in the Technical Overview, so if you check it out, you’ll notice some inconsistency there. To be fixed soon! I’m thinking of using cars.example.ca in honor of Paul…]
Many years ago, more than fifteen to be (somewhat) precise, I had a thing for crocheting. This obsession lasted long enough for me to finish two fairly nice blankets that I still use today (we won’t count the ugly potholder prototypes). I also managed to finish about two-thirds of another blanket, with the intent of giving it to my sister when it was finished.
My mistake? Telling her about it before I lost interest in finishing the damn thing. She never let me forget it.
So I’ve been carting around a blanket fragment for my last two house moves, in the course of which I lost the pattern. It’s not the most complicated one in the world — it’s a simple Vs-and-shells deal — but that didn’t help me want to pick up the whole thing again. In the meantime, I pretty much forgot how to crochet entirely.
My brilliant move? Going to visit Lauren. Watching her work on several knitting projects in timesharing fashion (one project for home, one project for the car…) inspired me to figure the whole silly thing out again. It helped that my sister’s birthday was approaching, and I was determined to surprise her with the finished article.
So while I hung out at Lauren’s place one evening, I clumsily re-taught myself how to do the basic crochet stitches, working from a wonderful book she loaned me, and over the next week I stitched away, reconstructing the pattern by staring at one of my completed blankets at home.
The result?
Blue crocheted blanket in Vs and shells
Blanket detail
When my sister received the package, her reaction was: “Oh, is this my potholder?” Snarky. But, I thought, the outcome wasn’t too horribly bad for a project whose schedule slipped into a whole ‘nother decade.
After this I really got the bug — both literally and figuratively. I found myself fighting a cold a couple of weekends ago, and couldn’t sleep. So I dug up some old yarn and a new pattern and made this overnight.
Testosterone-soaked scarf
I tried to make it as masculine-looking as possible, because my intent was for Eli to wear it. He seemed appreciative (but so far I haven’t seen it on him!).
I’m not sure what new projects I’ll pick up now. Unlike KnitBot, who has talent and hoarded yarn to spare, I have no yarn stock worth the name (and, uh, not much talent either). I suspect that the key is having some excellent yarn on hand and then running across an irresistible pattern. Actually, I’m thinking it would be cool to work in thread rather than yarn — lots harder on the eyes and fingers, but really pretty.
Pat Patterson went and did it: He implemented the Service Provider (relying party) side of SAML V2.0’s browser/POST single sign-on profile…entirely in PHP. A number of people have been concerned that SAML is somehow just too hard to implement, particularly with that nasty XML Signature bit, but I think this shows the concern wasn’t warranted. He was apparently inspired by the ease with which Kim Cameron implemented InfoCard in PHP; of course, that has a significant SAML token-handling component, so there are a lot of similarities in what you have to do underneath.
At the same time, Jeff Hodges and Scott Cantor have continued to improve their SimpleSign and Lightweight SSO specs for doing SSO using SAML in an entirely XML-Signature-free way. The best way to keep up with this work is to track JeffH’s IdentityMeme.org blog. (He’s also got a recent post surveying the landscape of IETF I-D references to SAML, and other handy stuff.)
The next thing I’d love to see (I should get off my duff and do it, or at least browbeat Peter Davis into it — he’s the main guy behind the specs for SSO using both i-names and SAML) is a very simple spec showing how to use Yadis as the metadata and discovery component for SAML. With this, you could not only use Yadis for identities that have non-URL, non-XRI identifiers (such as the millions upon millions of “legacy” identities out there), but avoid some privacy issues as well.
The security considerations section of Peter’s spec profiling SAML for XRIs contains the seeds of everything you need to know to pull this off:
The use of XRI’s for authentication service discovery introduces a new potential correlation handle of the principal. Authentication service providers should carefully consider the risks associated with this shared identifier.
One suggested remedy is allow the principal to only supply the XRI of the authentication service provider (eg: @IdentityProvider), and not their personal i-name.
(I tried figuring out if the OpenID V2.0 work includes this approach as a possibility for URL-based identifiers, and it appears to go part of the way, though the underlying purpose seems to be different. Revision 10’s Appendix C.1 says “Supports IdP-driven identifier selection. This new variation of the protocol flow is initiated by entering an Identifier for an IdP instead of an Identifier for an End User, and allows the IdP to assist the End User in selecting an Identifier.” But I’m having trouble finding where in the normative spec this is defined.)
All in all, I think Pat’s lightbulb metaphor is apt — lightweight identity, shining a light on the identity issue, having the lightbulb suddenly go on, I get it, I get it. Now, with the “gotta wear shades” song in my head, I just have to avoid the next step down into earworm hell: “I wear my sunglasses at night”. Oh no! Too late! Even worse, the lyrics actually lend themselves to security and privacy themes…
…from one example is generalizing from no examples at all. That’s one of the X Window System’s design principles, and one of my favorite quotes.
So it’s pretty cool, then, that along with the Liberty Alliance having finalized the second major version of its Identity Web Services Framework (press release, summary article), for the first time it has also published its marketing requirements documents (MRDs), which have helped shape its specs. The MRD for ID-WSF 2.0 is fleshed out with use-case details like “John is a coffee addict” and “However, Blodwyn is sick of South Wales” among the necessarily drier stuff. Check it out.
Gee, when it rains it pours here at Pushing String (hmm, no joking matter as we head into fall) — nothing for two and a half weeks, and then three posts in an afternoon?
The thing is, I did an interview with Aldo Castañeda yesterday for his Story of Digital Identity series, and I see that he’s just posted it (feed here). He’s a great interviewer, and I had a good time speaking with him. We’re already engaging in some interesting followup conversation about the role of UIs in allowing users to effectively express their policies when it comes to their identity information, and conversely, the ways in which conventionalized UIs can cause difficulties.
In the podcast I mention an exchange between me and Paul Madsen about how to improve informed consent by users; if you’re interested you can find the whole thread by starting here. I had thought that the UI idea he pointed to was a Shibboleth-using project, and it turns out my memory was correct.
I got to visit San Juan Island for the first time recently — yeah, I’m still a northwest newbie — to take in an end-of-summer weekend of fun and funk. The people who run The San Juan Preservation Trust booked Mudcat to play their Harvest Festival, and we had a most excellent time doing so. (Click on the pictures for bigger versions.)
Peekaboo stage with hay bales
I really knew nothing about the San Juan Islands before this. My old Boston mindset made it feel as though we were “going to Martha’s Vineyard for the weekend.” It took about the same amount of time to get there; there was a ferry involved; and all the rhythms of life slowed down as soon as we arrived.
We played at Lacrover Farm, where we had a lovely view out onto their acreage.
My view from the stage
Each band member — along with assorted family members, including kids and dogs — was offered a place to stay with one of the SJPT board members. Eli and I were “assigned” to Sven Haarhoff and Allison Shadday, and it was a pleasure to get to know these nice and talented folks. She’s an author who has a book about multiple sclerosis on the cusp of release, and he’s the SJPT development director — the guy to talk to if you’re interested in supporting their mission of protecting the San Juans through voluntary private action. (You can get a special-edition Gary Larson T-shirt for donating to the Save the Turtleback Mountain project!)
The band now has a solid three hours of material, and we played until it got almost too dark to break down our equipment — though the lack of light pollution was welcome! Not being an outdoorsy sort, until that weekend I probably hadn’t seen the Milky Way for years.
Feeling vine
Luckily, modern musical equipment is generally lightweight and easy to tear down. Once upon a time I lugged a Hammond M1 organ, though I gave that up pretty quickly. Maybe back then I could’ve made do with this antique “portable” organ I found in a Friday Harbor shop — I’m guessing that’s got a couple of pounds of weight per key.
Portable band equipment
This weekend we’re playing at an apple-picking party on Bainbridge Island. This music stuff is really taking me places…
Paul beat me to it — announcing my newly updated SAML Basics slides before I got off my butt and did it myself. I’ll swallow my pride and just thank him for the kind words…
I’ve been doing talks and tutorials on SAML since 2001, and having tried out this latest material on my XML Summer School attendees, I think it’s really strong now. I feel like I’ve finally got a better handle on explaining federation and how SAML can help you achieve it. We could really go to town with the speech bubbles, for example, using them to explain how to extend SAML to add your own kinds of statements, or describing the different constraints and interpretations that overlay an assertion depending on the profile context.
(I’m not sure what trouble Paul had seeing the animation in the source file, but I know that in OpenOffice.org you start the slide show and then space-bar through it; doing a page-down will skip any animation. If you want to see a flattened-out version, there’s always the PDF.)
UPDATE: I’d be remiss if I didn’t also thank Paul and JeffH for their comments on this latest version.