Thursday, August 7, 2008

User Identity Reference Model

Discussions about computer networks and communications often include mention of the OSI Reference Model to help explain the particular concepts being discussed. I think a similar model for user identity would aid in the frequent and complex discussions about identity management. Fitting terms such as subject, principal, account, persona, context, and entity into such a model would foster more consistent use of terminology and better understanding of concepts.

While cogitating what such a model might look like, I thought perhaps a blog would be a way to engage others in defining such a model. Indeed this provided the motivation for me to finally start a blog.

To begin discussion, I submit the results of my thinking so far. Some colleagues suggested that, like the OSI model, the more physical aspects should appear nearer the bottom of a layered stack, so it may prove easier to read from the bottom up.

User Identity Reference Model Layers
  • Privileges - Entitlements (e.g., CRUD) to access particular resources (information, applications, and functions within applications) that may be either explicitly assigned, or may be derived by policy from users' roles & attributes.
  • Platform Roles & Attributes - One or more administration abstraction layers from which a user's privileges within a platform or application can be derived.
  • Accounts - Instantiation of identity into a particular platform or application enabling association of information supporting authorization, logging/audit, collaboration, preferences/profile, system resources, etc.
  • Provisioning Roles & Attributes - One or more administration abstraction layers from which users' accounts (and perhaps some entitlements within the accounts) can be derived.
  • Context - Within a realm, a principal may have multiple contexts (e.g., both customer and supplier). A context is similar to a persona, except it's within a particular realm. An entity’s multiple contexts within a particular realm may be linked to enable single sign-on within the realm.
  • Subject - A person or thing represented or existing in a particular realm which is being described or dealt with. An authenticatable Subject is a Principal.
  • Persona - A relationship between an entity and some realm such as an employer, bank, school, library, etc. To respect an entity’s privacy, the entity’s persona in one realm should not be linked with the entity’s persona in another realm unless such linking is explicitly enabled by the entity.
  • Entity - The thing (concrete or conceptual) represented by identity data.

1 comment:

Radovan Semancik said...

I have designed similar model some time age, but it was more "deeper" into the problem and less directly applicable. Details can be found here:

http://storm.alert.sk/work/papers/files/semancik-basic-properties-of-persona-model.pdf

I think that the fallacy of your model is that you do not make distinction between the physical entities and virtual entities. E.g. only access to the account can be authenticated, not really the person. You may think about different "assurance levels" that the physical person really corresponds to the user of the account, but you cannot ever be sure. Therefore it is a mistake to see these two entities as identical. While I can see that your approach may provide more understandable result, however if you do not consider such distinction the model that you create may not be valid.