Monday, July 02, 2007
Outstanding Questions on CardSpace and Security
I have been thinking about authorization in a user-centric world and have the following outstanding questions...
Digital signatures validate that the data was not modified and that the private key was used to create the signature. User-centric approaches assume that the identity provider will provide a security token to any relying party without regard to the notion of authorization. Of course, firewalls can provide some protection but if they don't then how can enterprises define where an information card can be consumed using a standards-based approach?
Let's say that I work for the Sun where they will be an identity provider for Cardspace and want to have policies that say that I can only present my card to Microsoft, BEA, Sun and Oracle. The STS can build in support and checks for policies that the identity provider desires, but what if the user wanted to control better where their card can be presented by means other than an Identity Selector?
Wouldn't the notion of who authorized the use of the Card and what conditions were when the signature was created important? Since Identity Selectors aren't required to prove that a user is really a human, wouldn't it be interesting for a site to express a claim to require this fact? I wonder if there is merit in an identity selector supporting the notion of CAPTCHA for this purpose?
Imagine the day when spammers start using Information Cards to spam sites that accept them. Will everyone be required to have a painful registration/confirmation process like Kim Cameron? Is there merit in having the ability as a relying party to have proof that a particular identity selector was in use and can this somehow be signed? While we are on the topic of identity selectors, I wonder what it would take for the relying party to receive a user-understandable friendly identifier from the STS?
Consider a site that allows a user to have multiple cards where the user wants to remove one or two of them? All that the relying party can display is a meaningless PPID instead of something more user-friendly.
One of the things that Cardspace will hopefully support in the near future is the OASIS XACML specification. Consider the scenario where an insurance agent wants to log into an insurance carriers web site to transact business. This agent may be a commercial lines agent in the State of Texas and a Personal Lines agent in the State of Minnesota. The relying party would need to check for licensing purposes whether the user could even interact with the site.
The same example may apply to sites such as TD Ameritrade where they may need to know if your Series 7 is current while also checking for the proper licenses at the state level. Relying on name-value pairs is somewhat constraining.
Whenever I logon to my own TD Ameritrade account, I would for the Information Card to understand the relationship between me and my wife where she can do much of the same actions as I.
| | View blog reactionsDigital signatures validate that the data was not modified and that the private key was used to create the signature. User-centric approaches assume that the identity provider will provide a security token to any relying party without regard to the notion of authorization. Of course, firewalls can provide some protection but if they don't then how can enterprises define where an information card can be consumed using a standards-based approach?
Let's say that I work for the Sun where they will be an identity provider for Cardspace and want to have policies that say that I can only present my card to Microsoft, BEA, Sun and Oracle. The STS can build in support and checks for policies that the identity provider desires, but what if the user wanted to control better where their card can be presented by means other than an Identity Selector?
Wouldn't the notion of who authorized the use of the Card and what conditions were when the signature was created important? Since Identity Selectors aren't required to prove that a user is really a human, wouldn't it be interesting for a site to express a claim to require this fact? I wonder if there is merit in an identity selector supporting the notion of CAPTCHA for this purpose?
Imagine the day when spammers start using Information Cards to spam sites that accept them. Will everyone be required to have a painful registration/confirmation process like Kim Cameron? Is there merit in having the ability as a relying party to have proof that a particular identity selector was in use and can this somehow be signed? While we are on the topic of identity selectors, I wonder what it would take for the relying party to receive a user-understandable friendly identifier from the STS?
Consider a site that allows a user to have multiple cards where the user wants to remove one or two of them? All that the relying party can display is a meaningless PPID instead of something more user-friendly.
One of the things that Cardspace will hopefully support in the near future is the OASIS XACML specification. Consider the scenario where an insurance agent wants to log into an insurance carriers web site to transact business. This agent may be a commercial lines agent in the State of Texas and a Personal Lines agent in the State of Minnesota. The relying party would need to check for licensing purposes whether the user could even interact with the site.
The same example may apply to sites such as TD Ameritrade where they may need to know if your Series 7 is current while also checking for the proper licenses at the state level. Relying on name-value pairs is somewhat constraining.
Whenever I logon to my own TD Ameritrade account, I would for the Information Card to understand the relationship between me and my wife where she can do much of the same actions as I.
