Anil John
Making Digital Services Secure and Trustworthy

Anil John

Relying Parties as IdPs and Assurance Level Escalation

 Tweet  Share  Comment  Print  Email

In the discussions generated by my earlier blog post, Will Consumer IdPs Become the Maginot Line of Federated Identity?, both in the comments as well as elsewhere on the InterWebs, there were some reactions generated that I wanted to highlight.

Crucially, banking IdM is closed: the RP is the IdP. The transaction business system can be designed for imperfections in their own identity system and absorb them in ways that are much more difficult when you outsource identification to a third party IdP. Simply, the cost of banking fraud can be absorbed (or passed on) when you are your own imperfect IdP. Do we call self insurance a "compensatory control"? If it is, it is proprietary and opaque.

The big picture of e-commerce inside a bank is that they balance the cost of online fraud against the savings enjoyed from reduced branch, call centre and personnel overhead. Banks can continuously monitor the system-wide equation and tweak all sorts of CCs to stay ahead of evolving criminal risks. But with federated identity the banks lose a lot of their flexibility. And they have to share with the outside world more of their business intel and risk management stratagems; all that competitively sensitive detail gets flushed out during the process of negotiating IdP costs and contracts.

Stephen Wilson

While Steve, similar to the example that I used in by blog post, focused on the Financial Institutions, I believe that the same can be said for any entity that uses a combination of weak tokens and strong down-stream analytics and compensating controls. The situation is made more complex by the fact that each of them will implement their analytics and compensating controls in a unique manner based on their internal processes and risk tolerance. As such it becomes difficult to quantify from outside the domain.

At the same time Ian Glazer, one of the other smart people in the business, was left with a ‘so what?’ feeling about the point raised in my blog. I wanted to offer the following as to why this matters:

My concern is a scenario in which a very weak LOA1 credentials is compromised out-of-band (we hear about this almost on a daily basis these days). The attacker then logs in with that credential to the IdP (which as an RP has implemented a variety of analytics and compensating controls). But in this case, the transactional assurance bits (which were accumulated over time based on the behavior of the legitimate user) are used to bump up their LOA to LOA2. This higher LOA is what is now asserted to an external RP as part of a federation transaction.

The key point being that the attacker has not done anything within the IdP system that triggered analytics that will catch any anomalous behavior, but simply used it as a jumping off point to compromise their actual target, which is the external RP.

How do you address this type situation?

  • From the IdP perspective, in a federation scenario, assert the “low water mark” of the assurance level(s) available from the token, identify proofing and credential issuance processes.
  • From the external RP perspective, if you are depending on a LOA1 credential from an IdP, understand what you are getting and make sure you you have your own analytics and compensating controls in place or use a multi-token assurance escalation strategy.


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