Udell on Identity 2.0
Jon Udell (another one of my heros) watched my OSCON talk and blogged about it. Once I got over the excitement, I read his comments, which includes:
… while the presentation is a great introduction to the topic of user-centric claims-based identity, it says little about how the Sxip implementation works, and what kind of user experience it entails.
In other words, “Where’s the beef?” Great question, but it is not the one the talk was designed to answer. In the past, I would explain how Sxip worked, people would sort of understand, but would not get why it was important. The objective of the Identity 2.0 talk was to answer the question, “Why should I care?”.
But don’t worry, the sequel will answer most of Jon’s questions! Right now I am not sure which challenge is bigger — adding more beef, or topping the presentation style sizzle.
digg this
del.icio.us this
Sure the Sxip solution was missing from the talk but it came off as intentional. I bet every single person who watched the video of that talk went straight to the Sxip website.
The talk was brilliant. Established the problem. Established Dick as a guy from Canada, from BC who studied at UBC, lives and works in Gas town and knows the problem intimately enough to succeed at fixing it.
The talk engaged the mind and left you wanting more.
I agree that most people don't need or want to know how the plumbing works. They do very much need to see the user experience, and understand how and why it will differ from the one that was so compellingly visualized by the ACLU, and that has defined what a lot of people actually expect digital identity to become.
As I said, to the extent that I can help create these visualizations, I will.
Hey Jon, finally got our response feature in. Hopefully you see my response here. :) ... I totally agree that showing the user experience is critical for people to get an understanding. I have been thinking about how I can make that interesting. A successful interface would be as transparent and intuitive to the user as possible, which also means it may be rather boring, which won't really entertain people. The ACLU was great since it got people thinking. Thanks for the offer to help, I will be taking you up on that!
Perhaps more important than the plumbing details, many will be concerned with dependancy on Sxip. i.e. succinct, clear answers to "how is this better than Passport, replacing Microsoft with Sxip?"
SXIP allows any site that has a trust relationship with the user to manage the users identity, or for the user to manage it themselves. Sxip is just supplying the plumbing, and SXIP 2.0 is archetected so that the protocol can be used without Sxip being involved at all. Stay tuned!
I loved the talk, and didn't miss the details about the implementation. What I didn't get is the requirement. The clerk in the liquor store didn't need to know Dick's identity, didn't care about Dick's identity, didn't use Dick's identity, but Dick proved his identity.
All Dick needed to buy his vanilla Stoly was the authorization to buy liquor. To do that, the only aspect of Dick's identity that he needed to prove was his age. Instead, he proved that he is Canadian, lives in Gas town, and is old enough to by vanilla Stoly. (Notice that he didn't prove that he went to UBC, etc.) Maybe the clerk missed the humor in the South Park movie and blames the Canadians. Dick could be in a lot of trouble.
I have a hard time coming up with examples of where it's necessary to prove identity. In almost every case, proving authorization suffices.
Dick's age is part of his identity, though. I thought that example was a beautiful simile to explain why it's important that identity be based on the user, allowing multiple registrars to validate without having to participate in transactions.
What's still missing is a strong demonstration of how Sxip enables this. (Perhaps a sister registry to sxore, labeled by someone like Technorati?)
As to sharing identity beyond the authorization litmus tests we've come to expect: I believe the use cases are endless. If you elected to share upcoming event registrations with Amazon, it might suggest books related to a conference you're heading towards, or recognize that you live south and are traveling to Chicago in February and suggest coats. Google Maps could notice I have a Starbucks account and default to marking locations. I could go on ad naseum...
Authorization vs identity raises some good questions. Authorization is a facet of identity based on identity characteristics, so perhaps Identity 3.0 is simply passing a verified "checksum" that proves authorization but provides no other useful information. (Insert pic of SPAM)
It also brings up the issue of defined elements of authorization. In the referenced example, it's not so much that Dick is authorized to buy the Stoly ... but rather that the clerk is authorized to sell as a result of the perfunctory check of ID. It is when Dick provides more than solely the authorization facet of his identity that he also provides the opportunity to have a better customer experience (which, to a limited extent, his purchase selection suggests anyway).
IMHO a crucial element, and fascinating piece, of the presentation was the distinction not only of validating authorities (Federal, Provincial etc) but also the scope of identity information disclosed by each piece (or package) of ID -- potentially ranging from strict 'authorization to transact' to full sharing of, say, active passport visas and network of friends and CV in the case of using identification to look for a new position (or funding for a new venture). User selection of the ID package, especially when the authorization to transact is an independent module of the package, is very attractive. It would enable the user to mimic the scope of purchasing experiences in the real world, from an anonymous purchase (ID modules: authorization to transact, perhaps a single use pre-funded Paypal account, and a Fed Ex Pick up code for delivery) to a full long term relationship development type transaction -- think retirement investment advisor (ID modules: age, income, health, life priorities, risk profile, family, etc etc).
Now, who decides what are necessary and sufficient ID modules to transact...and how does the user keep a greedy marketer (SPAM anyone?) from demanding more than is truly necessary?
Good analysis Steve. Providing information is part of a trust relationship. With a move to programatically providing the data, your "agent" that is managing it can warn you about how much you are providing. If we can define a programitic privacy policy, then your "agent" can contrast your personal privacy policy against the requesting party, and alert you to exceptions, since few people take the time to read the privacy policies of a site.
I think if you understand the issues Dick put out in that presentation, you understand (to a certain point, at least) how it can be used.
Here's how I understand portable ID to mean:
Say I have an eBay account, but no Flickr account. One day I want to start putting photos on Flickr. Well, to do that, Flickr needs to know a few things about me, and know every time I visit that I am who I say I am.
The old-fashioned way of doing this is to create a whole new Flickr account, where I claim to be named Paul, and I claim to have this email address, and so on. But wait a second - eBay already knows all those things about me, and I have a trust relationship with them.
So why, instead, can't my eBay ID be portable? I just show up at Flickr's website, flash my eBay badge, tell Flickr I'd like to upload my photos, and away I go.
The great thing is that it's asymmetric and decentralized (unlike Microsoft's Passport). I can choose whether I show my eBay ID, Gmail ID, or some other ID to Flickr. Flickr, for their part, can choose whose IDs to trust and whose not to trust.
Paul, your description is close to how SXIP works. We envision that you have a small number (maybe even only one) place that manages your identity, and that you can use that at all the different sites, and you get to choose which site is your "Homesite"
If I can request...
I would argue that most users don't have a static privacy policy, or that the basis for any such policy varies with the nature of the transaction (high privacy with impulse or infrequent or unusual or personal purchases; lower privacy with incentivized transactions, loyalty programs, complex product/service combinations). For myself, anonymity is a very attractive aspect of the web and something I try to maintain. I can't imagine the amount of Spam that a high profile individual such as yourself receives, but despite filters and specifically requesting no email contact I'm sure we all get more spam than we want.
Here's my request: in real life, if a vendor starts to request more information than is necessary for a transaction, I can request a manager or threaten to cancel the transaction. The vendor can then decide whether collecting desirable but unnecessary information is worth losing the sale (or their job). On the net, unfortunately, I often do the same, cancelling the on-line transaction if they get too nosey, and (increasing the transaction cost to the vendor) call, complain, and decide whether or not to complete the order. So, the request is to have the user identity 'agent' have the ability to alert the vendor that the amount of ID requested exceeds the users 'policy' (comfort level, whatever) and that the transaction is at risk.
Any good salesman intuitively spots the nature of the interaction a potential customer is likely to desire, and does not try to force a 'trust' relationship on a reticent prospect. The sales experience (approach) is immediately adapted to the degree of identification / interaction the customer seems ready to provide.
Way back when Toffler first wrote Third Wave, he pointed out that that disclosing identity has value. I don't think he anticipated the degree to which some vendors would try to bully users to give up that value nor the degree to which others would abuse that information (spammers). I do think there is a significant portion of the demographic that wants to have some sort of feedback mechanism implicit in the transaction that describes the risk of collecting identity information to the vendor. After all, there is valuable information received by a vendor when a sale fails in the real world -- but in most cases on the net, when users terminate a sale or connection, the site gets minimal if any feedback on why the transaction was aborted. (There's a market niche for you -- 'find out why your potential customers left'.)
BTW thanks for your kind reply.
I hope that agent software evolves to provide intelligent feedback to users on the nature of the identity transaction. In order for an intelligent agent to participate in the transaction, there needs to be semantics a opposed to the existing form mechanisms. SXIP enables this.
'We envision that you have a small number (maybe even only one) place that manages your identity, and that you can use that at all the different sites, and you get to choose which site is your "Homesite"'
How many Homesites do you envision there being to choose from, and is there any technical reason each Membersite can't be a potential Homesite?
There is no technical reason a Membersite can't offer the functionality of a Homesite. Wether a user chooses to use the site as their Homesite is what will make the site a Homesite. I envision that Homesites will follow the power curve. There will likely be a small number that have many users, and a large number that have few users.