Pushing String

Lately I’ve been discussing three human tendencies we should take into account in designing identity-enabled systems: new-relationship energy, the efficiency imperative, and the self-revelation imperative. I’ve put aside the privacy imperative (essentially the opposite of self-revelation) because it seems more interesting to discuss challenges to privacy by examining the forces working against it.

I just got a handy reminder that whatever privacy imperative we have is, at least in part, learned rather than innate. In going through a storage-roomful of boxes to stock some new bookcases, I came across a calligraphy instruction book that’s more than 20 years old. I’d gotten it second-hand, and its previous owner had claimed ownership of the book and practiced his italic in one swoop by writing his name and his social security number inside the front cover…

In my talk at the Burton Catalyst conference earlier this week on The Care and Feeding of Online Relationships, I presented a brief argument for specific requirements on relationship management solutions.

My appreciation of these requirements has deepened through conversations with Bob Blakley (who kindly invited me to speak in his track — Bob, you should blog more!), people involved in Project VRM and Internet2, customers, Sun colleagues, and others.

I’ve noticed that when I present on “everyday identity”, usability folk come out of the woodwork, excited that someone is talking about Don Norman’s work, human-centered design, HCI, and the like. Luckily I have a real expert like Jen McGinn to keep me honest… I think we’d all benefit from listening to usability experts more closely.

(The title of this post is taken from the lovely Flickr photo that I borrowed for the first slide. Thanks, hojusaram!)

Eric Wilde and Bob Glushko have produced a wonderful compendium of problems people have with XML due to overblown expectations or plain old misunderstandings: XML Fever. It’s funny because it’s true!

(And hey, don’t forget about authorial illnesses like Tag Abuse Syndrome [see Sec 4.1.2.3], for which markup models can be carriers…)

Ooh, cool — Wordle can make word clouds out of anything.

This is the Venn of Identity article, Wordled (Wordlified? Wordlimicated?). Can you find the “SPs” in this picture?… At least the “user” is well represented!

Check it out — OASIS has added a SAML entry to its growing list of XML.org community websites for its Standards (press release), and Sun is a proud sponsor. I’m not exactly sure why there’s a space instead of a dot between the SAML and XML part, but the official name is SAML XML.org.

The Security Services Technical Committee is in the middle of doing a refresh of our original public home page to ensure that there are no missing tidbits of info on the new site. Also check out our working-area wiki if you want to know the status of various docs in progress.

This is also a great juncture to announce a Call for Profiling Intentions. A what?? Let me ’splain.

In the post-SAML2 era the SSTC has fielded many requests to take up profiles, bindings, and extensions based on real-world experience — things like SimpleSign for less digital signing overhead, an alternative method for IdP Discovery, and an Attribute-Sharing Profile that’s X.509-friendly.

I know there are at least a few other profiles-in-waiting out there, so in order to manage our docket better over the next few months and ensure that these new specs are designed cohesively, the SSTC is asking you to give us a heads-up on your plans.

Just drop me a note with a proposed title, short abstract/motivation, and the anticipated date of your initial contribution — and if you’re doing any kind of profile on your own and plan to seek the SSTC’s advice, let me know that too. I’ll coordinate upcoming schedules with our co-chairs Brian Campbell and Hal Lockhart and with you.

Please get in touch by Friday July 25 so we can get our next round of work mapped out.

Share and enjoy!

I’ve seen the Queen musical We Will Rock You three times and own the soundtrack. I’ve already admitted an unhealthy obsession with Bohemian Rhapsody. But I’m not so much of a groupie that I follow the touring show around. And as far as I can tell, this email message I just got — entire contents shown below — was not specially directed to me.

So yeah, it’s spam. And they’re not going to get a ticket sale out of me anyway. But cool poster, huh?

The organizers of the conference on Managing Identity in New Zealand have made available videos of all the keynote talks and breakout sessions. Go you and take advantage of this valuable resource… (I was told the videos only work with IE, but I found them to work okay with Safari on my Mac with only minimal weirdness around slide syncing.)

While you’re at it, you might want to check out the Radio NZ audio program prepared during that week on the topic of The Digital Shadow. They interviewed Dick Hardt and me for that while we were there; that was fun to do, and it’s a thoughtful program. Vikram Kumar has further comments on it here.

Swamped with meetings at work? Getting sick of all the company rules, pointlessly close parsings of email messages, and PHBs? Maybe someone is executing a denial-of-service attack on the business! (The instructions are real; they start on page 28 of the linked manual.)

Joe Andrieu describes his “ah-hah” experience about r-cards (”relationship cards”) at the recent Internet Identity Workshop and Data Sharing Summit. I was glad to catch the DSS r-card session; I’d heard about r-cards at previous events but didn’t really understand them, and this was their debut in demo form.

I think Joe is right about their potential power. Like him, I also wonder if the name properly captures what’s going on. Here’s my take…

R-cards offer two fascinating features:

• They aggregate a set of claims for you to offer to a particular relying party, potentially from multiple sources. Joe riffs on names for this: “dynamic cards or aggregate cards or mashup identity cards”.
• They allow a relying party to subscribe (my word, not theirs, I believe) to that set of info, so that you can make changes at each source that can be picked up by them later (even while you’re not logged in to them).

Joe’s second big point is that, by virtue of offering these features, the selector interface provides a natural home for managing the authorization policies you want to impose on each relying party for the usage and further sharing of whatever data you give it. This goal resonates perfectly with my calls for “relationship-forging” interfaces (vs. further overloading login-time interfaces).

So far, so good!

…But I do have some discomfort around the name, for two reasons.

First, the “card” metaphor seems an odd choice if you compare r-cards with regular infocards. Normally, cards are conceptually tied to a single identity provider, and the idea is single sign-on-ish: to reuse the same identity info over and over with multiple relying parties. It’s invoked when you try to log in at the relying party to get service (and that’s when you’re given the opportunity to consent to data transfer, according to the prescribed ceremony).

R-cards, on the other hand, are conceptually tied to a relying party, and they have a set it and forget it quality about them: the relying party can pull data from identity providers even if you’re not around. While this behavior is par for the course for identity web services frameworks that shall remain nameless (*cough* ID-WSF :-), and also lines up well with other pub/sub approaches being discussed lately, it seems like a pretty big change for infocards.

Second, it would seem that both kinds of cards reflect a relationship: one with an identity provider (maybe call it a “data-hosting relationship”?), and one with a relying party (a “data-sharing relationship”). So both are “r-”, in a sense! And I think we’d be missing some opportunities if we didn’t recognize the parallelism here, along the lines of Bob Blakley’s recent proposals: your you+IdP relationships benefit from management and policy-setting just like your you+RP relationships.

All in all, r-cards are an interesting development and I look forward to hearing more.

How not to handle forgotten password recovery flow during a massive promotion. A big fat reminder that people who are free agents on the web will go elsewhere if they hate your interface…

And I had somehow missed the earlier post he links to — excellent point. And don’t miss: