Tuesday, October 04, 2005

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

2 Comments:

Blogger Dave Kearns said...

Welcome to the world of blogging, Steve!

But don't be too quick to confuse "identity" with "naming". After all, "lamp post" is more of a role than a persona, isn't it?

:)

3:37 PM  
Blogger src said...

Thanks for the welcome and comment.

Roles are another item of discussion that I would like to discuss in the future. To me, "naming" is a practice that results in a set of well-formed "identifiers." Lamp Post is a very nice identifier. Further, Roles must be referenced by an identifier. In fact, a properly referenced Role could be constructed into an Identity. Consider that I might authenticate to a portal that then asserts to another application that my identity is "Employee." Nothing further need be known about my access request. "Employee" is a role and has become an identity because of a policy statement that allows my access request to act as such.

As for "persona," I just left a comment on your blog giving a little insight into my concept of the term. The concept is an important one and I'm sure we'll discuss it as I move ahead.

thanks again for you comment. -src

7:47 AM  

Post a Comment

<< Home