Identity Happens

Don’t Forget the Back-End!

2011-09-29T20:31:00.000-07:00

Over the years we’ve spent lots of time worrying about the security characteristics of various types of authentication tokens, with broad consensus that static passwords reek. And we’ve put lots of thought into the processes we use to vet users’ identity and to bind tokens to users. And of course we’ve put lots of effort into lifecycle management and processes to disable authenticators when they are no longer needed.

NIST Special Publication 800-63-1 is a pretty good exploration of topics like those mentioned above, and describes how they contribute to an authentication event’s level of assurance. However, I don’t see any mention of back-end authentication systems in the NIST document.

We’ve progressed far enough that the authentication back-end systems have now become attractive attack points. Why should attackers try to steal someone’s smart card if they can steal the certificate authority’s certificate signing key? Why should attackers try to replay a SAML assertion if they can steal the IdP’s assertion signing key? Why should attackers try to steal someone’s OTP token if they can steal all the tokens’ shared secrets from the back-end OTP verification system?

Even if attackers are unable to steal OTP tokens’ secrets from a company’s back-end OTP verification system, they may be able to steal the token secrets from the token supplier, or some third party contracted to inexpensively program OTP tokens. Did RSA ever confirm our conjecture that their customers’ OTP token secrets were stolen in a recent breach?

Even if attackers are unable to actually steal secrets and/or keys (thank heavens for hardware security modules), they may be able to compromise the back-end servers to maliciously exercise the secrets and/or keys, thereby generating what appear to be valid certificates, assertions, or OTP values.

Even if attackers are unable to maliciously exercise a back-end server’s secrets and/or keys, they may be able to inject malware onto a RADIUS, LDAP, or OTP server that returns a success status for every authentication, bind, or verification request.

Don’t forget the back-end! Are your back-end authentication servers sufficiently hardened? Are they in secure network enclaves? Are your secrets and keys protected by HSMs? Are single-factor admin passwords used to control access to your multi-factor authentication systems? Are you confident that your virtual machine hypervisor doesn't open attack channels to your hosted authentication servers? Could compromised workstations used for remote administration introduce malware to your authentication servers?

Yikes! How do we adequately protect the back-end? And how should we include back-end considerations in determining authentication level of assurance?

Anything goodware can do, malware can do.

2011-08-08T07:05:00.000-07:00

Over the past couple years I’ve been repeating these words so often that I’m now calling it Schleiff’s Law. It may seem presumptuous or vain for me to name something after myself, but I got tired of waiting for anyone else to do me the honor.

By goodware I mean software that is neither written nor used with malicious intent. And by malware I mean software that is written and/or used with malicious intent.

Much of my time is spent working on ways to better authenticate computer users to the services they access. It’s now generally accepted that passwords provide only nominal assurance about users’ claimed identity. We generally want to attain better assurance, hopefully without severely degrading usability, and at reasonable cost. The following paragraphs discuss how Schleiff's Law applies to various authentication methods:

Soft Certificates
By soft certificates I mean X.509 certificates containing a public key, where the associated private key is stored on a computer's disk (as opposed to the private key being stored in a hardware keystore such as a smart card). I don't like soft certificates because the private key can be stolen or copied by an attacker, and the compromise is not readily evident to the rightful user of the key. Even if the key is not stolen/copied, malware on the PC could perform the same crypto operations that can be performed by goodware on the PC. Even if the private key is protected by a password, malware (e.g., a key logger) could capture the user-entered password, use the password to unlock the private key, and then operate with the private key for malicious purposes.
Hardware-Based Certificates
By hardware-based certificates I mean X.509 certificates containing a public key, where the associated private key is stored on a separate hardware token, such as a smart card. Such credentials are generally accepted as the most secure for purposes of user authentication. I like hardware-based certificates on smart cards quite a bit. I use one every day in my day job, and I think that after a bit of practice, they are reasonably user friendly. However, even smart cards are susceptible to Schleiff's Law. Whenever a smart card is inserted into a PC's smart card reader, malware on the PC could submit requests to the smart card to perform private key tasks for malicious purposes. Even if the smart card is protected by a PIN, malware (e.g., a key logger) could capture the user-entered PIN, use the PIN to unlock the smart card, and then operate with the private key for malicious purposes. At least one vendor of smart cards and associated middleware provides software to detect inserted smart cards, and prompts the user to remove their smart card after a few minutes. Malware can only exploit a smart card's private key when the smart card is inserted into the smart card reader.
TPM-Based Certificates
By TPM-based certificates I mean X.509 certificates containing a public key, where an encrypted version of the associated private key is stored on a computer's disk, and where the encryption was performed by a key in the computer's Trusted Platform Module (TPM) chip. The only place the private key can be decrypted for use is inside the TPM chip, thus protecting the clear text private key from theft (unless of course the whole PC including the TPM chip is stolen). Because the TPM chip is physically attached to a PC's motherboard, it cannot be removed from the PC, and is therefore always subject to malware that might be running on the PC. Even if the TPM chip is protected by a PIN, malware (e.g., a key logger) could capture the user-entered PIN, use the PIN to unlock the TPM chip, and then operate with the private key for malicious purposes.
PC-Based Biometrics
I admittedly know little about biometrics. However, I think that biometrics relying PC-attached readers and/or PC-resident software are also susceptible to Schleiff's Law. If there's software on the PC to enable biometric capabilities, then malware on the PC could enable the same biometrioc tasks for malicious purposes. Even if the biometrics are stored on a smart card, malware on a PC could interact with an inserted smart card in the same way that goodware could.
One-Time Passwords (OTP)
OTP systems generally rely on some sort of token assigned to a user, and in that user's possession. The token and the OTP management/verification system share a secret key. An algorithm that can be executed at both the token and at the management/verification system operates on the secret and another piece of dynamic shared data (e.g., an event counter, or time). Because the dynamic shared data changes on each use (or every few seconds if time-based), the algorithm produces a different result (i.e., a one-time password) on each execution. OTP tokens can be either soft tokens or hard tokens:
- OTP Soft Tokens
  By OTP soft token I mean a piece of software running on a PC, or a smart phone, that knows the shared secret and can execute an OTP algorithm to generate one-time passwords. Execution of the software may require the user to enter a PIN. Such a PIN could be discovered by an attacker using keystroke logging malware. Malware could also invoke the soft token software to generate one-time passwords for its own malicious use. Or, the soft token could be stolen/copied from the user's PC (or smart phone) to an attacker's system to be executed whenever the attacker wishes.
- OTP Hard Tokens
  By OTP hard token I mean a separate hardware token into which the shared secret is loaded, and from which the shared secret can never be extracted. The hard token also keeps track of the dynamic shared data (e.g., an event counter, or time), and can execute an OTP algorithm to generate one-time password values. The shared secret, protected in the hard token, is not susceptible to copying or theft (unless the whole token is stolen).
  - Without PC Connection
    Often hard tokens are in the form of a key fob, and usually with no connection to a PC so they are NOT susceptible to malware running on the PC (or smart phone).
  - With PC Connection
    In some cases OTP hard tokens include a USB connector, and can be connected to a PC. In another case, with Intel's IPT (Identity Protection Technology) the OTP function is provided by an Intel chip on the PC's motherboard. Such cases, because they are not fully air-gapped from the PC, warrant increased suspicion about the token's susceptibility to malware running on the PC.
Out Of Band Passwords
By out of band passwords I mean the delivery of a shared secret to a user on some channel other than to the user's PC. Examples include sending a registration code to a user's home address, or sending a logon code via SMS or text-to-voice to a user's cell phone. Malware running on the user's PC has no access to such codes/PINs/passwords until the user enters the value into the PC, at which point it's probably too late to be of use to malware.

I believe the authenticators most resistant to Schleiff's Law are OTP hard tokens (without any connection to the PC) and out of band passwords. Of course, even though they may avoid Schleiff's Law, they are still susceptible to other attacks, most notably man-in-the-middle attacks.

Identity for Data - MyDataClaims

2011-06-14T23:26:00.000-07:00

I've been tinkering with a new concept (at least it's new for me). It's a way to prove that you were in possession of particular data at a particular time. I hope people will find this useful to protect copyright on their creative works, or a way to protect ideas before revealing them to others, or a way to keep rights to your own ideas that you had prior to beginning work for a new employer that makes you sign away your rights to ideas conceived while employed there, etc.

Anything you can represent digitally (even a sketch on a napkin can be digitally photographed) can be given an identifier, and be tagged with descriptive attributes. And a set of attributes including at least one identifier constitutes an identity (in this case identity for data). I call this identity a DataClaim.

A DataClaim is a signed SAML assertion about some data, with an identifier based on a hash of the data, and including attribute assertions about the individual in possession of the data, a timestamp, and some other info. It will be interesting to get some feedback on this concept. Please take a peek at the following URL:

https://www.MyDataClaims.com

It's not quite in production yet, but the functionality is pretty much in place. After my upcoming vacation I plan to generate a new keys and certificates for signing the SAML assertions, and then I'll declare an official launch of MyDataClaims.

Let me know what you think.

User Identity Reference Model - March Update

2009-03-17T17:03:00.000-07:00

A couple months ago we made another couple tweaks to our identity model (see v20 below), and nothing has changed recently. I think that means we're pretty satisfied with it's current state. We had a grueling couple months trying to figure out our direction for dealing with multiple personas. Now we're evangelizing our new direction and seeking support from around the company.

The new economy has curtailed most of my involvement in external activities. I'm now asked to focus more on internal projects. So to many of my friends, it may appear I'm hibernating until economic conditions improve.

User Identity Reference Model - December Update

2008-12-18T13:17:00.000-08:00

I'm a complete slacker in trying to lead an effort for the Concordia Identity Reference Model. This is due to lack of bandwidth, low levels or participation, and my own frustration at conceptualizing things differently than most other people.

At my day job we continue to use and evolve the model. We used it to facilitate discussion about Testing IDs, and to illustrate our determined approach. In November we shifted discussions from Testing IDs to individuals with Multiple Personas.

Here's today's version of the model:

My Preferences for the User Identity Reference Model

2008-11-12T07:13:00.000-08:00

I haven't yet received any feedback on this version of the diagram, but it represents my current preferences.

Detective Assigned

2008-10-21T08:14:00.000-07:00

It's been a few days and I've had no update on the case of my robbery. So this morning I called the detectives in Boston to see if there's any news. Evidently my case had not yet been assigned to a detective, so they made the assignment while we were on the phone. Detective Walsh got my case -- let's wish him luck (or break a leg, or whatever one is suppose to wish for a detective).

Robbery Update

2008-10-17T16:01:00.000-07:00

Later on Wednesday (the day of the theft) I got to speak with the hotel detective again. He think s he knows who stole my watch and ring. They saw him on the hotel security cameras. The community of hotel security people evidently keeps in touch, because he said he learned from his colleagues at other hotels that the guy was active at other hotels earlier in the week. He asked me to file a police report so they could try to get fingerprints from the coffee cup.

Speaking with the Boston police I learned it could be several days before a detective gets assigned to my case. Frown.

Yesterday I asked the police if it would be worth my effort to check area pawn shops, because I had a couple free hours before I needed to catch my plane home. The policeman said it was a good idea, and that occasionally someone is able to find their stolen property at a pawn shop.

I looked in the yellow pages and found two pawn shops within 15 minutes walk of the hotel. In all my life I had never before been in a pawn shop, so I was beginning to look forward to a new adventure.

In the first shop reality hit. The shopkeeper said I might have a very slight chance of finding my watch, but a gold ring would just be quickly melted down and used for other jewelry. I asked if there might be certain shops where stolen jewelry is more likely to show up; he said that any jewelry store buys gold jewelry, and that a thief would go to a jewelry store before a pawn shop because at a pawn shop they have to fill out paperwork, and at a jewelry store they can just sell it.

Onward to the next planned stop, which was around the corner and about three blocks away. Rounding the corner I immediately saw a jewelry shop with a large sign indicating they buy old jewelry. Upon entering the store, I saw it was more like a mini-market than a single store. Counters lined both walls all the way to the back of the store. Every 8 or 10 feet of counter was staffed by a different vendor. That was a LOT of second hand jewelry to look through.

Continuing my journey to the planned second stop, I encountered two more of the jewelry mini-markets. After looking through five shops in three blocks, and seeing that the same type of neighborhood extended for many more blocks, and assuming I'd continue to find a jewelry shop or two on every block, I determined that this haystack was much too large.

Every time I look at my bare wrist to see what time it is, I feel hassled that I now have to look somewhere else. But the loss of the ring is much worse. There's a lot of sentimentality attached to a ring of almost 19 years. Also, some of you who know that I'm a consummate fidgetter, and that my ring was my favorite subject to fidget with. Now I feel a loss every time I reach for my ring to give it a spin on the table, or move it from finger to finger, or slide it up and down my tie, etc.

I'm thinking about contacting the jeweler who made my original ring so long ago, to have him make me a new one just like the old one. Who knows, perhaps the same gold that was in my old ring will have made it's way to my jeweler friend, and my new ring will end up with my old sentimental gold. At least I can choose to believe that, and probably nobody can prove me wrong.

Recognizable Compromise - I was ROBBED!!!

2008-10-15T07:20:00.000-07:00

Interesting experience this morning at my hotel in Boston.

I woke about 4:30 this morning with an upset stomach. I opened my door to see if the USA Today was there (it was). I read for maybe a half hour and went back to sleep. At 7:00 my alarm went off and I got up. About 7:40 I put my watch and wedding ring on the bathroom shelf to get into the shower. After my shower while getting dressed I looked for my watch and ring, but couldn't find them. Even though I was "sure" I put them on the bathroom shelf, I looked on the dresser, the desk, the bed, and all around wondering where I could have put them. I found a disposable coffee mug on the floor between the bed and the wall and thought how careless the cleaning staff must have been the day before to have left behind a coffee mug. I picked it up to throw it away, and it was nearly full of still warm coffee. I don't drink coffee.

I looked in the closet - nobody there. I went to the door (a few minutes before 8:00) and noticed the chain lock was not locked. I opened the door to see if anyone was still in the hallway - nope.

The hotel detective arrived perhaps 10 minutes after my call. He had a printout of all my door openings and closings. We saw my opening of the door at 4:30, but no closing of the door until ~7:57. I had noticed yesterday that the door sometimes sticks and I have to pull or push it to get it completely closed. In my early morning stupor, I was evidently not very thorough about closing the door.

The detective is now looking at surveillance tapes and records of other doors near mine that were opened near 7:57. Perhaps a crime of opportunity - an unlocked door with an audible shower on. Sadly there is no surveillance camera that can see my door; the only one is by the guest elevator. I don't think it can see the stairway exit from there either. Hopefully the thief passed within view of the elevator.

The desk is at the wall furthest from the door. I think I must have turned off the shower (scaring the thief away) before s/he made it that far into the room. My wallet was on the desk. My computer was on the desk, unlocked (hey - I was still in the room), and with my SecureBadge in the card reader. That's quite eerie, because my day job colleagues and I just recently had an email debate on whether a TPM chip in a notebook coupled with the TPM chip's PIN constitutes two-factor authentication. In comparing TPM to smart card, we considered this exact scenario and arrived at the conclusion that stealing a PC with a TPM chip and PIN is the same as if stealing a PC together with the user's smart card. If you use a smart card for Windows logon (like I do), do you leave your smart card in the hotel room when you go out to dinner? Or do you travel with your smart card in the same bag as your PC?

This experience highlights to me the importance of one consideration for assessing the strength of various authenticators; i.e., recognizable compromise. If the thief had not left their coffee mug, I'd still be scratching my head wondering where I put my watch and ring.

Let's do it all again!

2008-10-13T18:29:00.000-07:00

Last week Project Concordia decided to undertake definition of a Concordia Identity Reference Model. Because of the work on the Identity Happens blog, I was asked to lead the Concordia effort. I'm pleased that a more formal forum is now home to this effort. Please continue to participate at the Concordia wiki.

A New Concept for the Model

2008-10-07T07:46:00.000-07:00

These last couple weeks we've used the model to help cogitate testing IDs at my day job. We discussed two main approaches:

The Subject is a tester, and the testing ID is one of the tester's Digital Personas.
The Subject is a conceptual entity. The tester has a new kind of relationship to the Digital Persona as an Invoker. Generally the Subject and Invoker are the same Entity; however, with Testing IDs the Invoker is not the same Entity as the conceptual Subject.

After much discussion we favored the second approach (note that this is our preference - some other organization may prefer something different).

Although we haven't discussed other use cases yet, we anticipate the concept of Invoker may also be pertinent to discussions about group accounts, root accounts, help center support scenarios, and perhaps others. We think this warrants adding the concept of Invoker to the general model. Here's what that might look like:

The rest of the people at my day job haven't seen this yet, so I'm not sure if they'll like it. Do you like it?

What's Next for the User Identity Reference Model?

2008-09-25T22:47:00.000-07:00

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.

Answering Matt's Questions

2008-09-16T14:43:00.000-07:00

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

Comments Finally Come In

2008-09-13T00:10:00.000-07:00

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:

Inherent Attributes of the Entity like age or address. We consider these part of the Digital Persona.
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.
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.
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.

DIDW

2008-09-11T17:43:00.001-07:00

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 http://wiki.idcommons.net/Index.php/Enterprise_Identity_Architects_Charter. One thought is that we could organize a mini-conference that would occur at the next IIW.

Model Nearing Completion?

2008-09-11T17:09:00.000-07:00

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.

Does "Account" belong in the Identity Model?

2008-09-08T22:51:00.000-07:00

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?

2008-09-08T21:46:00.000-07:00

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.

Identity Model Update

2008-09-01T23:33:00.000-07:00

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

User-centric vs. Enterprise-centric Identity

2008-08-25T09:10:00.000-07:00

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

2008-08-21T22:00:00.000-07:00

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

2008-08-19T16:09:00.000-07:00

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

2008-08-15T08:19:00.000-07:00

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.

2008-08-12T20:19:00.000-07:00

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

2008-08-07T23:55:00.000-07:00

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.