Relationship cards

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.