XAuth has had me fascinated since it was announced yesterday. If you haven’t heard of it yet, I think Dare Obasanjo’s summary is one of the better descriptions, although his site seems to be having issues this morning.
What is XAuth? It appears to be one service, running on one domain, that will maintain the login state of every user at (ideally) every consumer Identity Provider in the world, in real time. A service users have to opt out of. The goal is discovery of authenticated providers.
There are interesting nuances here. As far as I can tell, for the large providers who are already a fixture on the standard NASCAR page, adopting Xauth means that their logo can only be shown on fewer pages than they are today. This means that Google, Microsoft Live and Yahoo! are essentially volunteering to delist themselves from NASCAR pages when the user is not registered or not logged in. Meanwhile Facebook and Twitter, who are not at this time involved in XAuth, will be there on every single NASCAR page, holding their spot, nice and predictable, day in and day out. If you travel to Zoho, for example, and you are logged out of both Facebook and GMail, you will only see Facebook’s logo. And since xauth.org is by design a single point of failure, any service disruption that threatens revenue for the relying party is likely to result in an abrupt re-adoption of a static NASCAR page. So – what is it that these providers gain from such a dance?
They get to remove the user from the equation. Relying Parties and Identity Providers get to finally discover each other all by themselves, they can talk right over everybody’s heads without prompting users. In one sense, I completely get this! Business runs so much smoother when the decisions get made en masse. Asking the user is time-consuming, difficult, and frequently unappreciated. And eventually you just have to solve the problem and get stuff done.
XAuth, if it succeeds, will be the antithesis of user-centric identity. It is what happens when companies with businesses to run finally realize that asking users is a thankless, hopeless task that can only get in the way. We all know it is easier to ask forgiveness than permission – for better or worse, XAuth is that principle, taken to its logical conclusion.
For whatever reason, I’ve been pondering similarities and differences between financial and IT risk lately, and one big difference seems to be around reputation in these two areas. The financial world painstakingly maintains institutionalized memory of credit issues through standardized credit ratings. Companies, cities, and even countries are rated based on current and past performance, and a ratings downgrade is a BIG deal.
Why isn’t there an analogous service for systems security risk? For example, Mike Ramirez just pointed out a data breach at Monster.com, I’d love to go somewhere and see, was that the first time? Have they been breached before, and I simply didn’t hear about it? How about Heartland Payment Systems? It seems to me that right now, companies can get away with repeat offenses, simply by flying under the radar.
Of course, there is always the Listeriosis Clause to consider — who do you trust more, the company with a dedication to quality that is forced to disclose, or the lazy/ignorant company who never even looks, and therefore never has to tell?
In any case, I’d like to see collections of disclosures about the various services I choose to use or do business with. I’d like to see data collection for the purposes of comparing privacy policies, TOSs, known breaches of or challenges to those policie. Another issue that I believe could gain prominence is being able to easily research whether the companies I interact with are sending/storing my information across international borders. I think there would be some really interesting discoveries in such a body of data.
Do you remember this quote from the movie “The Incredibles”?
… And when I’m old and I’ve had my fun, I’ll sell my inventions so that *everyone* can have powers. *Everyone* can be super! And when everyone’s super– [chuckles evilly] –no one will be.
Sometimes I think that this is the end game we’re looking at with Social Media. Right now, we’re so busy hooking every acquaintance we ever had to every other acquaintance as virally as possible on every site everywhere, that we forget who it is we’re going to end up talking to, and to whom our words have meaning.
It’s great that we’ve gotten to the point where I can broadcast a single thought simultaneously to all of my many services – but what happens when everybody does that? What happens when the majority of the people you know are on two or more of the sites you visit and all of them are broadcasting across services? I like seeing tweets from people I know. But when I see the tweet on twitter, then the next time I get onto Facebook the identical tweet shows up as a status update, and then I see it yet again in a weekly digest of tweets that shows up in my RSS reader from that person’s blog - it gets old fast, and it takes away from the unique character of any one service. As a very subjective judgement, I personally start to feel more like I’ve been spammed than confided in.
Right now, I would choose an aggregation service not for the combination of what’s different so much as the elimination of what’s redundant. As all these services bleed into each other, the ratio of new to redundant will become very pronounced; I imagine that creative solutions to this problem will be an important future differentiator.
I love working with smart people. I went into the ICF schemas working group call with my set of gobbled-together proposals, and everybody seized on it and started breaking those ideas down into their separate pieces, using language with far more structure than my own words.
There were some excellent points made:
What are the expectations of the “Display Claim” versus the actual claim in providing human-readable claim values? Is it reasonable (or even preferable) to define a claim value that is not human-readable and trust that the STS will be responsible for mapping that value to something useful?
Is it expected that the selector will do a metadata discovery on each and every claim passed? I had never even thought of such a thing, so will have to learn more.
I will keep you up to date with the conversation, which is expected to continue on the working group mailing list this week. The mailing group is: http://groups.google.ca/group/icf-wg-schemas, I believe anyone can read, but you have to be an ICF member to participate. If you are keen to participate, let me know.
During IIW, the ICF Schema Working Group proposed and approved its first standardized claim definition. I’ve been following the workings of the schema group but not closely, and I was taken by surprise at the values defined as part of this precedent-setting claim element:
Claim Name: age-18-or-over
What? Want to know what the values MEAN? Sorry, you’ll have to look that up. What you see above is what a Mother or Father will see when they view values passed between the Identity Provider they are trusting to make claims about their children’s age, and a website that may restrict content based on that value.
Do you see the problem? Why on earth even have a selector if the standard claims we propose are not understandable by end users? Why use a meaningless number? To make it easier for the machines? For the developers? That’s crazy! Why don’t we make it easier for the people that are making selector-level security decisions on a daily basis? These schema types have to be created so that whenever possible, the data passed is legible to those attempting to understand the context of identity data flowing around them. Heck, if we created a vocabulary for content that could be distinctly identified and parsed by Selectors, we could even localize.
It’s taken me since IIW to really get my head around this – but I believe we need to set some very specific best practices around these schema elements, first and foremost being the primary design principle that these atomic elements should be designed for regular people, not for developers, and not for machines.
I’m going to do my best to argue this point today on the ICF working group call. If you think this is important, whatever your stance on the issue might be, I urge you to join the Information Card Foundation and to make your voice heard. Contact me if you aren’t sure what you need in order to join, I will put you in touch with the right people.
I think that best practices around claims schema is THE MOST IMPORTANT thing happening right now. It is worth taking the time to get this right. We’ll only get one shot at it.
This adds a massive lightning stroke of accountability into the affair, doesn’t it? Suddenly, the forums aren’t just a “value-add”, they are also a potential “value-take-away”. I have this picture in my head of Family Member A explaining to Family Members B and C how A lost his/her temper in the EA forums last night, and now the whole family has lost not only their access to their games, but possibly their game statistics & reputations too, depending on what EA does to enforce the ban and the subsequent serial number invalidation. Ah, it all comes back to Identity mgmt and asset mgmt, doesn’t it?
Kim has been working on a less internerdy version of the Laws of Identity – but I’m not sure the current version would resonate with people like my Mom. So – being the go-getter that I am, I had to take a minute and come up with alternatives. What do you think?
If I could use any terms I wanted and assume that everyone understood them, I could get even shorter:
Don’t share my information behind my back.
Don’t take more information than you need.
Don’t expose my information unnecessarily.
Don’t link me or allow others to link me unless I want to be linked.
Don’t lock me into silos.
Don’t tell me to RTFM in order to be secure.
Don’t let the product interfere with the ceremony.
In my last blog post, I complained that we’re a bit lost. I would like to even be more specific. In the world of Identity, there are theoretically two types of people — those whose job it is to pay attention, and those who rely on the first type of people. I don’t mind if the second group are lost. I worry when the first group are lost.
So, why is it that we actually deploy these systems in the first place? And, if this world of Identity is a journey and not a destination, how do we know when we’ve seen and done enough?
Here is my definition of what a given Enterprise may wish to accomplish by spending money on Identity technology:
Simplification of Sign-on & Sign-on related procedures
Access to assets granted on basis of least privilege
Process-driven Account Automation
Delegation of Identity Data Maintenance & Workflow to the person/resource most able to enter correct, timely & knowledgeable data
Ability to interact with partners or outsourced services securely & efficiently
Accountability for all of the above through Approvals, Audit
Why do we wish to accomplish these things?
To make the Enterprise workforce as productive as possible.
To protect corporate assets against theft or abuse.
There. That’s it, assuming I haven’t forgotten anything obvious. The problem is, you can’t just tick off these items like some kind of grocery list. All you can do is make a qualitative assessment of how close the processes & technologies your company has implemented from the first list bring you towards the end goals described in the second list. Every organization of every size should be making these evaluations – but the sweet spot between cost undertaken and value returned will be different. For smaller companies everything could be manual, and there is nothing wrong with that as long as the risk and overhead are tolerable.
Is this characterization just an invitation for vendors to get lazy? It’s hard for me to imagine. There is so much work to do in these areas, so many things that can improve, that I can’t imagine any of the vendors having time to slack off. Besides, I think there are revolutions to come.
The really interesting question will be whether or not the big vendors will ever start enabling truly integrated provisioning and SSO support for the full range of their products. Imagine if every web enabled product sold by Oracle had a configuration property called “trust OAM session cookie”, and if the configuration property was set, the application ceased to prompt users for credentials, and instead simply looked for a set of pre-agreed-upon header values to determine the identity of the user. Imagine if your provisioning workflows for employee and manager self-service came built into your HR product, but only a configuration page later, you could hook the interface into your provisioning system. Imagine if all of the application-specific roles in all of your stack applications were consistent and complimentary, both at the fine-grained application level and at the enterprise middleware level. That is the potential, if not the reality, of a stack offering. Integral adherence to an identity vision, instead of bolted-on adherence. Sigh, what a lovely thought.