so 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