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.
