One of the interesting aspects of the service model outlined in the “Component Identity Services” Section of the FICAM TFS Trust Framework Provider Adoption Process for All Levels of Assurance are the roles, responsibilities and expectations of each of the components. This is especially critical within the context of identity federation when you are depending upon entities outside your security/business domain for critical identity capabilities.
BTW, I find the commonly used term identity provider, at best, imprecise and, at worst, misleading since as typically implemented they are often not one or the other. So let me start with some standard terminology from OMB M-04-04 E-Authentication Guidance for Federal Agencies (PDF) and NIST Electronic Authentication Guideline SP-800-63-2 (PDF):
- Identity: A set of attributes that uniquely describes a person within a given context
- Token: Something that the Claimant possesses and controls (typically a cryptographic module or password) that is used to authenticate the Claimant’s identity
- Individual Authentication: The process of establishing an understood level of confidence that an identifier refers to a specific individual
- Level of Assurance (a.k.a Assurance Level of a Credential): Defined as (1) the degree of confidence in the vetting process used to establish the identity of an individual to whom the credential was issued, and (2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued
All of this works brilliantly and seamlessly when the vetting and the secure binding of the identity to a token, and the assertion of that identity to a RP is done within a single security/business domain. The Relying Parties (RPs) within that domain have full access to the identifier as well as the set of attributes that uniquely describes a person.
The pieces get much more distributed within the context of a Federation.
First and foremost, the starting point of identity within a federation, in the majority of public sector online service use cases, is entirely driven by the need to uniquely describe a person to an RP so that someone from outside the RP’s security/business domain can be mapped into the RP in order to deliver online services to them.
The assertion of an identifier by a CSP is not enough to resolve that person to a unique individual, especially within the US context where there is no single mandated identity-card/identifier that can used by the RP to “look up” the identity (i.e. the set of attributes that uniquely describes a person) for resolution.
Identity in a federation is ultimately in the eye of the RP, so a CSP that is able to convey nothing more than an identifier is not providing enough information to the RP to allow it to do identity resolution. And while they may indeed play the role of a CSP within an Enterprise/White-label-scenario or a single security/business domain, without the ability to provide identity attributes that allow for resolution in a federation environment, they are asserting a Token and not a Credential i.e. They are a Token Manager.
UPDATE 12/31/13: Graphic updated to match FICAM TFS Component Identity Services Terminology
- FICAM TFS Trust Framework Provider Adoption Process for All Levels of Assurance - Section 3.4
- OMB M-04-04 E-Authentication Guidance for Federal Agencies (PDF)
- NIST Electronic Authentication Guideline SP-800-63-2 (PDF)
- IDMGOV Info: FICAM TFS Component Identity Services Terminology
Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!
This blog post first appeared on Anil John | Blog (https://blog.aniljohn.com). The opinions expressed here are my own and do not represent my employer’s view in any way.