Anil John
Making Digital Services Secure and Trustworthy

Anil John

Why I Will Not Ride The (Trust) Elevator

 Tweet  Share  Comment  Print  Email

I believe there is a place for the use of compensating controls when it comes to identity assurance, but am ambivalent about the approach that is referred to as “trust elevation”. This blog post describes my understanding of the two approaches and why I believe the former is a more valid and realistic approach in the current time frame.

In a recent discussion on compensating controls and trust elevation, a friend who focuses on the privacy side of house asked me if the difference is simply a matter of semantics. I found that to be a fair question and thought I would provide my answer here as well.

Compensating controls, as it relates to identity assurance, are something to be implemented by the relying party when there is a mismatch between assurance(s) available from a credential service provider and what is needed by the relying party. I’ve written about this before, so won’t repeat it here. The point is that for a variety of reasons including unavailability of credentials at the needed LOA or the need to make the user journey as friction-less as possible, an RP may put into place controls that seek to mitigate the risk of mis-identification.

Those controls are often transactional in nature and allows the RP to operate within a risk profile that they are comfortable with. There are trade-offs that the RP needs to be aware of in making this decision and the key take-away is that the manner in which the compensating controls are implemented are unique to each RP and they are fully responsible for the consequences. The uniqueness of the implementation combined with the RP specific risk appetite means that it is almost impossible to quantify the control mechanisms such that it can be used outside the RP’s domain.

Trust elevation, as I understand it, seeks to quantify a set of “other factors” that can be used in combination with an existing credential in order to “elevate” the assurance level of the credential beyond its original level. It is similar in concept to NIST SP-800-63-1 Multi-Token Assurance Level Escalation, but uses factors such as behavior and context instead of additional tokens.

Conceptually, I understand the intent and the approach.

What I disagree with are:

  1. the presumption that the approach is raising the assurance level instead of mitigating the risk of using a lower assurance credential
  2. that the “elevation” can persist beyond the session; A Bad Idea
  3. that the “elevated” level of assurance can then be asserted downstream to another application or in a federation context; Another Bad Idea

Is my understanding of trust elevation correct? Do you believe that factors such as behavior can be quantified such that they can be consistently used across organizations?


Did you find this interesting? Don't miss any new posts. Sign up to automatically receive them now!

I will never share, rent, or sell your information to anyone. Cancel anytime.

This blog post first appeared on Anil John | Blog ( The opinions expressed here are my own and do not represent my employer’s view in any way.

By on |

Continue The Conversation ...

I would love to know your thoughts on this blog post. Please leave a comment below!

I am a Public Interest Technologist. I help technical leaders make digital services secure and trustworthy. Learn more »

Free Updates

I will never share, rent, or sell your information to anyone