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.
I won’t re-read the spec right now, but it seems to me that there’s nothing in the infocard definition that requires that all data encapsulated within a card have the same authoritative source. An IdP could assemble data from multiple, distribute sources, n’est-cs pas? Of course, the static nature of the infocard is a stumbling block, but it should be possible – in a future version – to implement secure, dynamic managed cards I would think. Think “virtual card,” perhaps.
Hi Dave– I got the impression, from hearing a description of what r-cards have to do internally, that there are currently some limits on the allowable combinations if you stick with the infocard protocol as she is spoke today. Something about self-issued plus one managed card provider as potential sources?… Obviously it’s ideal for there to be no constraints if what one is doing is building a “data-sharing relationship”. (I’ve got another post brewing on what those potential sources could look like.)