This post is by Kim Cameron
from Kim Cameron's Identity Weblog
Click here to view on the original site: Original Post
The recent European Identity Conference, hosted in Munich by the analyst firm Kuppinger Cole, had great content inspiring an ongoing stream of interesting conversations. Importantly, attendance was up despite the economic climate, an outcome Tim Cole pointed out was predictable since identity technology is so key to efficiency in IT.
One of the people I met in person was James McGovern, well known for his Enterprise Architecture blog. He is on a roll writing about ideas he discussed with a number of us at the conference, starting with this piece on use of Information Cards in industry verticals. James knows a lot about both verticals and identity. He has started a critical conversation, replete with the liminal questions he is known for:
‘Consider a scenario where you are an insurance carrier and you would like to have independent insurance agents leverage CardSpace for SSO. The rationale says that insurance agents have more personally identifiable information on consumers ranging from their financial information such as where they work, how much they earn, where they live, what they own to information about their medical history, etc. When they sell an insurance policy they will even take payment via credit cards. In other words, if there were a scenario where username/passwords should be demolished first, insurance should be at the top of the list.’
A great perception. Scary, even.
‘Now, an independent insurance agent can do business with a plethora of carriers who all are competitors. The ideal scenario says that all of the carriers would agree to a common set of claims so as to insure card portability. The first challenge is that the insurance vertical hasn’t been truly successful in forming useful standards that are pervasive (NOTE: There is ACORD but it isn’t widely implemented) and therefore relying on a particular vertical to self-organize is problematic.
‘The business value - while not currently on the tongues of enterprise architects who work in the insurance vertical - says that by embracing information cards, they could minimally save money. By not having to manage so many disparate password reset approaches (each carrier has their own policies for password history, complexity and expiry) they can improve the user experience…
‘If I wanted to be a really good relying party, I think there are other challenges that would emerge. Today, I have no automated way of validating the quality of an identity provider and would have to do this as a bunch of one offs. So, within our vertical, we may have say 80,000 different insurance agencies whom could have their own identity provider. With such a large number, I couldn’t rely on white listing and there has to be a better way. We should of course attempt to define what information would need to be exposed at runtime in order for trust to be consumed.’
This raises the matter of how trust would be concretized within the various verticals. White listing is obviously too cumbersome given the numbers. James proposes an idea that I will paraphrase as follows: use claims transformers run by trusted entities (like state departments of insurance) to vet incoming claims. The idea would be to reuse the authorities already involved in making this kind of decision.
He goes on to examine the challenge of figuring out what identity proofing process has actually been used by an identity provider. In a paper I collaborated on recently (I’ll be publishing it here soon) we included the proofing and registration processes as one element in a chain of factors we called the “security presentation”. One of the points James makes is that it should be easy to include an explicit statement about the “security presentation” as one element of any claim-set being submitted (see Jame’s post for some good examples). Another is that the relying party should be able to include a statement of its security presentation requirements in its policy.
James concludes with a set of action items that need to be addressed for Information Cards to be widely usedl in industry verticals:
‘1. Microsoft needs to redouble its efforts to sell information cards as a business value proposition where the current pitch is towards a technical audience. It is nice that it will be part of Geneva but this means that its capabilities would be fully leveraged unless it is understood by more than folks who do just infrastructure work.
‘2. Oasis is a wonderful standards organization and can add value as a forum to organize common claims at an industry vertical level. Since identity is not insurance specific, we have to acknowledge that using insurance specific bodies such as ACORD may not be appropriate. I would be game to participate on a working group to generate common claims for the insurance vertical.
‘3. When it comes to developing enterprise applications using the notion of claims, …developers need to do a quick paradigm shift. I can envision a few of us individuals who are also book authors coming up with a book entitled: Thinking in Claims and XACML as there is no guide to help developers understand proper architecture going forward. If such a guide existed, we… (could avoid repeating) …the same mistakes of the past.
‘4. I am wildly convinced that industry analysts are having the wrong conversations around identity. Ask yourself, how many ECM systems have on their 2009 roadmap, the ability to consume a claim? How many BPM systems? In case you haven’t figured it out, the answer is a big fat zero. This says that the identity crowd is evangelizing to the wrong demographic. Industry analysts are measuring identity products what consumers really need which is to measure how many existing products can consume new approaches to identity. Does anyone have a clue as to how to get analysts such as Nick Malik, Gerry Gebel, Bob Blakely and others to change the conversation.
‘5. We need to figure out some additional identity standards that an IDP could expose to an RP to assert vetting, attestation, indemnification and other constructs to relying parties. This will require a small change in the way that identity selectors work but B2B user-centric approaches won’t scale without these approaches…’
I know some good work to formalize various aspects of the “security presentation” has been going on in one of the Liberty Alliance working groups - perhaps someone involved could post about the progress that has been made an how it ties in to some of James’ action items.
James’ action items are all good. I buy his point that Microsoft needs to take claims beyond the current “infrastructure” community - though I still see the participation of this community as absolutely key. But we need - as an industry and as individual companies - to widen the discussion and start figuring out how claims can be used in concrete verticals. As we do this, I expect to see many players, with very strong participation from Microsoft, taking the new paradigm to the “business people” who will really benefit from the technology.
When Geneva is released to manufacturing later this year, it will be seen as a fundamental part of Active Directory and the Windows platform. I expect that many programs will then start to kick in that turn up the temperature along the lines James proposes.
My only caution with respect to James’ argument is that I hope we can keep requirements simple in the first go-around. I don’t think ALL the capabilities of claims have to be delivered “simultaneously”, though I think it is essential for architects like James to understand them and build our current deliverables in light of them.
So I would add a sixth bullet to the five proposed by James, about beginning with extremely simplified profiles and getting them to work perfectly and interoperably before moving on to more advanced scenarios. Of course, that means more work in nailing the most germane scenarios and determining their concrete requirements. I expect James would agree with me on this (I guess I’ll find out, eh?…)
[By the way, James also has an intriguing graphic that appears with the piece, but doesn't discuss it explicitly. I hope that is a treat that is coming...]