We had a lively webinar last week on “The Future of Authentication and Authorization”. If you missed, you can watch the replay. Essentially, what I was talking about was context aware Risk Based Access Control (RiskBAC).
The day after the webinar, I got involved in a very lively Twitter chat with a handful of the Identirati/Identorati (some spell it one way, some the other, but it’s the collective term for those in the Identity business in one way or another) about attributes, Attribute Providers (APs), Identity Providers (IdPs) and Relying Parties (RPs).
So how are these related?
Context information, which I noted could also be referred to as “metadata” (a term much in the news lately, see “Metadata: Separating fact from fiction” in the Toronto Star) is a part of the collection of attributes surrounding an identity (or “digital identity” as some would have it). As the Star’s article notes, “The truth is that collecting metadata can actually be more revealing than accessing the content of our communications.” This was neatly summed up by Ping Identity CEO Andre Durand when he said “the sum of the correlation between attributes is greater than the sum of the raw attributes themselves. “ But he said that at Digital ID World 10 years ago!
Durand later addressed this issue again when he wrote: “I read a great Editor’s note in CIO Insight this month on the effective end of privacy as corporations build massive customer databases in an attempt to better understand how, who, when and what to sell to people. In federation terms, I call this ‘attribute-hording’, the concept that companies aggregate our attributes and then leverage the aggregation of these attributes to build ever more complex algorithms for predicting our behavior.” And he wrote that in 2004.
Yes, we should have been worries about “big data” back in 2004. With the advent of the US Patriot Act (which actually was passed in 2001, then renewed in 2011) a few forward thinkers (he says, patting himself on the back) noted at that time that the very things revealed by Edward Snowden were not only possible, but likely.
Still, the revelations and the subsequent discussions about metadata make it possible to talk about context and attributes without having to offer a lengthy explanation of them.
Identity Providers (IdPs) should be familiar to most of you. Web sites such as Google, Facebook, Yahoo!, PayPal, Amazon, etc. offer authentication services (usually through OpenID Connect and the OAuth protocol). When you visit many websites, you are prompted to “login” with your Google/Facebook/PayPal/etc. ID. Generally, these sites hold some attribute/value information, but it’s also somewhat limited. (Neither Google nor Facebook know your street address or social security number, for example). Nevertheless, it’s quite possible for them to form partnerships with other web-based enterprises who do hold some attribute/value information about you. Google offers a good explanation of this in an article called an “Overview of Attribute Providers,” with the following example:
“The popular TV channel HBO operates a website today called hbogo.com that can be used to watch HBO movies. However users have to first login and provide a trustworthy assertion that HBO can use to confirm the person is paying for an HBO subscription through a cable operator. Imagine that a user who visited HBO simply saw a list of popular identity providers, and chose theirs, such as Google. Google would then ask the user for their consent to share some of their information with hbogo.com. In the future that information might include their email address and their street address. If the user gives their consent, then hbogo.com can contact the cable operators who serve the area around the user’s house, and ask if that household has a paying subscription to HBO. If so, then with two simple clicks a user will be able to watch HBO movies on their computer.Now there’s no question that Attribute Providers will be important in the future, especially in the future of context aware risk-based access control. Some people, in fact, believe that relying parties should connect directly to the APs, bypassing the Identity Providers, since “Identity” (as we noted above) is simply a set of attributes - specifically, the set of attributes that makes you, as an entity, unique within a given namespace (your town, amazon.com, registered EIC attendees, etc.). As an example, I’m not the only David Kearns within my city, nor within my town, nor within my postal code. So saying “David Kearns, Montgomery Village, Gaithersburg, 20886 Maryland USA” isn’t unique (my son has those same attributes). Include my age, my street address, my phone number, the registration on my car, etc. and it does become unique. But there are a number of different Attribute Providers involved in gathering those values. Asking every relying party to connect with every attribute provider is really asking too much.Before the user’s identity provider can help the user assert their street address to hbogo.com, the user needs to have first selected an attribute provider who can validate their street address, and link that attribute provider to their identity provider. Companies may even compete to be a user’s attribute provider. For example when a user logs into their online banking service, they may see a promotion to use that bank as the attribute provider of their street address. If they click that promotion, the banks would explain why the user might want to do this, and if the user gives their approval then the bank would redirect the user to their identity provider. The identity provider would then ask the user to consent to using this bank as the attribute provider of their street address.”
Identity Providers, though, are ideally placed to interact with users, APs and RPs. In fact, that’s the business of an IdP. So that when I wish to do business with a new relying party, one which accepts authentication from an IdP I use, the RP can request what it considers the necessary and sufficient attributes and values concerning me and the IdP can quickly and easily verify the current values while at the same time getting my consent to reveal them.
That’s a big part of the future of Access Control, and we’ll explore it in more detail in September in a new webinar called “Authorization as a Calculated Risk.” More details as they become available.