LoA stands for Level of Assurance.
Most popular reference to this idea may be OMB M04-04 and NIST SP800-63.
Essentially, it classifies the identities into four categories from Level 1 to Level 4, where Level 4 stands for higher assurance. For internet commerce, generally, Level 2 or so is required. This can be applied to third party provided identities as well, but the use of such identities over Level 2 seems to be quite rare yet. Some of the notable exceptions in the field of OpenID are Japan Airlines (JAL), Rakuten, and KDDI in Japan.
Part of the reason for the market for third party provided identity failing is information asymmetry. This can be addressed by such efforts like Open Identity Trust Framework (OITF) led by US ICAM that are implemented as Open Identity Exchange (OIX) and Kantara Initiative Identity Assurance Framework (KI-IAF) etc. . Open Reputation System would be another important piece for it.
OITF addresses another factor: Contract scalability problems. As you can easily see, if there are N parties in the picture, if the Contracts are to be negotiated peer-to-peer, there needs to be N*(N-1)/2 contracts. Clearly it does not scale. The way OITF solves this problem is to setup a Trust Framework Provider and everybody gets in contractual relationship with it rather than other parties. This would reduce the number of the contract to N and helps the scalability considerably. It is working for Level 1 as of now. However, doing so with Level 2 seems to be considerably harder. One of the pain point is that it is very difficult to define an appropriate separation of responsibility and liability and capture them into a standardized contract in a static manner.
Let me elaborate it a little more.
From the Relying Party (RP) point of view, just being told that the identity is Level 2 is not very useful. RP wants to know how much risk is associated in accepting the identity including how much the Identity Provider (IdP) is covering. For example, if the IdP says that the level of the confidence of the identity is 80% with variance of 2.9 and it is covering the damage up to US$100 if the identity turns out to be false, then the RP can make its decision on whether accepting it and authorizing the transaction or not much more easier and precisely than just being told that the identity is Level 2 because it can evaluate the risk. The figure can dynamically change as well. This should apply to private and public sector equally.
It may be an interesting topic to discuss at the The Berkman Center Law Lab’s Gov 2.0 Workshop: Governance as an Open Platform September 8
Related Article: Risk based security decisions and CX
a) N parties need N*(N-1)/2 contracts
This would be true if all parties would have symetric relationships. However, some parties (large application providers or network operators) have relationships to many (thousands or millions of) subjects, whereas subjects usually have tens or hundrets of relationships to relying parties. This is why communities larger than 20 or 50 users are in fact possible.
Besides that, the problem remains that bidirectional contracts do not scale. It just happens at gibber numbers.
b) Level 2 is not useful to the RP
I disagree patially. Most applications requiring LoA 2 will not have a risk analysis performed, but are implemented with baseline security, whether that is formalized or not. And if there is no formalized risk analysis, it is good enough if the IdP can proove that its operational safeguards are the same or better if the RP would do it itself.
For high-risk or high-volume applications it might, however, be a good idea to specify liability limits. I would recommend to do that in a more legal fashion, like with registered letters or parcels, without mathematical bias, Finally, it nees to be understood by non-technical people.
Rainer Hörbe
Hi Rainer,
a) N parties need N*(N-1)/2 contracts
The large provider in your example actually is working as a trust framework provider in effect.
b) Level 2 is not useful to the RP
I am not saying it is useless. It in fact is useful. However, having those variables that I sited makes it more useful. Also, doing it through snail mail does not scale. I would rather do it electronically. It can equally be legally acceptable (at least in some jurisdiction.)