User-centric vs. Enterprise-centric Identity

In Dave Kearns' newsletter today (you may need to click the "Proceed directly ..." link in the upper right) he began a discussion on differences between User-centric and Enterprise-centric Identity. Here's his summary:

"And there you have it. Enterprise-centric identity management is really all about tying together all the activities and attributes of a single entity into a readily accessible (and reportable and auditable) form. User-centric identity is about keeping various parts of your online life totally separated so that they aren’t accessible and no report can be drawn."

I've been wondering if the model we're building (see diagram in previous post) applies to both, and I think it does. But of course I'd like to hear your views.

I think the lower layers (an Entity with multiple Contexts) are user-centric. Within a Context, I think Enterprise-centric concerns are addressed. Are there any types of service providers that do not have Enterprise-centric concerns? Any service provider that keeps any records about its users is effectively managing Digital Personas. I think.

User Identity Reference Model - 21 Aug 2008

Today at my day job we made lots of progress. A team member had submitted an alternate diagram for consideration. As we compared it with the diagram you see in this blog, we determined they were very close to the same thing! I think the experience helped validate (to ourselves) that we're on a pretty good track, and brought us much closer to consensus. I think we're now to the point of evolving this diagram instead of considering completely separate diagrams.

Nevertheless, the model continues to evolve, and we still have quite a bit to discuss. Here's what transpired today:

• We dropped "Principal" from the label on box 5. It was causing too much confusion even though the description for box 5 points out that Principals are a subset of Subjects (the ones that can be authenticated). We still left the words in the description in case people would complain about an identity model without mention of Principal.
• We opened a new debate about whether or not an account is an example of a Digital Persona. Most team members argued that an Account is how a Digital Persona gets instantiated into some platform that is not yet sufficiently enlightened to rely on external representations of identity. They say a Digital Persona could have multiple Accounts. To me this sounded like getting back to the concept of Accounts described back in my first post on August 7th, but the rest of the team says it's not. I feel like if an account is something different than a Digital Persona, we ought to be able to represent it in the model some way, but others disagreed. Obviously I'm not quite seeing this the same way as others yet -- hopefully we'll get closer in next week's meetings.
• In a comment to the post on Aug 19, PC provided some more views around the concept of Sponsor. This is another place we still have some discord on the team. Personally, I'm starting to think that a Sponsor is only responsible to specify which entities should be included as Subjects in a Context. A Sponsor should not be responsible for authorizing a Subject to do anything (I'm disagreeing with PC on this); instead, the Role management process deals with authorization. I do recognize that a single individual might be both a Sponsor of the Subject, and an approver in a Role management workflow that handles the Subject's authorizations.
• One last new area of contention: I wonder why one Subject might have only one Digital Persona, but another might have multiple Digital Personas. What's the difference? I think it's because of the functions (roles?) that a Subject plays within the Context, so I suggest that a Subject's Roles might result in additional Digital Personas being established for the Subject (and the model currently shows that a Role can have multiple Digital Personas for a Subject). That idea didn't sink in with the rest of the team.

As we resolve some of these differences of opinion, the model could change significantly, especially within the "Digital Realm" section. Please stay tuned.

And PC, please don't be discouraged that I disagreed with you. Keep arguing your point and you may change my mind.

Click the diagram to enlarge today's version:

User Identity Reference Model - 19 Aug 2008

We met again at my day job. Still far from consensus. Some people are suggesting completely different approaches. Changes from the prior version include the following:

• Changed Personae to Personas at the suggestion of a tech writer.
  
• Removed the one-to-many link at the left of box 5. It depicted that a Digital Persona could have multiple other Digital Personas. In today's version a Digital Persona can still have multiple roles, and a role can result in multiple Digital Personas (e.g., accounts, certificates) for the represented Subject. This builds on an idea that if a subject has multiple Digital Personas, there's probably a reason, and that reason could be expressed as criteria for being assigned a Role (with resultant Digital personas).
• Removed Attribute from box 6. An attribute describes either a Digital Persona, or the Subject represented by a Digital Persona, so the concept of attribute has now been moved inside box 5. Roles are still a separate box, because they tend to be assigned, rather than inherent to the Digital Persona. True that a role may be expressed in the form of an attribute in a directory; but if it's an assigned value, then we're calling it a role.

We're still wondering/debating if a Sponsor relates better to a Subject, or to a Digital Persona.

Here's the model as of today:

Fred Wettling suggested we take a look at the CIM model (see commend on prior post). I haven't gotten around to that yet, but hope to soon.

User Identity Reference Model - 15 Aug 2008

Yesterday at my day job seven of us met to further discuss our ideas for a User Identity Reference Model. Lots of ideas were floated.

We seem to have strayed from the notion of a simple "stack" model, with some of us favoring Venn Diagrams, others favoring boxes and arrows, and others with other ideas. Hopefully, however this ends up, it will still be relatively simple.

We had lots of debate about terminology (which is to be expected, because today's confusion is what's motivating us to work on a model in the first place). For example, several think that Subject and Entity mean the same thing. Others think that a Subject is the digital representation of the Entity. I lean towards Radovan's description that the digital representation of a non-digital Subject is a Persona. Some of us struggled with the notion of Digital Persona vs. Account; are they the same thing or not. I think an Account is one of several ways to instantiate a Digital Persona; other ways include a directory entry, an X.509 certificate, and probably other ways. Please let me know your reactions to the definitions in the diagram below.

Some of us think that Authenticators should be depicted in the model. Some of us think it's better to leave Authenticators off, and describe Authentication as the act of a Subject proving to be represented by a particular Persona.

Some of us wanted to jump straight to a company-specific model and then make a more general version for use beyond the company. Some of us wanted to focus on a generic model first, and then use/test the model to describe our company-specific approaches to Identity.

Consensus has not yet been achieved, but I think we're making progress. My preferences are depicted in the diagram below (click the diagram to make it larger).

User Identity Reference Model Evolves.

Today I read Radovan's comment, and then read his whitepaper Basic Properties of the Persona Model. It was a good read because earlier today I met with others at my employer to discuss our ideas for the model. They suggested a couple changes (such as recursion at certain layers) that bring it closer to Radovan's model. We're going to meet again on Thursday to try to evolve the model some more. Perhaps it will get even closer to Radovan's.

Radovan also raised a concern that "only access to the account can be authenticated, not really the person", and that you cannot be sure that "...the physical person really corresponds to the user of the account." At my employer we're trying to move away from authenticating at the account, and instead authenticate closer to the person with a smart card, or accept a partner's assertion of an authentication event that happened at the user's home company/organization. For the users with smart cards we'll have pretty good assurance of who the actual user is. For the assertions, we won't honor the assertions unless we're satisfied that they provide a particular degree of assurance. I'll be interested to get more feedback from Radovan (or anybody) on our approach to move authentication away from accounts.

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.