Identity assurance is a measure of the needed level of confidence in an identity to mitigate the consequences of authentication errors and misuse of credentials. As consequences become more serious, so does the required level of assurance. Given that it typically has not taken transaction specific data as input, how should digital services factor in transaction risk into their identity assurance models?
In the comments of my earlier blog post on 'Are We Conflating Identity Verification and Compensating Controls?', David Kelts made the following comment:
I think we are conflating Transaction Risk with Identity [Risk]. It is a Service Provider’s job to know the variables that decrease risk in their transactions. As you describe in "These Are Not The LOAs", managing Transaction Risk can help the Service Provider select an achievable Identity Assurance Level, perhaps even in real-time. It’s definitely not the Service Provider’s responsibility to assure identity. They manage Transaction Risk, pick an LOA, and request it from their trusted Identity Provider, making them a Relying Party to the IDP.David Kelts (@DavidKelts)
It is a valid point that both identity and transaction risk need to be managed by the RP/SP. The checks and controls required in order to ensure a particular level of assurance are one of the mechanisms for managing identity risk. The issue for many of us is that, when it comes to transaction risk, an equivalent standardization of checks and balances and an assessment of their relative 'goodness' are not something there is wide agreement on.
As I noted before in 'Should Level of Assurance be Scalar or a Vector?', the use and understanding of transaction risk factors favors those with a bespoke, risk assessment framework. And, where those 'transaction controls' should be applied (whether at the IdP/CSP or at the RP/SP) are a point of ongoing discussion.
So, what does that mean for an RP/SP seeking to secure a high value digital service?
- Use Level of Assurance as the mechanism for managing identity risk
- Understand that it is 'coarse-grained'
- Use it as a mechanism to ensure that a common and clearly articulated set of controls have been applied by the IdP/CSP to meet the needs of each assurance level
- Use it to ensure an apples-to-apples comparison of what a CSP/IdP has done to issue a credential
- Don't fall into the trap of 'We do Level 2 but also special magic X and Y'. That will tend to skew and confuse your standardized evaluation factors
- Implement Compensating Controls to manage transaction risk
- Realize that you are accountable and responsible for compensating controls
- Develop a risk assessment framework that accounts for the specific controls you choose to implement
- Start with a small and clearly understood set of compensating controls. The ones in the guidance by US FFIEC to Financial Institutions and the UK GPG 53: Transaction Monitoring for HMG Online Service Providers are a good start
Question: What body of work exists that evaluates and/or standardizes compensating controls and their relative 'goodness'?
- Are We Conflating Identity Verification and Compensating Controls?
- Should Level of Assurance be Scalar or a Vector?
- Are Federated Credentials and Continuous Identity Verification Compatible?
- UK GPG 53: Transaction Monitoring for HMG Online Service Providers
- Peter Alterman - The Sources of Online Trust: Credential Trust or Transaction Trust
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.