Stand-alone attribute providers typically use a lookup key based scheme in order to return attributes associated with that key. But as we move to a more attribute-centric world, they will need to incorporate identity resolution as the first step in the attribute query flow in order to meet the needs of a wide range of customers.
I’ve spent a fair amount of time profiling protocols to support attribute query and retrieval. A common theme across all of them have been that attribute lookup is key based. i.e. Provide the Attribute Provider (AP) a lookup key and the AP returns the attributes associated with the key.
CSPs as Attribute Providers
This is typically a non-issue when the Credential Service Provider (CSP) and the AP are one and the same. The CSP can authenticate the person and use the identifier from the authentication to lookup the associated attributes.
Examples of standardized lookup keys include Subject DN, FASC-N or UUID from an X.509 certificate or an email address or userid.
Stand-alone Attribute Providers
Pure attribute providers (i.e. ones that are NOT part of a Credential Service Provider) are an entirely different story. The challenge here is the need to select and standardize the LUSID (Locally Unique Shared Identifier) i.e. the lookup key that is shared between the requester and the AP.
Without the LUSID the AP is blind to who it is being asked to provide information on. So a significant amount of energy is expended on getting agreement on common identifiers, which have both resource and privacy implications.
Identity Resolution and Identity Proofing
Identity resolution is the confirmation that a set of attributes have been resolved to a unique individual (i.e. no other individual has the same set of attributes) within a particular context.
Identity resolution is the first step in an identity proofing process since the first step in assuring a trusted identity is the ability to ‘UNIQUELY DISTINGUISH’ an individual from all other people.
It requires the collection, with consent, of a specific set of attributes that balances data minimization imperatives with just enough data to determine uniqueness.
Attribute Providers and Identity Resolution
Stand-alone attribute providers, to remain relevant in an attribute-centric world, need to expand beyond key based lookup approaches to incorporate identity resolution based lookup approach.
In particular, they need to build in as the first step the ability to accept a minimal attribute set, defined by policy, that will be used for identity resolution.
It should be noted that the LUSID could be an additional matching criteria i.e. one of the attributes that comes in as part of the query. This could fast-track the lookup, but the key here is that one should not depend on the LUSID always being present.
Privacy, Data Minimization and Multiple Matches
An aspect to consider is what the AP does with the incoming set after resolution is done. I lean towards having a policy that the set should ONLY be used for resolution and must be discarded after resolution is achieved.
Another challenge that will need to be worked through is what happens when the minimal data set is not enough to uniquely resolve a person. Do you go back to the person to ask for additional information? What will that UX look like? Is that dependent on protocol? Can that be standardized?
At the end of the road, stand alone attribute providers, in order to be able to service the widest range of customers, need to move away from a pure key based lookup to an attribute query flow that incorporates identity resolution as the first step.
Question: Do you have any examples of stand alone attribute providers that are currently utilizing identity resolution as the first step in the query process?
- The Venn of Identity Proofing and Identity Resolution Attributes
- A Simple Framework for Trusted Identities
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.