When an electronic identity (handle) is bound to a person, different methods of identifying that person can result in different levels of assurance of the electronic identity of that person. (As an aside, the level of assurance is subsequently tied to the ability of the user to follow terms of use, including the selection of a strong password and not sharing the password with others.)

This table demonstrates different methods of identification and how they rank in assurance:

Note that the above scale does not define sufficient strength. It is up to each application to determine what is a sufficient level of authentication for its own purposes.

A user's level of assurance is determined by the most recent manner in which he or she identified himself or herself to the organization. Thus, if a person initially provides a Level 4 identification as a student but then (after graduation) reidentifies using Level 1, the person's electronic identity is only assured to Level 1. The earlier Level 4 assurance has been invalidated.

If used with an Identity Recovery mechanism like Sphinx, successful recovery of the identity maintains the level of assurance. This is because adequately selected secret questions have the same level of security as adequately selected passwords.

Other mechanisms may affect the user's level of assurance. In the scenario where a user requests that a one-time-use URL that would permit a password change be sent (via email or post) to an address previously known to the organization, the user's level of assurance would become Level 2, regardless of what it had previously been. If a user telephones an official at the organization, the level of assurance changes according to what the official is able to ask over the phone, with the highest possible value being Level 3.

Implementation of Gu Gong may proceed in one of two ways. The first places the level of assurance directly into the authentication mechanism (Kerberos). This implies that all current handles become Level 2, and that applications which accept weaker assurance or which require stronger assurance must make special calls to the KDC to determine the level of assurance involved. Specific technical details are still under investigation, however this approach will likely require significant (though not insurmountable) changes to the existing ID system.

The second places the level of assurance into the authorization system (LDAP). This requires all applications that require higher than Level 1 assurance to make a special call to determine what level of assurance is attached to the identity in question. Specific technical details are still under investigation. This approach will likely require fewer changes to the existing ID system.