Levels of assurance, per attribute

I’ve been working with a group of Dutch identity enthusiasts on a Dutch trust framework for OpenID (OpenID.nl+), for low-trust consumer identity (e.g., for web shops). Contrary to relying on self-asserted attributes, as is usually the case for OpenID, we want Identity Providers (IdPs) to provide verified attributes. This is similar to the levels of assurance concept as standardized by NIST (see also a previous post of mine on this), and used by e.g. the EU STORK project. However, level of assurance refers to the identity as a whole, not on specific attributes, and we believe that there is value in providing a level of assurance per attribute. For example, for IdPs may be able to provide bankaccount numbers that are thoroughly verified, but not verified birthdays, and they should be able to specify this per attribute. An IdP could provide a mix of verified and self-asserted attributes.

Doing this in OpenID (AX actually) is a bit beyond the current spec, but not so difficult (see also this draft from Google/Yahoo). What is more difficult is the semantics of what “verified” means for a specific attribute. We are considering simply defining one of more verification processes per attribute. An example of a process for a verified bank account attribute is: the bank account was verified by requiring the user to transfer some money to the IdP. By lack of a standard that describes these verification processes, we’re inventing them ourselves using common sense combined with existing practises at the involved IdPs. This is work in progress, so I cannot give any firm statements yet on how well this will work, and if this will also scale. I’m happy if it will work for a small set of frequently asked attributed, and for most verification processes. Alternative approaches include

  1. Defining numeric levels per attribute, comparable to the 1 to 4 of the NIST levels of assurance with higher meaning better, and mapping the verification process used by an IdP to one of these levels.
  2. Defining it simply as “verified” (boolean), but defining the minimum amount of verification an IdP should have done for that specific attribute. This can be considered the same as alternative 1, but only with 2 levels (verified or not verified).
  3. Defining it simply as “verified” (boolean), without semantics, and thus leaving it up to the RP to check with the IdP what this means for that specific attribute from that specific IdP. We can of course provide a URL to an explanation from the IdP on how the attribute was verified.

A recent blog post of Eve Maler describes her ideas on levels of assurance. She makes a good case that the 4 levels from NIST are not suitable for use cases were a website want to recognize a returning user, without needing to know who that user is exactly (persistent pseudonym). Or put differently: have a good authentication, but no identity binding process. She also pointed to this interesting diagram from an Internet 2 Tao of attributes workshop that I would have loved to attend.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: