Stork and other assurance frameworks

As I wrote earlier am involved in the Dutch OpenID.nl+ initiative to help grow the acceptance of OpenID (and to a lesser degree Information Card) in The Netherlands. Within the initiative Identity Providers and Relying Parties define an interoperability standard whereby Relying Parties can rely on digital identities from Identity Providers, based on the verification level of identity attributes by the participating Identity Providers. RP's can authorize users based on the verification information in the claims.

The Trust Framework is based on the assumption that trust derives from the reliability of the identity provider (including the reliability of the identity priovisioning process) and from the reliability of the use of a digital identity. Meaning that there are two parameters: trust in the identity as verified by the identity provider and trust in the use of an identity by the individual owning a digital identity (proof of posession). IdP's must adhere to a certification scheme to prove their reliability. The OpenID.nl+ initiative manages the white list with trusted IdP's.


International developments like STORK also define authentication assurance levels, but these levels are a combination of Identification (by the IdP) and the method of authentication (by the user, based on proof of identity). These assurance levels are the product of a mix of both parameters.


The strange issue is that for certain levels a low level of trust in the process can be compensated by using a strong form of authentication. So QAA2 can be the result of accepting an identity that's hardly verified by an identity provider, but requiring a one time password. Strangely, that would mean that the IdP may not fully know the individual who is issued a digital identity, but you know for sure that the user of the digital identity is the rightful owner of the identity. So someone logging in as Mickey Duck may not really be Mickey Duck, but he is the rightful owner of Mickey Duck's digital id.

In the OpenID.nl+ initiative the net effect may be the same, for most combinations, but the vision on trust is more distinct, the implementation offers a lot more granularity (because of the trust model), although implementing this granularity is not yet part of the roadmap.
In my opinion you shouldn't require a combined assurence level, but you should demand a certain level of trust in ownership of a digital identity and the use of a digital identity.

I will probably get this al wrong, since this model is widely accepted, but then again, maybe I'm not.