But, now I see Kim Cameron reference a Mike Beach post (or comment?) with the following
This doesn't jibe with what I know (or misunderstand) of Cardspace.
In the privacy space a colleague of my shared an interesting perspective. Most corporations, especially in the B2C space, have considered user/customer identity data to be an asset. Knowledge about their users that could be leveraged for any number of marketing opportunities. With the rising concerns and increasing regulations around privacy this perspective is, or should be, starting to change. This “asset” is now becoming a liability. Data about people (corporate people and consumer people) is always going to be required to do business, but how do we get that while at the same time minimizing liability? Enter the Infocard concept. It would seem we now have a means to establish authoritative data about the user, but give it to the user for safe keeping.(emphasis mine)
My interpretation of Mike's description above is that some TTP asserts (and thereby provide the authoritative identity) but the claim then gets cached by Cardspace for later presentation to a RP (the 'give it to the user for safe keeping'). This scenario would appear to be neither the (what I assume to be the default) flow of identity assertion created (at run time) and sent by the trusted 3rd party IDP to Cardspace for forwarding onto the RP, nor a self-assertion created by the local IDP.
Just when I thought I was understanding .....
4 comments:
From what I know, the InfoCard you present really depends on the type of transaction that you are trying to complete:
If you want to login to a site (say AmazingBooks.tld) and tell them where to ship your purchases, you would likely present a self-issued InfoCard, since you are in this case the authority. The RP would inspect your card, determine that its content is sufficent and take the relevant data into its order processing system.
If you then want to pay using your ServentCard credit card, you will use the TTP issued card in the way you described. WCS will NOT (as far as I know) cache high value information (like e.g. your card number) on your local machine, but only the security relevant portions.
Gerald Beuchelt
Gerald, right, local IDP when the information is that which users currently provide themselves through form fill; TTP when that's insufficient. It's the implication of caching that confuses me.
paul
My prediction: Self-issued cards will form the majority of the cards in a person's 'wallet', with managed cards only being used for transactional data whose content requires some level of surety.
Most Relying Parties only need surety on the identifier. Self-issued cards have been architected to have all sorts of cool features surrounding the identifier, or PPID, such as presenting a different PPID to every Relying Party that a given card is linked to to prevent inter-site correlation. Such technology would have to be built into an IdP. Self-issued cards also have a limited but known schema - this makes integration for a Relying Party easy, and I expect this will be the default use case, toolkitted and adopted with little inside knowledge needed.
For an RP to accept assertions via managed cards, they must negotiate fields and certificates (among other relationship bits) with an IdP. This will be useful if you must have surety for something (metadata for example) about your clients such as age, fico score, etc. One interesting possibility where managed cards might replace the simpler functionality of a self-issued card would be the case where an IdP starts to develop reputational meta data. This could possibly make it worth the extra work for an RP.
There are tons more reasons to use one vs. the other, it should be really interesting to see how the distribution settles out.
Cheers,
Pam
Paul -
From what I know, WCS will not (necessarily) cache attributes for managed InfoCards, but instead only provide a way to access them and allow them to be accessed by the RP. I'd be happy to go through some of the implications, if you like to: beuchelt at sun dot com.
Gerald Beuchelt
Post a Comment