The deeper I dive into the various projects I’m working on the more I encounter the substantive differences between logging into a system and having the appropriate roles to access what they need. In my rough-n-ready approach to definitions as a way to discuss concepts:
Authentication: Identifying yourself using some type of credentialing system
Authorization: Having the rights to access and/or modify something.
In our daily lives, we’re familiar with the need to authenticate. Whipping out your ATM card and entering your PIN is a common example of telling the banking system who you are (or at least the identification of your account). In the expanding universe of online services, everyone’s inundated with the standard challenge/response prompting the entry of username and password.
What’s not as often visible is what happens post-authentication. Under the covers, systems generally track what you’re allowed to do once you’ve said who you are. This is where authentication enters the story. After entering your PIN, you can pull some cash from your bank account, but your access is often limited. For example, you are only authorized to access up to $N.
This is all very well and good, but oddly enough it glosses over a fundamental issue at the core of these transactions. Specifically, when the authentication credentials are assigned, it’s not always clear the issuer truly knows the identity of the credentialed party.
This is where “assurance” comes into play. I had a great dinner conversation with Peter Alterman of the GSA who was able to shine a light on the subject. Before entering a system requiring authentication (and associated authorization), you’ll need to assert your identity to a level the managers of the system find acceptable. There is, of course, a complete gamut of acceptable levels as not all systems require the same assurance of their users’ identities.
These days when we’re creating new social networking accounts every five minutes, it’s pretty clear little to no assurance is given to the site that the name you entered when registering is valid. It’s arguable whether or not that’s a problem, but it’s not very controversial that signing up for Facebook has different needs than being credentialed to access your medical records.
Then again, that’s only true insofar as you’re going to stay within that system (or largely similar ones). What happens when you start cross-linking systems in a frenzy of mash-ups and other data portability goodness? Unfortunately, the discussion with Peter really opened my eyes to the host of issues that arise when a user creates a self-credentialing account, then wants to link data from it to a system he perceives as being more secure. It was in the context of discussing a healthcare initiative I’m working on where this problem really became obvious.
Taking my personal experience here, I’ve got what I believe to be the mac-daddy of OpenID accounts. I have been using myOpenID.com (and I firmly recommend it to anyone who will listen), and was thrilled when they rolled out their two (and three) factor identification methods. Now if I want to log into an OpenID Relying Parties, I need to present not just a username / password combination, but also provide an SSL certificate and answer my cell phone, too. Now if you want to access my accounts, you need all three bits: un/pw, SSL cert, and my cell phone.
Now, here’s the ugly secret. I set up that account myself, and no one verified that I was who I said I am when I created my OpenID. Basically, you could call it “Assurance Level 0″ (i.e. no assurance of my identity whatsoever).
Who cares, you might ask rhetorically. Well, you should. While it’s fine-and-dandy for run-of-the-mill social networking systems, what happens when they start asking for your credit card number? We’re right back where we’ve been for decades. Yes, you logged into the system before entering your payment information, but when you roll back to how the account was created it’s not materially different than simply typing your credit card into a non-credentialed system.
So, basically, here’s where I am now. I’m working on a couple of projects that need to maintain a level of security throughout the process lifecycle. Apparently, I need to be much more careful how credentials are allocated, and it’s not enough to rely on self-credentialing. I’m looking into automated multi-factor identification assurance models now (akin to SSL certification methods used by VeriSign that use third-party triangulation).
If you’re curious about this assurance discussion, you might want to pop over to the Identity Assurance Framework released by the Liberty Alliance. You’ll also notice that Peter was a co-chair for some of the work that went into it. I guess I was talking to the right guy.
END NOTE:I wish I knew the origin of the saying, “to name something is to control it”. In my experience that’s nearly accurate in that once a (good) name is applied to something, it’s easier to discuss, and thus feel a sense that what’s been named is more effectively understood. That’s not necessarily true, of course, but at least agreeing on a common name is a good start. Now that I’ve got a handle on the term “assurance”, I have a sense I’ll be able to more effectively grapple with the concept.
Authentication, Authorization, and Assurance
The deeper I dive into the various projects I’m working on the more I encounter the substantive differences between logging into a system and having the appropriate roles to access what they need. In my rough-n-ready approach to definitions as a way to discuss concepts:
In our daily lives, we’re familiar with the need to authenticate. Whipping out your ATM card and entering your PIN is a common example of telling the banking system who you are (or at least the identification of your account). In the expanding universe of online services, everyone’s inundated with the standard challenge/response prompting the entry of username and password.
What’s not as often visible is what happens post-authentication. Under the covers, systems generally track what you’re allowed to do once you’ve said who you are. This is where authentication enters the story. After entering your PIN, you can pull some cash from your bank account, but your access is often limited. For example, you are only authorized to access up to $N.
This is all very well and good, but oddly enough it glosses over a fundamental issue at the core of these transactions. Specifically, when the authentication credentials are assigned, it’s not always clear the issuer truly knows the identity of the credentialed party.
This is where “assurance” comes into play. I had a great dinner conversation with Peter Alterman of the GSA who was able to shine a light on the subject. Before entering a system requiring authentication (and associated authorization), you’ll need to assert your identity to a level the managers of the system find acceptable. There is, of course, a complete gamut of acceptable levels as not all systems require the same assurance of their users’ identities.
These days when we’re creating new social networking accounts every five minutes, it’s pretty clear little to no assurance is given to the site that the name you entered when registering is valid. It’s arguable whether or not that’s a problem, but it’s not very controversial that signing up for Facebook has different needs than being credentialed to access your medical records.
Then again, that’s only true insofar as you’re going to stay within that system (or largely similar ones). What happens when you start cross-linking systems in a frenzy of mash-ups and other data portability goodness? Unfortunately, the discussion with Peter really opened my eyes to the host of issues that arise when a user creates a self-credentialing account, then wants to link data from it to a system he perceives as being more secure. It was in the context of discussing a healthcare initiative I’m working on where this problem really became obvious.
Taking my personal experience here, I’ve got what I believe to be the mac-daddy of OpenID accounts. I have been using myOpenID.com (and I firmly recommend it to anyone who will listen), and was thrilled when they rolled out their two (and three) factor identification methods. Now if I want to log into an OpenID Relying Parties, I need to present not just a username / password combination, but also provide an SSL certificate and answer my cell phone, too. Now if you want to access my accounts, you need all three bits: un/pw, SSL cert, and my cell phone.
Now, here’s the ugly secret. I set up that account myself, and no one verified that I was who I said I am when I created my OpenID. Basically, you could call it “Assurance Level 0″ (i.e. no assurance of my identity whatsoever).
Who cares, you might ask rhetorically. Well, you should. While it’s fine-and-dandy for run-of-the-mill social networking systems, what happens when they start asking for your credit card number? We’re right back where we’ve been for decades. Yes, you logged into the system before entering your payment information, but when you roll back to how the account was created it’s not materially different than simply typing your credit card into a non-credentialed system.
So, basically, here’s where I am now. I’m working on a couple of projects that need to maintain a level of security throughout the process lifecycle. Apparently, I need to be much more careful how credentials are allocated, and it’s not enough to rely on self-credentialing. I’m looking into automated multi-factor identification assurance models now (akin to SSL certification methods used by VeriSign that use third-party triangulation).
If you’re curious about this assurance discussion, you might want to pop over to the Identity Assurance Framework released by the Liberty Alliance. You’ll also notice that Peter was a co-chair for some of the work that went into it. I guess I was talking to the right guy.
END NOTE: I wish I knew the origin of the saying, “to name something is to control it”. In my experience that’s nearly accurate in that once a (good) name is applied to something, it’s easier to discuss, and thus feel a sense that what’s been named is more effectively understood. That’s not necessarily true, of course, but at least agreeing on a common name is a good start. Now that I’ve got a handle on the term “assurance”, I have a sense I’ll be able to more effectively grapple with the concept.