Continuing 2 . . .

Before continuing with federation and federated identity, I’d like to address a concept that I think strengthens digital identities considerably and increases the viability of federation. This is the concept I call Attested Identity.

In today’s world, digital identities are accepted as valid if they come from a source that is associated with the authentication. Thus, if I authenticate to a service, say Amazon.com, then all of the information in the user record for the authenticated entity is considered a valid part of that identity. It is all or nothing, there is no way to partition the information into segments, some of which are more reliable and some less reliable. In other words, the Authentication Policy (see previous post) provides the assurance of authenticity for all of the information associated with the identifier of the authenticated account. This seems to be a questionable practice to me.

What if the address in the record is wrong (purposefully or not)? While I agree that it is “authentic” as far as asserting that the “creator of the account typed it in,” I assert that it would be far better to have a means and method for asserting that “the address is known by x” where the “x” is replaced by an entity attesting to the validity of the “address.” This “x” may be the US Postal Office, or the UPS Store, or Mailboxes Etc., or a campus mail system, or whatever. The bottom line is, Attributes associated with an Identity should be attested to such that the Authentication Policy can provide assurances of authenticity for the Attributes independent of the place where the attributes are stored. Of course, policy specifications will determine if the attester of the attribute (collection of attributes) are acceptable for any particular use.

The concept of Identity and the attributes associated with Identity current in the art, should be upgraded such that each Attribute or collection of Attributes may be independently validated—or have an associated authentication policy to provide assurances of authenticity.

While the example of “address” may seem trivial, consider the utility of having an “address” attested to by Visa as a valid address associated with a card-holder’s account. Note here that the card number and/or card-holder name need not be asserted, just the fact that the address is valid according to Visa. I won’t go into the “digital signature counter-singing” that is needed for this to work—but those methods exist and would allow for the validation of “address” separate from the fact that it exists at Amazon.com. In fact, proper use of digital signatures would allow for a condition that one of my friends termed, “Identified Anonymity” (remember, I told you we were an odd bunch). In other words, the subject or principal is anonymous, but the information being asserted is identified as being directly associated with the anonymous identity. Identified Anonymity is a very powerful concept and is possible via Attested Identities.

Consider further that some trusted attester (e.g., the DMV of the state issuing your driver’s license) could provide digital attestation concerning your Gender and Age Category. If a chat room were to require attested attributes that were digitally counter signed appropriately, much heartache would be alleviated. I understand that Attested Identities would have to become a part of a broader identity framework, but such seems to be gaining ground in the industry and will soon allow for such a provision.

Let me add a few terms to our glossary (BTW, it is my intent to provide the glossary as a document in a few weeks):

Attestation: a legal statement that is admissible in a court of law without an affidavit (http://en.wikipedia.org/wiki/Attestation_clause).

Digital Attester: one who provides Digital Attestation.

Digital Attestation: a verifiable statement that is verified via a specific policy that asserts the authenticity of digital information. The verifiable statement is usually a digitally-signed document containing the digital information being attested.

Attested Identity: a Digital Identity wherein specific Attributes have been Digitally Attested to by a Digital Attester. An Attested Identity has more efficacy than a Digital Identity because specific groupings of Attributes can be verified independent of the Identity Store. Also, Authentication Policy can be declared such that the Digital Attestation of specific Attributes must have policy-specified characteristics before being trusted.

Identified Anonymity: methods and data structures providing for the association of an identity with attributes such that the owner of the attributes remains anonymous but that the association of the attributes with the identity is validated. Assurances of authenticity are therefore based on countersigned attestations.

As a parting shot, one of the fellows I work with made the following observation concerning Attested Identity:

. . . about methods for asserting the validity of an attribute. What happens when the "quality" of the validation for the attributes of an identity is very dissimilar? For example, my address is attested by, say, Visa, but my telephone number is attested by, for example, "me". Can you use those two in conjunction to attest an identity, or a collection of attributes? Do you need to have policy that determines what 'attesters' are acceptable when you validate a collection of attributes? Are there limits to the validity of an aggregation of attested attributes? Obviously there's value to the concept, but I'm not sure whether it can be made secure enough without cumbersome aggregation policies.

Point well taken, I’ll address these issues as the blog plays out. Obviously, today we don’t have this problem because everything in a single identity vault (directory) is trusted the same and the pedigree of the information is not known.

More later . . .