3 Parts to Authentication

At the IETF85 meeting in Atlanta, I ran into Phillip Hallam-Baker after a meeting on HTTP Authentication (you may recall, Phillip is one of the editors of RFC2617 - Basic and Digest Access Authentication). We were talking about how the term "authentication" is very poorly defined and means different things to different people and different service components.

Phil pointed me to a WG draft he put together as input to the HTTP Working Group - "HTTP Authentication Considerations". In section 2, he points out that authentication has several parts:

• registration, 
• credential presentation, and 
• message (aka session) authentication.

The term 'authentication' tends to cause confusion due to the fact that there are actually three separate activities that it can refer to. When Alice establishes an account at a Web site, the site may verify her email address is correct. When Alice presents her username and password, the site verifies the data and if correct issues a HTTP cookie. When Alice re-visits the same Web site to make further requests, the cookie is verified each time. Each of these verifications is a form of authentication but they are totally different in character and only the last of these is a form of authentication that is directly related to HTTP.

Attempts have been made to distinguish between these as 'initial authentication' and 're-authentication' but this also creates confusion as some people consider the first contact with the user as the 'initial' authentication and others consider that to be the start of a Web session.

I have seen a lot of confusion about the purpose of access tokens in OAuth. Some feel that there should be strong authentication with every HTTP requests. But when you look at it how Phil lays it out, it's clear that the job of message authentication is simply to maintain session state across multiple HTTP requests. It has very different requirements from credential presentation.

Phil also has some interesting commentary on some of the problems with passwords like promiscuity, recovery, phishing, and lock-in issues. Many of us have for some time been on a rant about killing the password - but Phil talks plainly about what 'passwords get right'.

This is a great read.

Not just write once, run anywhere, but delpoy and deliver anywhere too!

"Not just write once, run anywhere, but delpoy and deliver anywhere too."

That statement is a quote from Nandini Ramani, Director of Java Development at Oracle (formerly Sun), recently talking about the need for JavaFX in this video. Instead of dealing with the many types of display devices, mobile phones, etc, JavaFX provides a platform for abstracting away the complexities of the myriad of displays and desktops.

I can't help but think how the same problem occurs for application developers writing applications that consume and use personal information. Just as applications have to deal with differing displays, keyboards and keys, identity applications have to deal with different methods of transfer and differing ceremonies (e.g. with user-centric protocols) with each exchange of information, and even differing modalities (as I described last year).

Developers that want applications to deploy and deliver anywhere, have to consider how to support the huge variety of data stores, network configurations, and protocols (LDAP, federated, user-centric), and as well as information governance and assurance issues.

Just as abstracting implementations into layers helps JavaFX, layered abstraction is a key cornerstone to how we are developing the ArisID API going forwards.

On Determining True Identity

I listened to a fascinating show on CBC Radio last Friday that discussed the case of Suaad Hagi Mohamud's detention in Kenya. In this case a woman from Toronto, Canada, who when asked by Canadian embassy officials in Kenya to answer some seemingly basic questions to confirm her identity, failed. So much so, that on May 28, Canada informed Kenya that she was believed to be an imposter and voided her passport, recommending to Kenyan authorities that she be prosecuted. Later on August 10, Suaad's identity was confirmed by DNA after much pressure. After Kenya dropped charges she returns home amidst many questions being asked by Ontario Premier Dalton McGuinty of Canada's Prime Minister Stephen Harper. A sad and fascinating story.

The CBC radio show (The Current) on Friday talked about how Suaad might have failed questions that were so obvious to many of us. That her cultural background played a large part in her ability to answer questions such as the birth date of her children.

We started this segment with some voices of newcomers to Canada at an English class in Toronto. The questions we asked them were similar to the ones Canadian officials put to Suaad Hagi Mohamud when they were trying to determine if she was who she said she was. And the question we're left with now is whether it's fair to assume that there is a common set of cultural reference points that all -- or even most -- Canadians share.

In the standards community, many try to talk about identity in absolute terms. Who owns it, who controls it, with little acknowledgment of the gray areas. There is an underlying assumption that somehow with cryptography, good information protocols and secure practices, everything should be straight forward. This case shows how unrealistic confidence about what likely were flawed processes and cultural misunderstandings can go very wrong. The expertise of any asserting authority is critical (in this case Canada's passport office and embassies), and can have life changing impacts -- especially for Suaad Hagi Mohamud. The same is true for business. Enterprises need to consider carefully the sources of information and how critical it is to their customers, employees, and the business itself.

Give the show a listen.

The Twitter Attack And Improving Application IDM

TechCrunch posted an article: "The Anatomy of the Twitter Attack" that details how an attacker leveraged use of search, social, and public email services to hack the Twitter corporate services.

...modern web applications have built out their own systems and policies that require a user to register and then manage their identities separately with each app. The identifier that most applications use is an email address, and it is this common factor that creates a de facto trust relationship between a user’s applications. The second factor is a password: a random string that only the user knows, is unique to each application, and in theory should take even a computer months or years to figure out if it started guessing. These two elements would work well enough for most cases, were it not for what is often the single weakest factor: human habit.

If you were looking for an example of why web applications should move towards supporting federated identity and identity management services rather than rolling their own identity management systems, well, this is the poster-child case.

Look at the front page of almost any web application and you will see hints at just how hopeless and helpless we are in managing our digital lives: “forgot my password”, “forgot my username”, “keep me logged in”, “do not keep me logged in”, “forgot my name”, “who am i?”. Features that were designed and built as a compromise since we are often unable to remember and recall a single four-digit PIN number, let alone a unique password for every application we ever sign up for. Each new service that a user signs up for creates a management overhead that collapses quickly into a common dirty habit of using simple passwords, everywhere. At that point, the security of that user’s entire online identity is only as strong as the weakest application they use - which often is to say, very weak.

The article is quite long, but is very worth while reading. It shows how one weak application can be used to weaken the security of another (directly and indirectly). In this case, password recovery at an unrelated email service was the vector that unlocked valuable information at Twitter according to TechCrunch. To be fair to the web sites mentioned in the article, this identity management (IDM) stuff is hard. Many have done a pleasing job that works well on their own for their user constituencies. But this article shows how hackers can use social attacks to leverage multiple sites together to gain an advantage.

As you may know Oracle's approach to IDM is to be application-centric, to focus in on the issues relevant to making secure applications. Products like Oracle Adaptive Access Manager, OAM, Oracle Identity Manager, (not the mention the entire suite) really go a long way to provide the tools needed for secure IDM infrastructure.

But Oracle, and the members of Liberty Alliance, and now Kantara are going much further to figure out a way to recruit more application developers to leverage identity services through a common set of secure middleware components and technologies that lowers development costs, improves privacy, and ultimately the security of applications and their users. To broaden this industry effort, Oracle and many others initiated a standardization effort called the Identity Governance Framework with Liberty Alliance. Together we also initiated development of a free and open-source API called "Project Aristotle" under openLiberty.org. This work is still in development, new participation and input are greatly welcomed!

Defining Identity Modality

During my last webcast about Project Aristotle at OpenLiberty Project, I introduced a new concept called Identity Modality. The idea occurred to me as I was trying to describe the different types of identity exchange protocols and methodologies and how they impact developers.

I noticed there are several different ways and modes in which information is exchanged. There are times when the user is present (online) or is absent (offline), there are times when the transfer occurs through a backend system (such as with a database), and times when it occurs directly via the user. Finally, there are simple transactions (atomic) and then there are multi-step or workflow like transactions.

If you take these 3 different dimensions and place them on a 3-dimensional axis and plot popular means of exchanging identity information (based on typical usage), there are some interesting observations that can be made.


What struck me is how the notion of a front-end or browser-based protocols create a 3rd dimension of information exchange. The diagram also shows why SQL based systems are so ubiquitous - because it fully encompasses user-online/offline, atomic vs. workflow based transactions. Likewise LDAP, covers a smaller area, because it was intended as a lightweight, atomic (single-operation at a time) protocol. Where SQL fully exists in 2-dimensions, LDAP exists only in the atomic space handling both user online and offline scenarios.

Considering the challenges of developers writing applications and the objectives of Project Aristotle, the chart suggests why applications dealing with multiple modes of identity communication face a huge challenge. It becomes one the reasons why most applications end up with their own identity "silos" -- it's much easier to ignore systems outside the application.

One of the objectives behind the architecture of ArisID is to be able to handle all of these modalities through a single API. A loosely-coupled architecture means Identity modality does not have to be restricted to a specific hard-coded set of choices, but rather be configuration-based leveraging policy and environmental requirements.

Why Centricity Doesn't Support Privacy

Every now and then I see people putting forward the notion that they would like to physically control all their identity information and have it held in a single place of their choosing. But does that really solve the problem of privacy? It certainly seems like it does.

The problem is that this idea ignores the nature of relationships we establish with service providers and agencies on the Internet. Bob Blakley puts it nicely here:

Identity 2.0 mistook the symptom (inaccurate identities, and the damage to privacy and ability of users to transact effectively) for the cause and took up the banner of “user centricity.” User centricity will not solve the Identity 1.0 problem; indeed, it will make the problem worse by creating antagonism between individuals and businesses. This antagonism will undermine already weak relationships and thereby make it even more difficult for businesses to get the identity information they need.

Part of the antagonism that Bob Blakley is referring to is the assumption that service providers are doing bad things, and users must have control through a centralized identity provider of their choosing. Does centralizing information in a place of our choosing improve our privacy? Some have argued yes, because eventually vendors won't need to retain information. We can give it to them every time we communicate with them and audit when they use it. That would be a cool thing if that covered the entire issue.

We may want a vendor to never hold our identity information, but what about when we expect the vendor to actually do something with the information we provide such as ship a book or offer a subscription? Often, delivery of the service itself requires the use our personal information. Even using the services of a provider may in fact generate new personal information. That is the nature of having a strong relationship. As Bob indicates, relationship is something Identity 2.0 does not take into account.

When we use services, new information about ourselves is often generated. Privacy is not just about controlling and consenting to the use of information we give to a vendor, but also about what that vendor does with what it learns about us through the use of their service. For example, if I sell a bunch of items on a fictional electronic marketplace called eStuff, I will gain a reputation with eStuff. Reputation is not something self-asserted. In this case, "reputation" is a piece of my persona that gets generated as a result of using the eStuff service. The more transactions I successfully complete and the higher my trading partners rank me, the better my "reputation". In this case, "reputation" is a result of my relationship with eStuff.

Because "reputation" has value, we could conclude that there is value in making that assertion portable. Yet clearly, this personal information is information generated by eStuff based on my relationship with eStuff and its other customers. Because of my relationship with eStuff, the eStuff service could be said to be an "authoritative" source for reputation. eStuff, having invested in its reputation service, has a business interest in how the information is used.

Of course, we would like to feel we have control over our reputation and about how others get to see our reputation information. eStuff, the generator of this information also has its own interests. It is for this reason that moving the storage of this data to a third party provider who has no relationship with eStuff becomes problematic. We should have a say in the use of our own information, but the asserting party (eStuff) should also have a say. It is part of a healthy relationship! If this personal information is to be given to another party, both the person and asserting provider should have an opportunity to agree.

In practice, eStuff asserts its rights by being the issuer of claims, while the user, asserts rights by consenting. User-centric systems enhance this process by allowing the user themselves to become the vehicle of exchange generating implied consent.

eStuff is just a hypothetical example, but there are many other places where applications generate information about us. An employer's HR system generates information about who is an employee and knows our job roles. A travel agents knows our travel preferences and travel plans. The department of motor vehicles knows about our driving record. Facebook, LinkedIn and other social networks know about our relationships and about our interests. Each of these sources can be considered "authoritative" because we have a relationship with these sources. Used with our consent, authoritative personal information can improve our relationships with other service providers.

The challenge today is not how we effect transfer of information. There are lots of protocols to transfer information. The challenge is defining the programatic policy that describes when information should be shared or for that matter updated, and what constraints or consent have users stipulated. Oracle has proposed that XACML is the best tool for the job and in particular has proposed AAPML as a profiles XACML for use in relation to identity services. As XACML is now beginning to mature, watch this space for more information on the progress of AAPML towards standards.

Canada backpedals on sharing ID database with U.S. - What is the difference between sharing and copying?

The Globe and Mail posted an interesting article entitled "Canada backpedals on sharing ID database with U.S.".

Here is a great example of the differences between sharing access to information and copying information between organizations. It seems the original plan was to let the U.S. "house a database of personal information about Canadians who hold special driver's licences aimed at better securing the border." Plans changed after criticism from both federal and provincial privacy commissioners.

Once in the control of the U.S., the data "could be disclosed to other organizations for any other purpose as authorized by law." While there are obviously good intentions by all parties, the problem is, that once out of the control of Canadian authorities, it would be difficult for them to audit how the U.S. used the data. And in the event of any problem, the multi-jurisdictional issues, would be difficult at best. Sharing entire databases requires enormous trust between governments for this to happen.

The Canadian Border Services Agency now says the data will be housed in Canada where the agency will be responsible for its security. What is the difference? Well, a couple come to mind:
1. The data remains in Canadian jurisdiction and its use subject to Canadian law.
2. The CBSA is now in a position to audit each use of the data by the U.S.

In this scenario, the CBSA is acting as an "authoritative" data source. By collecting and retaining the information, it is appropriate that the authority maintain control over the data's use as it has the responsibility for loss, breaches in security, and most importantly the quality of that data.

The sad thing, is that proposals to share CDs of databases are nothing new. I seem to recall an incident in the UK not too long ago.

Because of this issue alone, it is my personal belief that federated identity systems are going to become critical to improving personal privacy down the road. To date, the focus of federated system deployments has been on single-sign-on approaches linking different sites that each hold permanent copies of our personal information. But as federation technologies become more widely deployed, they can and should be used to share identity information, on-demand, where the transfer can be secured with user consent, and where request for information can be audited.

Identity Bus Discussion at European Identity Conference

Felix Gaehtgens leads an interesting round-table discussion on the "Identity Bus" and the need for a higher-level interface to identity with Dave Kearns, Kim Cameron, Jackson Shaw, and Dale Olds.

Felix...sorry I couldn't make it. I wish I could have been there!

Standards and Implementations

Kim Cameron posted a response today to my post yesterday about requirements for his next generation Meta-directory and how IGF aims to do just that. It seems Kim and I are in total agreement on these points and developer appeal is definitely key. I do want to clarify one paragraph from his response:

I haven’t seen CARML - perhaps it is still a private proposal? [UPDATE: I’ve been advised that CARML and the IGF Attribute Servces API are the same thing.] I think having a richer common representation for people will be the most important ingredient for success. I’m a little bit skeptical about confining developers to a single API - is this likely to fly in a world where people want to innovate? But details aside, it sounds like CARML will be a helpful input to an important industry discussion. Above all, this needs to be a wide-ranging and inclusive discussion, where we take lots of input. To get “as many applications as possible” involved we need to win the participation and support of application developers - this is not just an “infrastructure’ problem.

IGF is a collection of specifications (e.g. CARML, AAPML) that Oracle and others announced in November of 2006. With the positive response and encouragement from other vendors we quickly took the initial proposal for IGF to the Liberty Alliance on its way to making IGF an important identity information standard.

The AttributeServices API I spoke of is an Apache 2.0 License open source project under openLiberty.org that demonstrates just one possible implementation of the use of the IGF specifications. In other words, I totally agree with Kim on his skepticism about one API - the last thing we want to do is confine developers to a single API implementation. This was one reason why we went to the Apache License. We want to make it easy for other developers to take what we've done and port and adapt the implementation for their own purpose. From my perspective, the key is that all APIs should share implementation of IGF as a future standard.

To expand on Kim's point there are many communities that need to buy in: Developers, Privacy Officers, Deployment Managers, Infrastructure Managers for a start. But it goes without saying that if developers don't use it, none of this matters. Developers won't do this simply because the other parties (like infrastructure managers) want it. The key benefit I see for developers is the ability to write applications without having to worry about issues of deployment or issues surrounding protocol implementation through powerful development tooling.

Kim is correct about needing a wide-ranging inclusive discussion. We're doing that by developing the standard inside Liberty Alliance and by simultaneously developing the first reference implementation under openLiberty.org. I know there may be issues, particularly for small vendors to join the Liberty Alliance, but feel free to check out the mailing lists, and by all means, join up with OpenLiberty, which in contrast has wide open membership.

Kim Cameron On The New Generation of Metadirectory

As you may know, there has been an ongoing discussion on what does the next generation of meta-directory look like. Kim Cameron's latest post elaborates on what he thinks is needed for the next generation of "metadirectory".

• By “next generation application” I mean applications based on web service protocols. Our directories need to integrate completely into the web services fabric, and application developers must to be able to interact with them without knowing LDAP.
• Developers and users need places they can go to query for “core attributes”. They must be able to use those attributes to “locate” object metadata. Having done so, applications need to be able to understand what the known information content of the object is, and how they can reach it.
• Applications need to be able to register the information fields they can serve up.

These are actually some of the key reasons I have been advocating for a new approach to developing identity services APIs for developers. We are actually very close in our thinking. Here are my thoughts:

• There should be a new generation of APIs that de-couple developers from dependence on particular vendor implementations, protocols, and potentially even data schemas when it comes to accessing identity information. Applications should be able to define their requirements for data and simply let the infrastructure deal with how to deliver it.
• Instead of thinking of core attributes as those attributes that are used in common (e.g. such as surname is likely the same everywhere). I would like to propose we alter the definition slightly in terms of "authoritativeness". Application developers should think about what data is core to their application. What data is the application authoritative for? If an application isn't authoritative over an attribute, it probably shouldn't be storing or managing that attribute. Instead, this "non-core" attribute should be obtained from the "identity network" (or metaverse as Kim calls it). An application's "core" data should only be the data for which the application is authoritative. In that sense, I guess I may be saying the opposite of Kim. But the idea is the same, an application should have a sense of what is core and not core.
  
• Applications need to register the identity data they consume, use, and update. Additionally, applications need to register the transactions they intend to perform with that data. This enables identity services to be built around an application that can be performant to the application's requirements.
  

What I have just described was actually part of the original inspiration behind CARML(Client Attributes Requirements Markup Language) put forward by Oracle that the Liberty Alliance is working on now. It was our belief that in order to enable applications to connect to diverse identity service infrastructures, something like CARML was needed to make the identity network both possible, adaptive, and intelligent.

But, while CARML was cool in itself, the business benefit to CARML was that knowing how an application consumes and uses identity data would not only help the identity network but it would also greatly improve the ability of auditors to perform privacy impact assessments.

We've recently begun an open source project at OpenLiberty called the IGF Attribute Services API that does exactly what Kim is talking about (by the way, I'm looking for nominations for a cool project name - let me know your thoughts). The Attribute Services API is still in early development stages - we are only at milestone 0.3. But that said, now is a great time for broader input. I think we are beginning to show that a fully de-coupled API that meets the requirements above is possible and dramatically easier to use and yet at the same time, much more privacy centric in its approach.

The key to all of this is to get as many applications as possible in the future to support CARML as a standard form of declaration. CARML makes it possible for identity infrastructure product vendors and service providers to build the identity network or next generation of metadirectory as described by Kim.

Government as a Justifiable Party

For those of you who don't know, Vikram Kumar of the New Zealand State Services Commission has an excellent blog on Identity and Privacy.

Vikram's latest post, "When is government a Justifiable Party?" is a must read on the issues of government participating in a transaction.

Vikram talks about the natural and cultural resistance people have to having a government run services and in particular know more than they need to know about us. What is happening now with user-centric identity is that technology is evolving such that governments could act as providers of identity information in ways that do not allow a government to track use of that information. After-all this happens in the physical world. How often do we use a government "card" (such as a driver's license) or "statement" to prove something.

We should expect individual government agencies to offer only very specific assertions or statements about their citizens. These assertions would be related to what that a particular agency is accepted or legislated to be authoritative on. This contrasts greatly with the idea of a single government identity provider that knows too many things about us and holds the potential for inappropriate use (at least in the public's eye). Individual government agencies should only be able to make specific authoritative statements or assertions about their citizens or service consumers. Then it is up to us, as citizens and consumers of services to decide how and when information is transferred between agencies and between agencies and private enterprises.

Aside: one of the problem's I have always had with driver's licenses is they carry entirely too much information on them and are used way too often. An electronic, user-centric, identity network would be able restrict the information released on a need-to-know basis.

To be clear, government as a "justifiable party" is not about governments collecting more information! Government as a justifiable party is about governments securely sharing the information they are authoritative for under the control of the individual citizens about whom the information is about.

The Identity Network

It seems that as time passes, there are going to be more and more web services that can provide information about ourselves such as who we are, and what our reputation is. We've moved from relatively simple enterprise identity systems where data was held in a corporate directory towards multiple networks of identity information networks where we provide information about ourselves with the different business service providers we make contact with. In turn, those businesses may start communicating about us on our behalf or for other business reasons. Lot's of issues to be worried about.

It is interesting that the debate around enterprise identity is still going on. Firstly, the post from Jackson Shaw that started some recent discussion on meta-directory and virtual-directory all off: You won't have me to kick around anymore! Which was promptly responded to by Jackson's former Zoomit colleague and identity guru at Microsoft, Kim Cameron: Metadirectory and claims. A discussion then ensued between Dave Kearns, and Kim. My colleague, Nishant Kaushik jumped in with "Virtual Directories + Provisioning = No More MetaDirectory".

Now it seems that in addition to having simple sources of identity information that can make assertions about who we are, or about how good we are - where we are is now going to become possible. Paul Madsen blogs about IGF and Yahoo! FireEagle. This is exciting stuff indeed. But scary too!

We are headed to a far more sophisticated, social concept of identity that spans many more boundaries that the olds days of the corporate e-mail system from which LDAP evolved. But not to worry, we've seen this before with the evolution of the Internet itself evolved based on layered architecture from forerunners like OSI, DECnet, IPX, SNA and others and evolved through multi-protocol routers and eventually evolved or migrated into TCP/IP. Just like we had silos of networks, we have silos of identities spring up all over the place. Suddenly all the complexity of inter-networking simplified into the web we have today.

I believe the Identity Inter-Network (or just plain Identity Network) is going to emerge as a set of abstracting layers that securely link the different sources of identity information with the applications that need and should have access providing we as users agree to it. Kim Cameron has already made a lot of observations about how the Identity Network should function. I'm betting there will be a few more observations to be made. But the important question isn't about which silo I choose to put my data into. The big question at this point is, "What are the equivalent OSI Layers of the Identity Network?" I'm pretty sure there are the communication protocols and transport protocols (LDAP, SAML, ID-WSF, WS-Fed), but what about discovery, routing, transformation/mapping, governance/policy (IGF), and assurance (IAF)? What other layers are needed or are going to emerge?

Copy and Sync Bad for Privacy

I read an article by Rosie Lombardi in InterGovWorld that turned out not to be what I thought it was about on first reading the title "Secret identity: Solving the privacy puzzle in a federated model".

The article turned out to be a discussion not of classic web federation, but one of different approaches to using LDAP in a federated government setting. In the article, Rosie lays out the case for the copy-and-sync meta-directory approach, vs. the case for dynamic access via virtual directories. While the article was not about classic web federation using SAML or InfoCards, the article makes for a very interesting case study in federation, because the author is talking about two very different approaches using the same protocol.

Note: for those that don't know, I came to Oracle as the head of development for OctetString--a virtual directory vendor. I am obviously biased, but I hope you will see my observations are much more general than just about LDAP.

As I read the case for copy-and-sync, another article came to mind from Robin Wilton at Sun. He writes about the recent HMRC security breach in the UK where government entities were copying citizen data between departments and in the process lost one of the copies. As it turned out, their approach of copying information created huge exposure for the UK Government.

Any time entire data sets are being copied eyebrows should be raising. Instead of minimizing information usage, information was being propagated. Control was being distributed, enabling the possibility of mistakes as more systems and hands have access to valuable personal information. In fact, the people with the least control are usually the persons identified within the data -- the persons whose privacy should be protected!

On the other hand, Rosie makes a good case that when you take the minimal approach of federating information on the fly (such as with Virtual Directory), your security may be minimized to the lowest level security provider of the federation. In response, I would contend that bad data is still bad data whether it is obtained through copy-and-sync or through dynamic querying. The fault lies not with the approach but with the data itself. The protocol and approach matters little at this point, bad data is always bad data.

The positive news is that obtaining data dynamically from a provider of personal information means that data is the most current available and not dependent the frequency of the last update. Control is maintained by the information provider and each usage is auditable. Consent is also more easily verified as it is possible to check each specific use of information and whether consent is needed and obtained.

Whether the protocol used for federation was LDAP, SAML, or WS-Trust, the issues remain the same. Those building federated applications need to be able to trust their providers. They have to be able to assess the quality of their sources. There are no easy answers right now. Just as with PKI trust in the past, trusting information transferred comes down to assessing the quality of information and procedures and the quality and stability of the physical infrastructures. Liberty Alliance has launched a new initiative called the Identity Assurance Framework (IAF) where they hope to begin to solve this problem. Check it out.

Motivations for Identity Providers

I recently blogged about a couple of use-cases of organizations and why they might become attribute authorities and their general motivations. What are some more of the general motivations and for that matter de-motivators?

Yvonne Wilson of Sun writes...

I think the attribute provider concept makes a lot more sense when there is an entity that already has information about a person and which would be authoritative for a particular attribute and authorized (not necessarily by the user) to hand that attribute out, possibly in an obfuscated form. A government might be an authoritative source for whether someone is a citizen, and obliged to respond to another government to that effect. An employer might be an authoritative source for whether someone is employed and obligated to respond to a bank loan officer to that effect. A credit agency might be an authoritative source on someone's credit rating, and obligated to report that to a credit card company. The user doesn't get to intercept, alter or halt any of this, because the entities which need the information trust these authoritative sources more than they trust the user. Of course, this kind of provider would offer up only a limited set of attributes.

Some motivators for information providers:

• Is the provider authoritative? Before making assertions about individuals, the organization has to decide if it can provide some level of assurance about the information.
  
• Is the organization considered authoritative by means of legislation? Example, legislation may make a professional organization responsible for tracking and verifying the professional status of its members.
• Privacy enhancing reduction of information flow. Because a provider may know several things about an individual, they are often in a position to answer questions about individuals. Without directly revealing what they know, they can answer some questions. E.g. If you own property and pay taxes, your city can state whether you own and potentially live in that city. A department of vital statistics, responsible for birth certificates, could generate an assertion that you are over a specific age.
• Transactional co-ordination between business service providers. In order to complete a service to a user, a web merchant might exchange assertions with a credit card company and shipping company. This allows 3 service providers to co-ordinate in order to complete a transaction. The merchant sells a product. The credit company arranges for the financial exchange, and the shipper arranges for shipment. In this case, the credit card company and shipper are temporarily acting as Identity Providers, but in reality, they are motivated by the ability to offer a service.
• Auditing use. By switching from a bulk publishing method to a dynamic provider method, the provider organization can potentially keep better track of when and potentially where information was used. Note: this is not always possible or desirable, but the environmental privacy requirements will dictate it.
• Revokability. When organizations using batch methods exchange information about individuals, they have no convenient way to revoke or update the list on a timely basis. In a dynamic provider model, the assertions can be relatively short lived - from seconds to months.
  

Some of the de-motivators:

• Self-asserted, or asserted by a third-party information. If the providing organization is non-authoritative, then asserting these values to another party brings increased liability for accuracy, privacy, and potentially even copyright violation (e.g. credit scores from a credit bureau).
• SLA obligations. In the past, authorities may have been authoritative or responsible for assertions about individuals. However, requests were done through slower or legacy processes. Example, professional organizations issuing diploma's or certificates now moving to acting in real-time may change infrastructure requirements and the legal rules and responsibilities.
• Aggregation and compliance risk. The more information a providing organization amasses, the more risk they run for inappropriate exposure of information and inaccuracy.

I should point out that these observations are all from the perspective of the information provider and are not the view of the users/customers. It is important to understand the perspectives of all parties or user-control (centric) systems won't matter much.

Send me your thoughts! What other types of motivators or observations can be made?

Also, in a somewhat related post, check out Paul Madsen's Lemma of Dubious Attributes.

What Motivates Identity Providers?

Marco Casassa Mont was wondering a while back about Bob Blakley's piece on the Identity Oracle in which he states that in the Identity Oracle concept, providers of information will charge other relying-party customers for its services.

Marco comments that

I guess that to be a viable business, the Identity Oracle needs to have relationships with many Relying Parties – which themselves might have relationships with other parties. How to track the source of improper leakages/data misuses? Wouldn’t the cost of “forensic analysis” be potentially very high for the Identity Oracle (which I assume it must make the first steps in investigating the incident and in finding the source of improper disclosure)?

In my case, I began wondering about the business of Identity Providers (Identity Oracles). What would be a good example of a highly motivated Identity Provider? There are actually lots of examples out there. For one, employers use outsourced travel services and even HR service, need to be able to act as Identity Providers about their employees.

Another example is professional organizations. These organizations often have legislated responsibilities to determine who is a professional in their area of expertise within a specified jurisdictional region. For example, the "College of Physicians and Surgeons" is often cited as the provincial, state, or national group that regulates who is a physician and what their specialties are. Or in the case of Engineering, the Professional Engineering Associations.

Today, these organizations don't have a way to electronically publish directories of their memberships. Instead, they often share their entire membership directory with hospitals, health insurance agencies, etc. The problem? Some of this information is likely confidential Who has access? How is it used? To whom is it disclosed? This is the way things have been for a long time, but from a privacy perspective, this doesn't make it right. Any time you hear of entire databases being copied from one organization to another, alarm bells should be ringing.

Being an Identity Provider combined with IGF policy offers these professional organizations the ability to control the disclosure of information in real time. Instead of providing the entire list of professionals in a jurisdiction, the professional provider can simply answer questions like "Is Dr. Smith licensed?" or provide assertions detailing Dr. Smith's qualifications at a certain point of time. This might occur in a user-agent based system where it the doctor her/himself that requests the assertion in order to access a patient care system. Done this way, the Identity Provider has the ability to record who asked the question and when the question was asked and potentially for what purpose. From a liability perspective knowing what was said to whom, when, and why can be critically important. This just isn't possible when the professional organization simply shares copies of spreadsheets or databases.

In an upcoming post, I'll enumerate some of the motivators and de-motivators for Identity Providers.

Separation Anxiety

GovTech.com has an interesting article on how the US and US State governments are stuggling with disconnecting credentials from the concepts of identity.

In this article, the author, Shane Peterson, gets to the key point, the too often we confuse relationships we have with government with identity. The fact is we have multiple relationships.

Harper, a member of the Department of Homeland Security's Data Privacy and Integrity Advisory Committee and author of Identity Crisis: How Identification Is Overused and Misunderstood, said he and former Utah CIO Phil Windley arrived at the same conclusion.

"He expressed it very well [in his book, Digital Identity]," Harper said. "An identity is a relationship. There isn't just one relationship you have with the government, and that defines every other relationship you have. So the idea that we'd have an identity system structured as a government-created identity system is equally inaccurate."

This mindset is what caused the driver's-license-as-credential problem in the first place, he said, and America is still locked into the idea that there's a simple way to create a single, uniform identification system.

It's a holdover from days gone by, he explained, when so many transactions used to happen face-to-face and proving your identity was crucial to carrying out those sorts of transactions.

One great example of separation of identity and privacy is the new TSA Clear Card program.

The card is a credential that tells TSA staff the cardholder passed the TSA's security-threat assessment process and is authorized to use ClearLanes to bypass some aspects of airport security. The card does not reveal the cardholder's identity to TSA staff, effectively separating the person's identity from the physical credential.

Peterson goes on to talk about issues of privacy and the fact that there "is no policy framework for the collection, use, storage, and exchange of identity information." From a programmatic standpoint, this is where the Liberty Alliance Project is hoping to fill the gap. The Identity Governance Framework aims to do just that.