Level of Assurance

Paul picks up on an article by Pam about level of assurance with Windows CardSpace. He emphasizes the important point that assurance is not only affected by the underlying technology, but also by non-technical parameters like contracts.

I would go one step further and say that LoA is almost exclusively affected by non-technical factors. To be able to put any trust into a given authentication system (let alone an authorization system) you need minimally:

  1. A contract between the RP and the IdP
  2. A contract between the user and the IdP

Both contracts need to have provisions for the following areas:

  1. Data governance (including privacy assurances and data handling)
  2. Fault handling
  3. Data updates
  4. Contract termination
  5. Liability
  6. Arbitration and conflict resolution

Without such a framework most authentication and all authorization systems are only useful for ‘low-value transactions’ such as blogging or simple social networking. Or – in other terms – there is no level of assurance, even if the underlying technology supports the most fancy certificates or crypto algorithms.

Obviously, contracts of such kind can only be meaningful and economically viable, if the underlying technology is not broken and has the necessary features to support such provisions[1].

Now, as far as the Windows CardSpace identity system is concerned, there are indeed multiple levels of assurance for the RP:

  1. No assurance – self-managed cards, or any managed card where the Issuer is not enforced by the RP
  2. Assurance – managed cards where a particular set of Issuer(s) is required by the R

Only in the later case there can be a reasonable level of trust by the RP that the user is actually who he/she claims to be relative to a given IdP. In that case the contract provisions between the RP and the IdP are in effect and it will depend on them how much trust the RP can put into the authentication and attribute statements.

The Liberty identity system has the necessarily technology and the business and legal frameworks for providing a very high level of assurance, but they are currently not ideally equipped to address the needs of little or no assurance (which typically include fast and extremely easy deployments). Hopefully, openLiberty wil help address these issues.

tag: , ,

[1]Thus, any identity system that relies on an universal federation (i.e. any IdP is admissible) cannot provide any meaningful level of assurance.

Leave a Reply

Your email address will not be published. Required fields are marked *