Using Context Sensitive Identifier Mappings -- Lessons in XRI and XDI

The XRI Resolver provides a flexible identifier mapping that allows a service type to be passed to the mapping along with the identifier. The canonical example is where the two identifiers @ootao*steven and =steven.churchill map to the same XRI authority when asking for the OpenID service--thus allowing both identifiers to share the same OP account and password--while the same identifiers map to two different XRI authorities when asking for some other service type.

But this flexibility leads to an entity/identity model that can be hard to understand. I've written a paper in order to help navigate the territory: ftp://sandbox.myxdi.net/papers/context-sensitive-identifier-mappings.pdf.

Systems using Binary Identity Models

When dealing with identity system constructs, such as end users logging into online accounts and the like, I often find it useful to decompose the actors into a system of connected binary identity models. It's kind of like two stars falling around each other in a mutual gravitational embrace.
Or something. :-)

A Simple Identity Model (SIM)

In so doing, I employ a very atomic and simple abstract identity model. The following is the definition of the Simple Identity Model:

A formalization of entities and their groups. The formalization includes that which distinguishes entities within the group.

Some definitions are in order: An entity is simply something that can formalized, and a group is just a collection of zero or more entities. The definition of identity, in this context, is simple and natural: "that which distinguishes entities within a group". (See again the definition of the "Simple Identity Model" above.)

Examples:

SIM1:   My poker buddies
I play poker with this group every third week.

Entity:    A human being with which I play poker.
Group:     Jim, Craig, Karen, Lee, and sometimes
           Blake.
Identity:  Distinguished using my normal means
           of separating humans (name, appearance,
           etc.)

SIM2:   My online widget store's user accounts
My company has a website that it uses to sell
its widgets.

Entity:    Record in the user_account SQL table
           (along with all child records in
           tables email, phone, purchases,
           etc.)
Group:     All records in user_account table.
Identity:  Distinguished by PK of the
           user_account table.

SIM3:   My blogging website's user comment
        identifiers
My company offers a blogging web site where
users can leave comments on blog postings
if they leave an unique identifier (in the
form of a URL).

Entity:    Unique "comment identifier URL"
Group:     All "comment identifier URLs" ever
           used at the blogging website.
Identity:  Distinguished by the text value
           of the URL.

Here's a quick look at the notion of authentication within the three identity models:

In SIM1, any notion of authentication has to do with my inherent ability to distinguish human beings. (Usually, when I get to the point where I cannot distinguish Craig from Karen, that's when I know that I've had a few too many beers at the old poker table.)

In SIM2, there needs to be a means of verifying that an end user behind a web browser has been authenticated as the owner of a given account. (We are, after all, going to bill his or her credit card, so authentication would be very helpful.)

In SIM3, there needs to be a means of verifying that an end user behind a web browser has been authenticated as the owner of a given comment identifier URL.

If you look closely, you may notice something: None of the three identity models above say anything whatsoever about the notion of authentication (or an end user.) So why don't the SIMs cover this?

It is because the abstract identity model definition (repeated here, from above) ...

A formalization of entities and their groups. The formalization includes that which distinguishes entities within the group.

... does not have any support for notions such as authentication or end users.

Expand the model?

It might be tempting at this point to say that the Simple Identity Model is not very useful--that it doesn't support constructs such as end users and authentication--and that we would need to add these constructs in order to make it useful.

I think it better, however, to keep the identity model abstraction in its atomic form.

Instead we can model the authentication and the end user by spinning off, so to speak, a new SIM--call it SIM4--and then by defining the connections between two SIMS. (And, woohoo, we will have our system of binary identity models.)

Let's look at SIM2. We need a way of verifying that an end user behind a web browser has been authenticated as the owner of a given account, so that he or she can buy widgets. We spin off SIM4 to define that user.

SIM4:   End users who have accounts at at my
        online widget store
... and who we'd like to authenticate, because
we are going to bill their credit cards.

Entity:     Human being who buys widgets at my
            company's online widget store.
Group:      All the human beings who buy widgets
            at my company's online widget store.
Identity:   Distinguished by the Cardspace PPID
            used to communication with my the
            online widget store.

SIM Connections:

We can now formalize connections between the entities of the given identity models. (Conceptually, we can draw the lines between the entities in one SIM and the entities in another SIM.)

For example, the connection between SIM4 and SIM2 can be formalized as: the entity (the end user) in SIM4 uses the entity (the user account) in SIM2 when he or she buys online widgets. It should be noted that the connections are not necessarily one-to-one. For example, a given end-user in SIM4 might use two separate accounts at the widget store.

Authentication, then, is simply whatever means used to validate a given entity connection between two identity models.

Summary:

Rather than attempting to complicate a simple identity model by adding constructs such as authentication, it is better to keep the abstract model in its most atomic form and then to define notions such as authentication in terms of connections between entities in different identity models.