Monday, May 11, 2009
User Centric Identity within an industry vertical context
I am just returning from the European Identity Conference where I had some great conversations with thought leaders in our industry. Over the next week, I hope to share insights and continue the dialog I had with many virtually. Today, I wanted to focus on an intersection of conversations I had with Kim Cameron, Vittorio Bertocci, Dee Schur of Oasis and Anthony Nadalin of IBM, Prateek Mishra of Oracle on what are some of the next steps that need to occur to make cardspace usable in a B2B setting...
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.
Now, an independent insurance agent can do business with a plethora of carriers whom 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. Once this demographic decides to not remain blissfully ingorant and start to develop an uderstanding that being a really could relying party can make IT cheaper in the long haul and in a way that business people would understand.
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 whitelisting 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.
One analogy that I think has merit is in thinking about how PKI works. If you receive a certificate, the very first thing you do is to figure out if it is signed by a root CA that you trust. The same thinking could apply to an identity provider where if I received a pointer to an identity provider that was signed by a state department of insurance that I trust, then why wouldn't I want to trust it. I could upfront populate my RP with a listing of trusted roots and then could essentially consume identity without ardous registration processes while also avoiding whitelisting maintenance overhead.
The second challenge in been a really good relying party is to understand the vetting process of an identity provider. Today, there are notions of identity assurance within several of the OASIS specifications but the thinking is not complete. For example, don't you think it would be important for a relying party to understand method was used in identity vetting and to what level? For example, vetting can occur based on several mechanisms including out-of-band confirmation, knowledge-based authentication, in person and so on.
For knowledge-based authentication, wouldn't it be cool if one knew that a subject faced say five questions and got all five right vs say only three? Some of the other questions may include a way to communicate when the vetting process last occured, kinda along the lines of the way that IdM types think about attestation. Taking this one step further, Wouldn't it be great if the identity provider could also provide some form of how strongly or weakly they guarantee their own vetting? If an IDP could communicate that bad identity would be indemnified at a dollar value vs no liability/responsibility, the relying party could make an informed decision.
Anyway, wouldn't it be much better if a relying party could somehow communicate that they only wanted to accept cards that were signed by a particular body they trust and that was also vetted to a level they were comfortable with where the identity selector not only understood this request, but also only presented cards that met this criteria?
So, as I see it there are several action items that need to occur:
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, says that 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 would repeat 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...
| | View blog reactionsConsider 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.
Now, an independent insurance agent can do business with a plethora of carriers whom 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. Once this demographic decides to not remain blissfully ingorant and start to develop an uderstanding that being a really could relying party can make IT cheaper in the long haul and in a way that business people would understand.
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 whitelisting 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.
One analogy that I think has merit is in thinking about how PKI works. If you receive a certificate, the very first thing you do is to figure out if it is signed by a root CA that you trust. The same thinking could apply to an identity provider where if I received a pointer to an identity provider that was signed by a state department of insurance that I trust, then why wouldn't I want to trust it. I could upfront populate my RP with a listing of trusted roots and then could essentially consume identity without ardous registration processes while also avoiding whitelisting maintenance overhead.
The second challenge in been a really good relying party is to understand the vetting process of an identity provider. Today, there are notions of identity assurance within several of the OASIS specifications but the thinking is not complete. For example, don't you think it would be important for a relying party to understand method was used in identity vetting and to what level? For example, vetting can occur based on several mechanisms including out-of-band confirmation, knowledge-based authentication, in person and so on.
For knowledge-based authentication, wouldn't it be cool if one knew that a subject faced say five questions and got all five right vs say only three? Some of the other questions may include a way to communicate when the vetting process last occured, kinda along the lines of the way that IdM types think about attestation. Taking this one step further, Wouldn't it be great if the identity provider could also provide some form of how strongly or weakly they guarantee their own vetting? If an IDP could communicate that bad identity would be indemnified at a dollar value vs no liability/responsibility, the relying party could make an informed decision.
Anyway, wouldn't it be much better if a relying party could somehow communicate that they only wanted to accept cards that were signed by a particular body they trust and that was also vetted to a level they were comfortable with where the identity selector not only understood this request, but also only presented cards that met this criteria?
So, as I see it there are several action items that need to occur:
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, says that 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 would repeat 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...
