My (current) understanding is that R-cards are used to establish a long-lived, secure & privacy-respecting 'identity pipe' (or is it a bus?) between some entity that holds a user's identity, and another that wants those attributes. Unlike the relationship enabled by 'normal' cards, the R-Card relationship works even without the user's explicit participation/mediation at the time of sharing. (how about a name that reflects this distinction, e.g. Direct-Card, Silent-Card, etc?)
What R-cards don't do is define just how the identity actually flows, i.e. what are the specifics of how the requestor asks for the attributes, in what format are they passed, how can the requestor subscribe to be notified should they change etc.
That's where something like Liberty ID-WSF is needed, because ID-WSF defines just this sort of plumbing.
Fundamentally, to get things going for ID-WSF, the requestor needs to get a WS-Addressing EndpointReference (EPR) (as profiled by Liberty) for the user's Discovery Service. Once armed with this DS EPR, the requestor would be able to obtain the EPRs for particular service types, e.g. contacts, calendar etc.
The graphic below portrays this simplest case.
As modelled, the originally provisioned card does not capture a semantic of 'this attribute is stored at this provider' but rather 'This card can be used to discover where the user's attributes are stored'. Is this weird?
Tags:
No comments:
Post a Comment