RAH pointed last week to a series of blog postings on Identity. This seems to be a discussion between Ben Laurie, Kim Cameron and Stefan Brands. In contrast, Hasan points out the same debate is happening on slashdot. I'd vote for slashdot, this time. They say it's hard to do. They're right.
Why? As slashdot people suggest, this is a typical bottom-up versus top-down approach to a question you shouldn't be asking.
Drilling down, it's the same old story. High level managers say "we need to know who the consumer is." Or, as Dave says,
What is it about smart cards and health? Health ought to be one of the places where getting someone's identity right -- and being able to authenticate them quickly and efficiently -- is a driver.
Engineers in the space then address that problem, with varying degrees of modification of the original requirement. Note the temptation introduced by David Chaum to introduce privacy architectures so as to address the perceived harms of things like linkability, etc, continues.
The people over at Microsoft, Credentica, and probably Google are trying to build the toolkit. What they are not doing is establishing a clear user-driven set of requirements. That's because they can't, they are platform providers, and they are trying to establish a one-size-fits-all approach to the Rights space. And then impose that on the users.
Instead, we should address the business problem at its core. Why do you need to know who the consumer is? Stefan Brands' techniques go *some* way towards suggesting this by pushing the notion of a claims-based toolkit based on sophisticated cryptography, but it is still only a suggestion, it's still a toolkit, and it still imposes bottom-up thinking on a top-down world.
The debate will rumble on, because the big(gest) corporations and governments are going to invest capital in this. In the direct FC space, the same thing happened in the 90s between Netscape, Sun and Microsoft. Then, as now, the business case was flawed.
A flawed case doesn't mean a failed business, necessarily. Instead, it suggests that the real battle is going on in the business strategy space, not in the FC space. This means we can be relatively relaxed about the various claims batting back and forth in the rights layer, and instead keep our eyes on the business battle.
Posted by iang at June 5, 2007 11:31 AM | TrackBackso can I kick off some here
i've somewhat interacted with some of the parties/players in the identity sphere ... part of it involves
1) reducing principles of authentication & authorization to its fundamental, atomic (KISS) units ... as in attempting to show a way of moving from an institutional-centric hardware token ("something you have") paradigm to a person-centric hardware token paradigm ... recent post on subject
http://www.garlic.com/~lynn/2007l.html#8
2) working the concepts into the structure of my merged security taxonomy & glossary (which some of the identity related standards work have referenced):
http://www.garlic.com/~lynn/index.html#glosnote
in the past couple days, i got an inquiry from one of the "identity" players about expanding the security taxonomy/glossary with more identity related concepts. I've gone ahead with a start using a number of ".gov" sources ... including GSA's federated identity management manual.
authentication basically comes down to having high confidence that you are who you claim to be (aka involves identity). authorization basically comes down to permissions for the specific entity. frequently authentication and identification get confused
basically it is relatively straight-forward to aggressively cost-reduce a "something you have" hardware token ... even if multi-factor authentication gets involved ... with token support for "something you know" and/or "something you are" authentication ... from 3-factor authentication model
http://www.garlic.com/~lynn/subintegrity.html#3factor
lots of the complexity isn't from straight-forward authentication principles .... its getting confused with the authorization characteristics. lots of the hardware tokens aren't aggressively cost reduced ... they have lots of hand-waving about added value ... almost all of this carries with it lots of personal information. one possible scenario is that all the personal information can't be interpreted as related to "authentication" ... i.e. relying party grants permissions and privileges based on personal/privacy characteristics (aka it is getting heavily involved in authorization as "added" value).
this is left over from the offline world ... my frequent reference to explaining that the PKI digital certificate (which many of the hardware tokens are starting to emulate) is an electronic analog to physical credentials, certificates, licenses ... along the lines of the letters of credit/introduction from the sailing ship days (and earlier) when the relying party would be having first time interaction with a total stranger and unable to directly confer/check with any possible reference. the apparent tendency in the early to mid 90s was to grossly overload an x.509 identity digital certificate with enormous amounts of personal information ... as a means of aiding relying parties in authorization decisions (unrelated to any authentication and identity). it was in the mid-90s that there started to be some realization that such digital certificates, grossly overloaded with personal information represented significant privacy and liability issues. this led to the "replying-party-only" digital certificates ... which contained only sufficient information for authentication (identity)
http://www.garlic.com/~lynn/subpubkey.html#rpo
all the necessary personal information necessary for authorization then was obtained from some other source (once authentication had been performed). however it was trivial to show that relying-party-only certificates were redundant and superfluous ... since ALL the information the information for both authentication and authorization could be obtained from the same source ... and therefor it was possible to have a digital signature verification infrastructure (for both authentication and authorization) that had no need for PKI and digital certificates
http://www.garlic.com/~lynn/subpubkey.html#certless
so i would claim that the "identity" for the authentication part can be extremely simple and cost-effective (KISS). frequently it is the inclination to include enormous amounts of personal information as an aid allowing "relying parties" to base "authorization" decisions. It is also such enormous amounts of personal information that result in the privacy and liability issues.
this has led to the added value variations (digital certificates and hardware tokens) moving into the "no value" market segment ... i.e. environments where the relying party operations can't justify cost of their own information repository about individuals and/or justify online connectivity to some authoritative agency. the downside of moving into "no value" market segments is that it becomes even more difficult to justify the cost of any added value offerings.
so my tendency would be to claim that some amount of the whole swirl around "identity" ... isn't related to identity for authentication; it is all the possible enormous amounts of personal information that opens up the responsible agency for both privacy invasive liability from the individuals (possibly from data breaches) as well as any related authorization liability from relying parties (how to provide sufficient personal information so that relying parties can make authorization decisions w/o incurring any legal liability).
the other historical scenario (related to cross-domain, federated, etc) swirl around identity is all the stuff that there was in the 90s with PKIs trying to define cross-infrastructure operation for digital certificate (enormous amounts of privacy information as aid in cross-domain authorization decisions).
we had run into the same scenario nearly a decade earlier in a prior life when we were working for one of the companies that provided half of the funding/grants for MIT's Project Athena. Kerberos (authentication) was originally work done at Project Athena ... and it was one of the projects we would get to periodically review. We happened to be there when there was a week of working sessions on the initial details of Kerberos cross-domain support. More recently we sat thru a presentation on a SAML implementation where the message flows were essentially identical to what was worked out for cross-domain Kerberos (except using SAML encoded messages).
Later there was the pk-init draft for Kerberos ... registering public keys in lieu of passwords for authentication ... again a purely certificateless public key mode of operation. Somewhat after that, there was heavy lobbying to also add definition for certificate-mode of operation to the pk-init draft. Since then, one of the principles behind that (digital certificate) lobbying effort has periodically contacted us to apologise (i.e. digital certificate mode of operation for Kerberos being redundant and superfluous). lots of past Kerberos posts
http://www.garlic.com/~lynn/subpubkey.html#kerberos