We can over-stretch our metaphors.
Is a passport an "identifier"?
Is a drivers licence an identifier?
Is a credit card an identifier?
Is a professional membership card an identifier?
Is an employee badge an identifier?
Is a building access card an identifier?
Is a house key an identifier?
Is a car key an identifier?
Or putting the questions another way ...
Is a car key a "key"?
Is a house key a key?
Is a building access card a key?
Is an employee badge a key?
Is a professional membership card a key [to access an association]?
Is a credit card a key [to a payments system]?
Is a drivers licence a key [to access the privileges of road usage]?
Is a passport a key [to enter another country]?
From When does a key become an identifier?, 28 April 2005.
"All Hail the Relyingpartyrati!"
The quote "The IdP is Dead! Hail the Relyingpartyrati" is from my conclusion (reflecting the running inside joke at CIS that something has to die each year). One of my ideas is that because identification is carried out by Relying Parties, it's more correct (and probably liberating) to think of identity as being created by the RP. The best option for what we call "Identity Providers" today may be to switch to providing more specific Attributes or identity assertions. In fact, the importance of attributes kept recurring throughout CIS; Andrew Nash for example said at one point that "attributes are at least as interesting if not more so than identities".[Now it has emerged during the debates that people might use the word "attribute" in slightly different ways. I said at CIS that I treat 'attributes', 'assertions' and 'claims' interchangeably; I think we should focus functionally on reliable exchange of whatever factoids a Relying Party needs to know about a Subject in order to be able to transact. I'll blog in more detail about Attributes shortly.]
To summarise my CIS talk:
Federated Identity is easier said than done. In response, we should drop down a level, and instead of trading in abstract high level identities, let's instead federate concrete component attributes. We don't really need Identity Providers as such; we need a marketplace of Attribute Providers from which Relying Parties can get exactly the right information they need to identify their users.
- identities evolve over time in response to risk factors in the natural business environment; we need to understand why authentication has got the way it is before we rush in to federate disparate methods
- identities appear to be "memetic", composed of heritable traits relating to business rules and practices, conventions, standards, regulations, technologies, algorithms, cryptographic parameters, form factors and so on
- the dreaded identity silos are actually ecological niches; taking an identity from the context in which it evolved and using it in another is like taking a salt water fish and dropping it into a fresh water tank
- if identity is memetic then we should be able to sequence digital identities into their constituent memes, and thence re-engineer them more carefully to match desired new applications
- it is an over-simplification to think of a (one dimensional) identity spectrum; instead each RP's "identification" requirements are multi-dimensional, and best visualised as a surface.