Double-blind Identity

Note: Cross-posted from the Oracle Fusion Blog.

On November 13 and 14, the Government of British Columbia, Canada, launched the first in a series of public consultations on identity and digital services. For several years now, BC has been working on a new identity services project that would enable citizens to securely access government services online. For BC, there is clear motivation: reducing identity management and fraud costs in everything from drivers licenses to health insurance. BC's hope is that this can play a role in helping provide better services down the road as well as improving the overall privacy of residents.


For background to the challenges and motivations for BC, check out former BC CIO Dave Nikolejsin's talk on the importance of identity management in 2012 and the principles behind BC's identity project:

Incidentally my favourite quote from this video is: "Government will never be downstream from your Facebook account".

This first public consultation was focused as technical level-set meeting including standards community members from companies like Microsoft and Oracle and other vendors, as well as some members US Govt's NSTIC program, New Zealand Gov't, and British Columbia including its privacy commissioner, Elizabeth Denham. Most importantly, the meeting included several members of the general BC public picked at random from over 15,000 applicants. The day was spent educating and putting participants on a more equal footing on the basics of identity theory as well the challenges and objectives BC has for this program.

As part of this level-set, Collin Wallis, Identity Architect for the New Zealand Gov't, gave a great talk on how NZ and BC are similar in size and have many of the same overall cultural values and privacy concerns. He spoke about NZ's current "RealMe" deployments and their immediate focus on the "authentication". A similar presentation is available here.

The BC Gov't showed an overall architecture based on issuing new driver's licenses and Government Services Cards with near field chips (NFCs) supplied by SecureKey. The architecture depends mainly on OAuth2 authorization and SAML federation techniques that provide a "directed" identifier approach creating an infrastructure that has privacy qualities that could be said to be "double-blind".

You may recall that the term "double-blind" comes from medical research where both the tester and subject are blinded.  In the case of identity, the term implies the authenticator and relying party are blinded in a way that ensures privacy for the subject (the citizen).  The authenticator is not able to observe what personal information is shared or how the identifier is used assuring the citizen of freedom of use without monitoring. The relying party receives a directed identifier for the citizen unique to the relying party's use (see Kim Cameron's Law of Identity #4). What this stuff means is that two relying parties cannot share information directly based on a common identifier (as would happen if one used an omni-directional identifier like a SSN/SIN or Driver's License number). The same individual authenticating to two different parties appears to have separate identities. Hence the architecture could be said to be a double-blind system with strong privacy enabling qualities in its core design.

If successful, NZ and BC citizens may soon use their New Zealand RealMe or BC Government Services Id as a common authenticator to login and/or obtain services, while at the same time, avoid the privacy problems that occur when using a common identity such as offered by social networks, using personal email addresses. Their biggest challenge: BC and NZ need to avoid the fears of other national identity programs such as the US's "REAL ID" or the UK's "National ID" programs by building public confidence in its privacy-centred architecture.

For me personally, the most inspirational aspect of the consultation process was the leadership that Minister Andrew Wilkinson and his CTO, Ian Bailey, showed by adopting an "unconference" format that those of us in the IAM industry have come to know well at our regular meeting Internet Identity Workshop meetings. Following the first day's level-set session, an unconference session was led by Kaliya Hamlin (aka IdentityWoman) as well as Aron and Mike of IdentityNorth on the second day. This format was so successful that the group acknowledged highlights of the day were the members of the general public who chose not only to participate in deep theoretical discussion, but lead 3 of the most insightful sessions of the day!

To be clear, double-blind identity is not necessarily that new--we may have just put a term to it. After-all, there have been many systems with pseudononymous authentication. However, as technologists, we've been too accustomed to centralized architectures where both authentication and personal information in the form of claims come from a common provider (an Identity Provider). In these traditional enterprise architectures privacy has taken a back seat since employees don't often need to expect privacy in regards to performing their jobs. In contrast, these two governments are showing that privacy-enabled identity systems require separation of personal information from authentication services. I wonder what this means for cloud services architectures of the future and whether the current all-knowing social networks can survive the privacy problems they are running into by amassing so much information. It certainly suggests that the social network big data approach where all personal information is in one place is not the right way to go if governments really care about privacy.

Disclosure:  I am a resident of British Columbia. While my employer is a supplier to the government of British Columbia, I am not currently directly involved in this or any other projects with BC. My participation and comments are based as both resident and a member of the identity standards community. The views expressed are my own and do not necessarily reflect those of my employer.

IIW XII: Adding Identity Information to OAuth2

IIW XII is coming up October 18-20, so I thought I'd share with you a couple of discussions I'd like to open at IIW. The first one is how best to add user identity or authentication information to OAuth2.

The OAuth Identity Information Problem
As many of you know, OAuth2 enables a process whereby a client application, as authorized by a user, is issued a "valet key" (a token) for accessing protected resources controlled by the same user at some resource site/service provider.

One limitation of OAuth "valet keys" is that client applications do not receive information about the authorizing user. From the client application's perspective, the authorizing person is anonymous unless the underlying resource API (e.g. a social graph API) can reveal information about the authorizing user. To date, this has been the typical technique used with Twitter and Facebook. But what if, instead of a social graph API, the resource being accessed by a client application is a bank account, a set of medical test results, or a set of photos? Obviously not all resource service providers provide identity information. What if there was a standard way for client applications to obtain information about the authorizing user?

OpenID Connect's Proposal
Members of the OpenID Foundation have already been working on this. OpenID Connect has been touted by many as an important addition to OAuth2 because it would define a way for an artifact to be passed to the client application that the client could use to obtain more information--or, so I thought. Instead, the current "connect" specification suggests that an ID_token be given directly to the client in addition to the resource access token that shares basic profile information. Is this sharing of information going to be acceptable to all OpenID Providers? Shouldn't there be a trust mechanism between client applications and identity providers (OPs)?

Further, the "Connect" specification seems to assume that only OpenID Providers would be used by a resource provider and its OAuth authorization server. What happens if resource providers want to use multiple types of authenticating services such as local authentication via LDAP or federation through SAML? It seems there is something missing with the current Connect proposal. We need a way for OAuth to hand off identity information while not mandating a single protocol solution. We need a way for multiple federation protocols to work at the same time in an OAuth based service.

While I liked the original idea of OpenID Connect, I think the hand-off between OAuth2 and identity sources needs to be more flexible.

Proposing an OAuth Identity Draft Discussion
A new IETF OAuth Identity draft that lays the foundation for resource sites to be able to share artifacts that enable clients to obtain identity and personal information seems to be needed. It would enable an open solution whereby resource sites could freely choose from the many types of identity providers out there. A core OAuth Identity specification could leave room for differentiated service approaches (e.g. session management) between OpenID, SAML or any other protocol, while defining the key inter-op/hand-off points with OAuth2. Based on such an IETF draft, individual protocol profiles could then lay out the details of how particular protocols such as OpenID, or SAML, or other APIs/protocols should work in relation to OAuth2.

Comments? Thoughts?

If you are going to IIW XII, I'll have a quick ppt with some thoughts on the issues to get the discussion going. Let me know if you are interested in contributing.

ps. Don't forget to register for IIW.

SCIM at IIW - Looking for Simple and Effective

I attended several sessions at IIW last week discussing the new Simple Cloud Identity Management (SCIM) proposal. Already, there have been several positive and negative blog posts on SCIM. I won't try to rehash them, but here are a list of a few:

• Martin Kuppinger, Kuppinger-Cole, April 23, SCIM – will SPML shortcomings be reinvented?
• Nishant Kaushik, Oracle, April 25, SCIMming the Surface of User Provisioning
• Dave Kearns, Network World, April 29, SCIMing the provisioning landscape
• Patrick Harding, Ping Identity, April 29, Why SCIM over SPML? Why not?
• Mark Diodati, Gartner, May 6, SCIM and the Future of Standards-Based Provisioning
• Dave Kearns, Network World, May 10, Got SCIM?

SCIM Related Links:

• Information Site
• Google Code Project Site

SCIM supports a couple of key data flows which are:

• Copy and update identities from an enterprise cloud subscriber (ECS) to a cloud service provider (CSP) based on some event based triggers [ECS to CSP].
• Copy and update identities between cloud service providers [CSP to CSP].

For a list of possible event triggers, and flow details, check out the scenarios document here.

During the discussions, there was a question about having new operations designed to differentiate between delete and disable/suspend. For workflow based systems, suspend is often more preferable to delete. It also allows an account to be easily re-enabled. One issue this question exposes is that different end-points might interpret update events differently. For example, upon receiving a "delete" event from an ECS, a CSP might simply choose to suspend an account for either practical or even legal reasons. Thus one complication might be that read-after-delete confirmation techniques might not work as expected. Or even more tricky is the idea that the cloud-vendor might still want to allow logins by the user even if the cloud application is disabled -- if only because the cloud vendor wants to be able to gracefully redirect the user back to their enterprise to request re-enabling.

On another subject, should updates be bi-directional? If SaaS applications are generating value and hence data, how much identity information will need to be synchronized in the reverse, back to the enterprise clients, and bi-directionally between CSPs? The group felt that while this wasn't out of the question, but that the current priority was definitely unidirectional. This makes sense. At present, most cases seem to focus on centralized workflow initiated events such as hiring and retiring. 

As with many of the commenters above, I can't help but think we've been here many times before. Will SCIM work as well inside the enterprise as suggested by Mark Diodati? Maybe, but I do think there are some new multi-organizational twists to the old enterprise problem. Ownership and control of data is a new challenge not present in the classic enterprise scenarios. On the subject of "lightweight", Dave Kearns wrote this morning, is it really about finding lightweight solution? Patrick Harding points out, none of this matters if it isn't adopted. Good questions. Me, I just want something simple and effective. It is the latter requirement that makes this hard.

OAuth: Emergence of Network Centric Identity

For 5 or more years now, there has been a push by many in the identity management industry to rally around the idea of user-centric identity. Why not give users complete control over information being shared between web sites? From a web service provider it should make sense. Why retain data if it could be provided easily by the user? It made a lot of sense. Thus user-centric identity was born. There was a lot of interest, but user-centricity has remained esoteric and hasn't really taken off...

At the recent IIW 11 meeting, Dick Hardt led a discussion on the decline of user-centric identity. The conclusion was predictable. Lack of big players with significant financial incentives, too many negative financial incentives, and finally launching with immature technology not able to meet security, functionality or usability requirements. But I'm not so sure that fully explains the issue.

Both InfoCards and OpenID had some great new thinking. They both evolved around the idea of either a single user-agent or a single identity provider. User-control was key to both offerings putting the user at the centre. Neither approach was accepted by the market except in limited ways. I think that a big part of the problem was a design that focuses on a single point of control or distribution - a centricity. Both of these approaches ended up creating functional "silos" that limit the ability to embrace the Internet. Though with good intent, I think they fell into the same trap that applications fall into when they manage their own security and identity management. The application works, but it is a limited use silo with potential elevated risk and management costs. Further as application silos get big, the pressure to bridge the silos has increased. As evidence of this look at social networking application today and the Google/Facebook API sharing debate.

A new option has emerged that may serve to rejuvenate user-centric protocols by adding a new capability - open authorization or OAuth. OAuth enables applications and service providers to access data with the permission of users. Instead of trying to solve data transfer and user authentication at the same time, the requirements are separated. Yes, data can still be transferred as part of authentication, but now, many more use cases are handled without needing the users to be present. Instead of just applying to typical data points about users (first name, last name, etc), OAuth enables access to services that are controlled by users. Much more powerful. OAuth in combination with OpenID, SAML, or InfoCards enables new network cases like photo printing services, game boxes, cell-phone applications.

OAuth brings forward the notion that too me is a multi-agent or network-centric approach that enables controlled sharing of personal information by parties with some level of independence. For example, a user can give a game-box a one-time token that enables it to access his online game profile automatically. No longer does the user need to perform complex authentication in a device that doesn't have a keyboard. Instead, the user enables the device to act as an "agent" on his or her behalf. In fact there are many use-cases now envisioned (see the Zeltsan use cases draft).

OAuth enables applications to have independent relationships with data providers by using tokens as proof they are working on a user's behalf. With OAuth, applications access each other's services while allowing access control systems to handle authentication and authorization and more importantly, as I outlined in my last blog post, it allows the authorization system to distinguish between an OAuth client and a user. The OAuth concept is important because it enables network-centric identity.

I am glossing over a lot of issues (like the security of tokens, which I'll address in later posts), but the essential point, is that OAuth enables users to authorize applications, devices, or web services to perform actions on their behalf. This can be done with the user present (browser based), and with the user absent from ongoing exchanges of information. This is done with tokens (bearer, holder-of-key, etc). The OAuth 2.0 draft describe several scenarios in which users can enable a "client" application to obtain an access token to access user-controlled information on their behalf. Example, a service like Mint.com can aggregate financial information from investment services or banking service; a photo printing service can obtain photos from flickr for 24 hours to allow it to print a set of photos. A Twitter client on an smart phone can have a long-lived token to allow a user to easily post and read updates from services like twitter.

In short, network-centricity allows users to form a web of relationships between service clients and service providers. In this approach, emphasis on private 'silos' are minimized and authorized shared access to authoritative information is emphasized. Because applications have easy access to authorized, quality data, the need to copy and retain information is reduced as network services are embraced and adoption is more likely.

IIW OAUTH Enterprise BOF: Session Management

Continuing the summary of the OAuth Enterprise BOF, I want to call attention to a discussion on session management and OAuth. While we didn't start off talking about it, we soon came to realize a key potential benefit–session management.

The group was looking at the issue of UI complexity and features like "Share" buttons–a user clicks on a "Share" button and passes a token on to friends and family members to share content such as photos. Is this an appropriate use of OAuth? Are there complex token handling and UI issues to resolve?

The conversation took a rather interesting turn when Chuck Mortimore (Salesforce.com) commented that there are some technical SSO and session management issues to be concerned about. Bob Blakley (Gartner) responded by saying, OAuth is being used to establish CORBA-like "associations" to handle the absence of session management. The idea being that OAuth enables a different form of re-authentication for token holders than would normally happen for a typical user.

Bob asked: Are we overloading session management on to OAuth?

Because OAuth gives applications an idea of a separate identity from the user, access control systems can make different access control decisions about an authorized agent (token holder) distinct from the user that authorized agent (token holder). The implication is that a OAuth agent application could have a different session life than the end user. In contrast to OpenID and other SSO approaches, activity can take place without the presence of the user.

In my personal opinion, whether intended or not, enabling authorized agent session management independent of user session management is OAuth's most powerful feature! It allows for agent specific access policies and independent session lifetimes that will work in far more use-case scenarios then currently offered in current Web SSO protocols where the focus is on solving user-present in the browser scenarios.

But there is some caution here. Bob quite correctly pointed out that the fact that people are doing this without it being intentionally designed may be good reason to be worried. The group agreed that though implementations seem to be handling it well, there is good motivation to work further on some good guidance on refresh and re-authentication issues within OAuth.

IIW OAuth Enterprise BOF: Scenarios Discussion

As I blogged earlier, it seems like it is time explore the idea of enterprise use of OAuth. Many folks chimed in via email and blog comments that they were interested in a group discussion. So, at IIW 11, folks from Gartner, Google, HP, Paypal, PingIdentity, Salesforce.com, VMWare, Oracle, and others got together for a series of sessions on OAuth at IIW.

Please note, the opinions here are my own and represent my impression of the discussion that took place. Hopefully I have not misrepresented anyones view here, if I have, please let me know. This post is not meant to represent minutes for the discussion but rather a summary. Minutes can be obtained here.

Nishant Kaushik (Oracle) started off by talking about the case of a personal banking/financial services aggregator site and the quandary that services like it present to the financial service industry and their customers. While a great idea, these types of sites currently require customers to provide their banking user ids and passwords to access financial information. Obviously there is a lot of risk for potential customers to share this information. But, it seems the biggest risk is that there is no way to differentiate the customer from the aggregator. The aggregator accesses banking information with the same rights as the customer. This forces the customer to take an undue risk and likely compromises the aggregators ability to gather a broad set of customers. For banks being accessed by the aggregator, the sharing of uid/passwords by their customers also brings a certain amount of risk.

OAuth provides a new way to handle this scenario that would enable these types of aggregators to avoid using private user-ids and passwords, and instead obtain OAuth "authorization" tokens with the permission of their customers, to access financial service information. The advantage? Well, for one, no re-use of passwords. But for Banks, a key advantage. The ability to to differentiate usage capabilities of individual 3rd-party applications as distinct from and approved by their customers.

Patrick Harding (PingIdentity) covered another scenario that actually may be even more familiar. Patrick described how web companies (such as banks, or retailers) often offer 3rd-party services to their customers. To-date, that has been done successfully using web single-sign-on (SSO) technology. When a web retailer hands off to a 3rd-party, a SSO token is used to transfer session information. However, that need is evolving to where the 3rd-party service provider needs to have access to services from the retailer on some ongoing basis, or beyond the current session with the user. OAuth presents an opportunity for the 3rd party site to obtain access rights, with the customer permission, to access retailer information about the customer on an as-needed basis.

Patrick also pointed out that for the enterprise, the OAuth token avoids having to give broad access to 3rd parties systems. Enterprises will prefer a delegated access model as could be offered with OAuth. While eliminating the uid/password anti-pattern is key, differentiated access management of 3rd parties acting on behalf of users is an even more important benefit of OAuth.

There was a general discussion that there are many cases where OAuth tokens are a useful way to obtain user consent for sharing of information between service providers (organizations). As usual, Bob Blakley (Gartner) made the point, more important here is the idea that the holders of valuable data, will retain their ability to ascent to particular clients service providers access data on behalf of users. This makes natural sense, since the above scenarios demonstrate the need by enterprises to be able to have access policy that differentiates capabilities of users/customers from those of 3rd party service providers acting on their behalf.

There was a lot more discussion that took place. Some of it very detailed, some on topics which I plan to blog on shortly. Stay tuned!

Update on Enterprise OAuth BOF at IIW

For those interested, the following sessions have been proposed for Wednesday at IIW 11 (tomorrow):

1. Introduction / level-set (Patrick Harding)
2. Client App credentials discussion (Chuck Mortimore)
3. Chaining, Can OAuth happend for Application access to directories/databases? (Phil Hunt)
4. The case for OAuth for Enterprises who already have SAML Artifact support. Discussion (Prateek Mishra)
5. Relationship to Kerberos (Thomas Hardjono)
6. Revocation/logout - Revocation of client credentials? Session logout and access token relationships (Axel Nennker).

Apologies if I missed any topics.

I also recommend Eric Sachs paper on OAuth Practices. This paper makes a fairly good case for why OAuth is important to enterprise customers and enterprise application developers.

Please feel free to pass this info to fellow attendees who you think might be interested!

Enterprise OAUTH and ChangeNotify at IIW #11

For those considering attending the Internet Identity Workshop 11 in Mountain View, California, here a couple of session proposals that may be of interest:

• Enterprise OAuth BOF - this is looking like it may be an all day session on Wednesday as lot of topics have already been proposed (email me or comment if you want the list). If you are interested in adding topics, please let me know by commenting below.
• ChangeNotify - an introduction and update on the SAML ChangeNotify specification. This proposal has proved to be an interesting way to handle updates between federated providers particularly for cloud services. We'll discuss why it is different and what the advantages are. While ChangeNotify is currently profiled for SAML, there has been a proposal to develop a notification protocol variant that is non-SAML specific. Your participation and input is greatly appreciated! If you have a preference for a specific day on this, let me know!

See you there!