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 . . .

Continuing . . .

The problem with this Authenticated Identity Nirvana is that each of the places accepting such an Authenticated Identity would have to “trust” that all of the authentication policy issues are common among them all. That would mean that Amazon.com would have to agree that the Novell authentication I perform in the morning satisfies their authentication policy and that the UserID passed to Amazon.com by Novell could be used to access the Amazon.com databases without question. Not only is that being overly trusting, it would be bad business practice. Each enterprise has an obligation to their investors to be prudent in their business practices to ensure success; and putting that kind of trust in another company would be very imprudent.

The answer must lay in a middle ground. Enter stage left: efforts such as Liberty Alliance and SAML 2.0. The Liberty Alliance is formed by the participation of concerned enterprises to allow for the Federation of Identities.

Federated Identity: The association of disparate Identifiers between disparate parties via commonly agreed upon Authentication Policy and Attribute naming schemes.

In the case of Federated Identity, it is not the Identity that is used, rather it is the Identifier provided by the federation process and the agreement on specific Authentication Policies that used. This Identifier and Authentication Policy assertion are trusted because the information is provided in a digitally signed assertion (e.g., SAML). Also, the Identity Provider (IDP in Liberty terms) may be associated with the recipient of the Identifier via a legal contract spelling out the Authentication Policies to be used in each circumstance; the contract may provide remedies for breach of contract.

So, now we have something that represents an Authenticated Identity that survives process boundaries and can exist as an object in its own right (in the case of Liberty Alliance, it is a SAML assertion), however, we want more-much more . . .

More later . . .

The Authentication of an Identity

I’d like to follow my last post with a discussion of Authentication, a process having a good deal of mystique surrounding it. On one hand, we’d like to have a very easy-to-use and very-strong authentication process. On the other hand, once we’ve “authenticated” we’d like that single authentication to satisfy all future authentication requests, this is called Single Sign-on. To keep the discussion on track, I’ll restate some definitions from the Identity Glossary:

Authentication: the process of establishing the validity of DPI according to policy that expresses the requirements of authenticity.

Authenticated Identity: the result of successful Authentication.

DPI (Decision Point Input): Attribute and/or data that is provided to the Policy Decision Point.

Authenticity is another slippery slope. To establish “absolute assurance of authenticity” we may need to expend “infinite resources.” This is unacceptable, therefore, we compensate by defining our risk – what are the consequences and likelihood of allowing a false authentication through--what is the cost of being wrong. Having evaluated the risk, we settle for stating a policy that, if satisfied, provides an acceptable assurance of authenticity. This is called the Authentication Policy.

Authentication Policy: a stated policy that provides assurance of authenticity within the parameters of the policy.
With an Authentication Policy in place we all agree that satisfying the parameters of the policy will provide us with a statement of authenticity that we are willing to live with. Unfortunately, it is often the case that Authentication Policies are put into force without evaluating them in this light (e.g., using simple UserID and Password to protect highly valuable information).

So, policy is at the heart of the matter. In the case of authentication, there is an Authentication Policy that must be satisfied before we can become “authenticated.” Most of the world hard codes this authentication policy as “If the application can perform an LDAP BIND using the UserID and Password supplied by the user, then change the request state from unauthenticated to authenticated.” The application is configured to use a specific LDAP directory, the application sends the UserID and Password as arguments to the BIND, and if “OK” comes back then the application allows the requests, on that connection, to traverse code paths that do what the user expects.

Thus, if the authentication was performed by a portal, then all of the applications controlled by the portal will suddenly become available; unless, of course, any of the applications are “legacy applications” and are, themselves, configured to authenticate the user by binding to a configured LDAP store. The integration of legacy applications into an integrated framework requiring only one authentication process becomes an exercise in figuring out how to satisfy each of the individual authentication mechanisms in each application.

Some solutions to the problem involve synchronizing all of the directory or database stores (Identity Stores) used by the multitude of applications. Sometimes many applications can use the same Identity Store. Other times, the UserID and Password for each user must be replicated between many Identity Stores. Unfortunately, this only allows the user to use the same UserID and Password on each system. In order to complete the single sign-on effort, the integration framework must save the UserID and Password from the user’s original authentication and “play it back” each time requested.

However, we just introduced several big issues.

First, the user’s UserID and Password are being distributed without the user’s knowledge and inspection.

Second, the UserID and Password are hanging around to be replayed and are more vulnerable to disclosure. (Please note that there are some very good deployments of these types of solutions that, because of the deployment constraints, are very secure and work very well).

Third, if we are replicating the UserID and Password of each user throughout a framework, and some of the directories (or databases) that are a part of the replication are not fully trusted by the user or owner of the user’s account (e.g., the enterprise), then we just put valuable information in the hands of someone we don’t trust. For example, let’s say that one of the systems to be hooked into the single sign-on framework is a book service that allows any of the employees of an enterprise to read any of the on-line books that are provided by the service. This book service is a separate business, so replicating the UserID and Password for each employee to the book service allows them to have valuable information that could allow someone to impersonate a legitimate employee.

Well, to make a very, very, long story short – there are many schemes for solving each twisting turn of the problem. Some are less intrusive than others and some more secure than others, but trade offs are the order of the day. What we wish for is that the end result of the Authentication processes would be something tangible, what the glossary terms an Authenticated Identity in a form that can be shared; an Identity that can be instantiated and exist outside of process boundaries; something that is not a program state change but, rather, a persistent object that can transcend process and environment boundaries.

Authenticated Identity: the result of successful Authentication.

More later . . .

Identity: what, why, how, when

I work with some real smart people and I count myself lucky to associate with them. Most of them work in identity related businesses and, as a result, we have some very interesting conversations concerning Identity. Because we all work daily considering Open Source issues, by nature, we think in multi-platform and Open-friendly terms. This results in our conversations having a different twist that other conversations about Identity may have. I have thought that others might be interested in my take on the issues and concepts we collaborate on--thus, this blog.

I'll open by defining Identity in the context of what we have termed, “Open.”

What is Identity? I would advance that Identity is a way of naming a thing such that “the thing” can be recognized. The term “Lamp Post” is an identity and someone saying, “I’ll meet you by the lamp post” would expect that you could at least recognize something termed a “lamp post” and that there is a mutually known lamp post that would provide us with a place to meet. If the reference, however, was, “The buried treasure is 40 paces north of the lamp post,” you would be very anxious to know “which lamp post.” If there is only one in the context of the reference, then there is no problem. But, lamp posts tend to be ubiquitous and you would need a lot more information to recognize the specific lamp post being referred to.

I’ll start advancing terms at this point:

Attribute: a measurable characteristic of something.

Identifier: an Attribute that is useful in distinguishing something.

Thus, “lamp post” becomes an Identifier. But, as per our observation above, just knowing the identifier isn’t enough to find the buried treasure. We must know something else about the thing we are trying to recognize. Suppose we said, “blue lamp post?” We have added another Identifier with the intent that the object we are trying to recognize becomes apparent.

Sometimes we want information associated with an Identifier to be a “Secret” so that it is more indicative of “insider knowledge.” A password is a good example of a Secret. More effort is extended to keep a Secret from being disclosed than is generally extended for an Attribute. Note that a Secret may never be saved as an Attribute but have only an association with other Attribute(s).

Secret: input that is protected from disclosure and that can be validated against Attributes to establish authenticity.

OK, enough of that discussion. Cutting to the chase, an Identity is constructed from applying one or more Identifiers, zero or more Attributes, and zero or more Secrets to one or more Policies such that the object being identified can be recognized. Or, in short

Identity: a grouping of associated Attributes representing a participant.

Many identity-types are now saying, “But, you forgot to say, ‘Context’.” In our conversations about Identity, we expect that context is a part of the process of evaluating a Policy. Thus, Identifiers and Attributes are arguments (Decision Point Input or DPI) supplied to a Policy Decision Point (PDP) to determine if a specific Policy can provide a definitive statement concerning an Identity (Decision Point Output or DPO). The Policy Enforcement Point (PEP) is responsible for enforcing the definitive statement. It is the intersection of DPI and the PDP that defines the context of the Identity (after all, an Identity is really not of much use unless it is being tested against some criteria to allow or deny access to a resource, for example, and it is the testing that constitutes the definition of a context). Note, however, that the resource being protected is itself an Identity that is a part of the DPI.

DPI (Decision Point Input): Attribute and/or data that is provided to the Policy Decision Point.

PDP (Policy Decision Point): a process that is responsible for evaluating Decision Point Input according to an explicit Policy statement and providing Decision Point Output.

DPO (Decision Point Output): Attribute, data, and/or disposition that results from the evaluation of the Policy in the Policy Decision Point.

PEP (Policy Enforcement Point): a process that is responsible for enforcing a Decision Point Output.

Policy: an explicit statement that allows the testing of Decision Point Input by a Policy Decision Point resulting in the ability to produce Decision Point Output. This results in the definition of relationships between Identities.

How does all this work? Let’s suppose that you were given a note and told, “Give this note to Steve Carter.” In this example, you, the note deliverer are the process that constitutes both the PDP and PEP. Depending on what you know about me, you will determine if you recognize me as “Steve Carter.” If you don’t know me you might, perhaps, ask to see my driver’s license. If this satisfies you then the explicit policy you just used was, “If the driver’s license has a Name of ‘Steve Carter’ and the Picture looks like the bearer, then allow the delivery of the note.”

But, maybe this isn’t enough. Perhaps you have extra knowledge that “X” is my birth year, “Y” is my eye color (both are Attributes on a Utah driver’s license) and that the license for the “Steve Carter” you are looking for must have been issued by the State of Utah. Now, when you ask to see my drivers license, much more is going on. The policy statement now becomes, “If the Utah driver’s license has a Name of ‘Steve Carter’, a picture that resembles the bearer, and the Birth Year is ‘X’, and the Eye Color is ‘Y’, then allow the delivery of the note.”

Now let’s separate the PDP and PEP. Let’s say that you are told to deliver the note to “Steve Carter” but must verify my identity via cell phone before you deliver it. You are told to perform the initial recognition via the driver’s license Name and Picture and then to call a number stored in the cell phone memory. You are now the PEP. You recognize an event (found a person that might be “Steve Carter”), you call the number and are asked for more information (you are providing DPI). Maybe you are even instructed to ask me some questions (more DPI). All of this is spoken into the cell phone and the process on the other side of the line (the PDP) renders a decision based on the DPI that you, the PEP, have supplied. You hear, “Give the subject of your interrogation the note” (this constitutes the DPO). Notice that the determination of Identity is not because the subject is really “Steve Carter,” but because all indications from the information supplied to the policy evaluation make it reasonable to conclude that the subject of the interrogation is “Steve Carter.” This last distinction is the basis of identity theft which, I’m sure, will be discussed in a later post.

To round things out I’ll supply the following definitions of terms:

Authentication: the process of establishing the validity of DPI according to policy that expresses the requirements of authenticity.

Authenticated Identity: the result of successful Authentication.

There are several holes in this discussion. For example, we didn’t bother to supply the DPI source(s), DPO target(s), PDP, PEP, and Policy Expression with an Identity. Likewise we didn’t provide the Note or the cell phone with an Identity. In today’s business climate of “compliance assurance” we are sorely lacking . . . but that gives me a reason to come back.

More later . . .

Under Construction

We cannot open ourselves to new insights without endangering the security
of our prior assumptions. We cannot propose new ideas without risking disapproval and rejection.

-Robert Grudin, The Grace of Great Things