Visualizing the Needs of Attribute Consumers and Attribute Providers

Visual representations, if done right, can often convey complex ideas much more clearly than verbose text. I’ve been looking for some time for how best to visually represent the needs of attribute providers and the needs of attribute consumers in a simple manner. I recently came across a way to do so, and wanted to highlight it in this blog post.

Identity, in NIST SP 800-63-1, is defined as a set of attributes that uniquely describe a person within a given context. When you move to A Model for Separating Token and Attribute Manager Functions, one of the by-products is that it becomes even more obvious that the entity that has the role to bind the token(s) to a set of attributes (a.k.a. identity) has some specific requirements for what those attributes should be (a.k.a needed attribute bundle). That entity also has the ability to go out to multiple attribute managers in order to “fill” that bundle.

The model allows flexibility in who carries out the binding. Assuming, for illustrative purposes, that the relying party (RP) has taken on this role, an easy way to visualize the consumer and provider needs for attributes is using radar charts:

The key point to understand is that all of the RP requirements cannot be met by a single entity, so it has the flexibility to seek additional sources of attributes to meet its needs. And once it does, it will have the confidence it needs to do the binding.

It is interesting to note that one could assign “levels of confidence” to each of these attributes, both on the consumer side and on the producer side. For example, the RP might in its visual representation indicate that it needs the Last Name attribute to have a confidence of 80%. At the same time, the Attribute Provider 1 may indicate that it is able to provide it only to a 70%, while the CSP can provide it to 90%. I am deliberately not showing that on the visualization since I am still in the process of thinking thru how (or if) one could be assured that the criteria used to define this confidence level is feasible across sovereign domains.

I’ve focused on visual representation of attribute needs within the context of token/attribute separation. But the first time I saw radar charts being used for this particular purpose is in some of the work and thinking that Stephen Wilson has done around what he calls “identity fractions”. That approach and thinking are highly relevant to the token/attribute separation model and I would urge you to read his blog posts on “Let’s forget about identity” and “An authentication claims exchange bus” and continue the conversation.

RELATED INFO

• A Model for Separating Token and Attribute Manager Functions
• Stephen Wilson: Let’s forget about identity
• Stephen Wilson: An authentication claims exchange bus