Thursday, September 25, 2008

What's Next for the User Identity Reference Model?

Last week at my day job we concluded that the model has progressed far enough that we'd like to refocus our efforts from developing the model to actually using it to solve some problems. This week we met twice and began tackling the tricky issue of testing IDs.

What's so tricky about testing IDs? Maybe it's not so difficult to test a little application that has it's own list of users and associated permissions. But think about a large enterprise with infrastructure services for identity and security. Developers (and potential vendors) are encouraged to externalize security from their applications by leveraging the infrastructure services. For example, don't build a user store into your application; don't even prompt the user for ID and password that then gets verified against the enterprise directory. Instead, rely on the enterprise authentication services to authenticate a user and to assert the user's identity into the application; rely on enterprise authorization services to make consistent policy-based access decisions that can be leveraged by the application. In an enterprise environment like that, how do you create a testing ID that can be used to exercise the functionality of one application without enabling the testing ID to inappropriately access any other applications or data beyond the application being tested? For example, if a testing ID for one application needs to appear as a manager and a US citizen, how can we ensure the testing ID cannot be used to inappropriately access other applications or data that is intended only for managers and/or US citizens? It's tricky.

Anyway, we found the model in its current state to be very useful. It was a big help to have everybody looking at the same picture and definitions, so we could effectively communicate our various ideas to each other. After we finalize our approach for testing IDs, we hope to use the model to help us figure out our desired approach to privileged accounts, Subjects with multiple Personas, what identifier to use where (e.g., persona identifier vs. account identifier), shadow accounts for users at federated partners, reorganize some of our LDAP Directory Information Tree, etc.

What's next for the model outside my day job? I hears some murmurings of people interested in developing an identity model at some forum better suited to collaboration. We'd love to participate in an effort like that, and we'd be happy to share the contents of this blog in the hopes that it would be helpful.

Tuesday, September 16, 2008

Answering Matt's Questions

Matt posted questions about the User Identity Reference Model on his blog, which I'll try to answer here.

Q. This is just about identifying the types of information that is used to represent an identity. Correct?

A. Correct. At my day job we defined the word identity to mean a set of attributes, at least one of which is an identifier. By this definition, an identity is information, so an identity model would be some form of information model.

Q. Why is Sponsor relevant to this model? Sponsor is important in the provisioning process, but is not part of the identity data itself.

A. We felt that especially for Digital Personas representing non-human Entities it is important to be able to map back to a responsible party that is human (or perhaps a group of humans). At times we have done this incorrectly in the past, and it has caused major headaches. For example, in one of our directories we populate the employeeNumber attribute with the represented user's employee number. Some applications use that employeeNumber to lookup additional user data in other user stores and directories. When representing a non-human Entity in the directory (e.g., a service account) we sometimes put the Sponsor's employee number into the employeeNumber attribute -- Yikes! The applications that use the contents of employeeNumber to lookup additional information in other user stores were seeing that the service accounts had people-type attributes (like citizenship - which is really an attribute of the Sponsor, not the Entity) in addition to service account attributes. We now think it's important to emphasize that the sponsor relationship is not the same thing as the Subject represented by a Digital Persona. We could leave it out, but we favored leaving it in with a dashed line to differentiate it from the other kinds of relationships depicted with solid lines.

Q. What's the difference between an Entity and a Subject?

A. The model agrees with you (and so do I) that when an Entity tries to access a resource, the Entity is doing so as a Digital Persona. An Entity exists even without any Context. A Subject is an Entity in a particular Context. If you've got no relationship to my home company, then you are not a Subject in my company's Context; however, you are still an Entity. At the point you get some relationship to my company, then you will become a Subject of interest in my company's context, and to keep track of you, we'll establish one or more Digital Personas for you.

Your remarks about personas sound pretty good to me. Bear in mind that one motivation for this model is promote consistent use of terms. I noticed your frequent use of the word "context" to describe what you mean by persona. It's unfortunate that Context is one of the proposed components of the model, which make it confusing to use that word to describe other parts of the model. Oh well, even if we used a different word instead (circumstance, situation, meaning, condition???) we'd still have a similar problem trying to differentiate between the general use of the word and the specific name of a model component.

I think your use of the information card metaphor is interesting too. Do you think that within a company an employee would have one card or multiple cards? At my company we think some people have multiple personas within our company. I suppose if/when we use info cards, those people would probably get multiple cards.

Regarding accounts: this whole effort is a bunch of compromises by the several people participating in the discussion. I started off with the idea that an Account is an example of a Digital Persona. However, I was outnumbered, and the majority felt that they have just one Digital Persona at our company, parts of which are represented in each of their many Accounts. Because in the context of our company we each have many accounts, but generally just a single Persona, Account cannot be an example of a Digital Persona (at least according to us). at some point, I don't know that we can declare the model is "correct"; instead it will be great if we can just declare it "acceptable".

Saturday, September 13, 2008

Comments Finally Come In

Thanks to all of you who are starting to participate with comments.

Matt asked for more context to help think about the model. Lets look at it in the context of the very familiar Access Control Model below:

The Digital Realm in the User Identity Reference Model represents what is inside of the "Identity Data" store depicted above. The Subject is the "Requestor" above. This yields a diagram like the following (I inverted the Digital Realm because that seems to look better in this diagram):

Craig suggested replacing Account, IT Role, and Entitlement with a single "Capabilities". At my day job we discussed using fewer boxes in this area too. But we decided that there are different types of attributes associated with a users and we wanted to represent at least the following four types:
  1. Inherent Attributes of the Entity like age or address. We consider these part of the Digital Persona.
  2. Business Roles like manager or CEO. These are inherent attributes of the Subject (or the Entity within a Context), so we also consider them part of the Digital Persona.
  3. IT Roles which are explicitly assigned (as opposed to being inherent to the Entity or Subject). IT Roles are explicitly assigned, probably for purposes of administration efficiency in access management.
  4. Directly assigned Entitlements.
We also debated at length whether or not to include Account in the model. We favored leaving it in because because a Digital Persona can have multiple accounts, and each account could in turn include IT Roles and Entitlements.

Drummond submitted a bunch of questions and comments:

1) Higgins uses some terms differently than this model. that's OK for now. I think what's important is to get the shape of the model close to correct. The labels can change if we figure out better words, or if it would help align with other established models.

2) Regarding the term Sponsor which Drummond suggests is a bit narrow, we think it is the party with lifecycle responsibility for the Digital Persona. A term like "Authority" might work, but it might not be the authority for all the data associated with the Digital Persona, so I don't think it should be "Context Authority" or "Realm Authority", because those would include the IT Roles, Entitlements, and Accounts. An example of a Sponsor is HR, who is responsible for lifecycle of the Digital persona, but probably not responsible for IT Roles, Accounts, or Entitlements.

3) Regarding "IT Role": In earlier versions the box was indeed labeled "Role"; however, we then started exploring the difference between Business Roles (part of the Digital Persona) and IT Roles (assigned for access management). We called it "IT Roles" to differentiate from "Business Roles".

4) Regarding Digital Realm: that's mostly just a comment. Outside the Digital Realm the Entity and Subject are concrete or conceptual things, but when they get represented as Digital Personas they are in bit form. If we include a description of Digital Realm, then the descriptions will be lots taller than the diagram (pretty poor justification). Do we really think it needs a number and description?

5) Regarding Account: Earlier versions described an Account as an example of a Digital Persona; however, we evolved to the view that a regular employee of a company would probably have a single Digital Persona at the company. The employee's Digital Persona is all the bits (even spread across different systems) that represent the inherent attributes of the Subject employee. The Employee likely has several accounts, all associated with the employee's single Digital Persona. So we ended up at an Account is not an example of a Digital Persona; rather, it may contain a subset of a Digital Persona in a format required by some particular system.

6) Regarding Groups: we think of Groups as aggregations, and therefore just a particular form of IT Role.

Note to all: I'm trying to answer these questions the way we did at my day job; I'm not trying to say your ideas are wrong. So if my answer doesn't satisfy you, then please continue the discussion, and push for changes to the model.

Thursday, September 11, 2008


Monday through Wednesday I was at Digital ID World. I hadn't been for the past 3 or 4 years, so it was nice to get re-acquainted with some people I hadn't seen for a while.

I got to talk with some people about the User Identity Reference Model. A few people expressed interest in participating to develop the model. I hope they start submitting comments on this blog.

I also got to speak with some people about a collaboration forum for enterprise identity architects. We're trying to set up such a forum under Identity Commons. A draft charter is visible (and editable if you want to insert your thoughts) at One thought is that we could organize a mini-conference that would occur at the next IIW.

Model Nearing Completion?

Today at my day job we met about the general model. We didn't change the model diagram at all! As for descriptive text, we just changed the last sentence of box #4 about Digital Persona. We think we're near the end of what we can do for the general model, unless some of you step up to provide some feedback and/or alternate thinking. Next we're going to start trying to use the model to describe various identity concepts, current architecture at my employer, desired identity architecture at my employer, etc. If for some reason it doesn't work, we may make adjustments to the model. If it does work, then that helps validate the model.

I wonder if more comments would be submitted if I allowed anonymous comments, so I just enabled anonymous comments. Please include some name in your comments so we can say things like, "Bill said ...".

I got permission to host telecons about the model, so let me know if you are interested in participating. That would provide a more interactive forum, and hopefully foster a more lively discussion.

Monday, September 8, 2008

Does "Account" belong in the Identity Model?

Last week at my day job we made some tweaks to the model such as changing a many relationship to a single relationship, changing the top box from Privilege to Entitlement, and relating Sponsor to Digital Persona instead of Subject. We also discussed whether or not the concept of Account belongs in the model. We ended up the meeting agreeing that Account is a kind of Entitlement and doesn't warrant its own box. However, as I tried to update the diagram and descriptive text, I couldn't make it make sense. So, against the majority in the meeting, I stuck Account back in. Please look it over and comment about whether or not Account should be in or out -- I'll need your support if I'm to convince others that Account should stay in.

Why a User Identity Reference Model?

The first part of this week I'm at Digital ID World. That means fewer chances to meet with my co-workers to further develop the model, but hopefully a chance to catch up on blogging where we got to last week.

At DIDW I'm telling a few people about this blog, so hopefully we'll get some more participation soon. A couple people have told me they'd like to participate in the actual discussions we're having, and I think that might be a good idea. I'll check into it to see if we can host a series of telecons.

When I first started this effort, I hoped we could come up with a simple "stack" (like the OSI Reference Model). It wasn't long before we moved to a diagram instead of a simple stack. I still hope we end up with something very simple. As an example, I've seen versions of the following diagram for access control all over the place. I don't know where it originated (if someone can provide a link, that would be nice), but it seems to have very wide recognition, and even if someone hasn't seen it before, it doesn't take them very long to understand. It's a great tool for introducing vocabulary, for categorizing products, and for describing how various systems can work together.

In my day job some of us are working on a suite of roadmaps, including Authentication, Authorization, Provisioning, and Identity. In the Identity roadmap we had hoped to cover many things; however, limited time and resources requires us to trim down to just a few topics, which are listed here:
  • Identities & Personas & Principals & Contexts (entities with multiple personas)
  • Identity beyond people (applications, devices, etc.)
  • Standard identifier framework (fully-qualified identifiers from multiple namespaces)
  • Third party identity & attribute providers (federation concepts)
For some of these items I'd like to be able to reference a widely recognized identity model, and then use it to help design my employer's approach to managing multiple personas, testing IDs, special IDs (like IDs for crawlers), elevated privileged accounts, application identity, etc. After failing to find such an existing model, we started this activity to build one. Hopefully we can define it in a generic fashion so that it can be useful far beyond the specific needs of my employer.

Monday, September 1, 2008

Identity Model Update

First I have to apologize for being such a sporadic blogger. I just noticed that Peter and Radovan posted comments many days ago, and I didn't get them approved until just now.

Last week my team met twice. A few people came who had not been to some of the earlier meetings. We spent a lot of time level-setting and catching up. On our team one guy thinks only the stuff in the Digital Realm is important, so we can leave the rest off. Another guy thinks that Roles and Privileges are the turf of Authorization and don't belong in the model. If I take out all those, that would leave just one little box, Digital Persona. That would not be a very useful model.

I can see the point about Roles and Privileges. I can agree that the design/engineering of Roles is more of an Authorization architecture than an Identity architecture. Perhaps if we changed the Identity Model to something like Role Assignment instead of just Role, there would be less objection. This week I'm going to focus on working with someone representing our Authorization roadmap effort. Hopefully we'll get his concurrence that Roles and Privileges belong (perhaps tweaking the definitions?), and that will quell the objections.

One guy has also complained that things that should be in an Identity Model aren't there. He specifically suggested Federation, Pseudonymity, and Anonymity. I countered that first we should get the basic model down, and then we should use it to describe concepts like Federation, Pseudonymity, and Anonymity -- similar to how there's no box for Authentication, but it is described in the text as the act of a Subject proving to be represented by a particular Digital Persona. Maybe around Sept 12 we'll be able to explore these concepts with the model (I'll be at DIDW the first part of that week).