18 May 2012

Federated Permissions - Post Facebook

The early web was strictly a public place. Everything out there was visible to everyone. Not too long afterward, private services appeared. Between the extremes of private services, like online banking, and public services, like Twitter, is a spectrum of permissions management.
Whenever permissions are restricted to some degree a credential is needed -- usually a username/password combination. Even public services like Wikipedia use credentials so that contributors can be identified. The result is that anyone that spends more than a minimum amount of time on the internet has a bunch of credentials to keep track of. This has resulted in a call for federated identity systems that let you log into multiple services using the same credentials. 

The most well-known federated ID systems are OpenID and SAML. Despite OpenID being supported by Google, Yahoo, Flickr, MySpace, AOL and many other popular sites, it remains largely unused by individuals. The trouble is that most people have solved the problem by simply using the same two or three passwords across all of their services. To them, the convenience of this approach outweighs the security risk.

In computer security we talk about two components -- authentication and authorization. Authentication is determining who someone is. Authorization determines whether that individual should have access to particular data or services. Federated ID solves the authentication problem but the much more complicated authorization issue is left to the individual websites. Not only does federated ID not solve the authorization problem -- the current solutions can make it more complicated.

For example, in order to preserve privacy, SAML issues each service a different identifier for the same person. This is intended to prevent sites from correlating user behavior from site-to-site. But it makes it really hard to grant privileges because the person granting rights doesn't know the ID that will be randomly assigned to the individual. Meanwhile, there are other ways to correlate user behavior anyway.

Which brings us to Facebook.

Facebook is really a privacy manager. Sure it supplies features like a profile, wall, forums, messaging, photo sharing, games and so forth. But better versions of most of these features are available elsewhere on the web. What Facebook lets you do is selectively grant access to your private (or semiprivate) information that is stored in those services. And Facebook's advantage is that they have accounts for a majority of internet users in North America. That lets them remain dominant despite being pretty bad about managing privacy.

What's next? With competitors envious of their position and users wishing they could jump ship it seems unreasonable that Facebook will remain dominant. I think the next step is Federated Permissions. This would be a system that lets me share private information with select individuals or organizations -- friends, family, business associates, care providers, etc. -- regardless of their identity provider.

To help bring this about. I'll start with some definitions, two Use Cases and a set of Requirements.

Definitions:
  • Identity Provider: The service that "logs you in" and tells other services that you are who you claim to. In the use cases below, I suggest that your email provider is also your identity provider. That would be a convenient option though not the only one.
  • Content Provider: A service that trusts your identity provider and supplies certain content and services to you.
  • Public ID: An identifier assigned to an individual that others can use when granting permissions. In the use cases below, I assume that your public ID is also your email address -- also a convenient option but not the only one.
These definitions are commonly used by existing federated identity systems.

Use Case #1

Sara Smith is organizing a student exchange trip to Germany. In order to share the group's experiences with people back home she wants to share photos and an online journal. All of the students should be able to contribute material and, because the students are minors, only family and select friends should be able to access the content.

First, Sara logs into "genericmail.com" which is both her mail provider and her identity provider. She creates two new groups called "germany2012crew@genericmail.com" and  "germany2012family@genericmail.com". She loads these with the email addresses (public IDs) of the people going on the trip (crew) and family and friends remaining home.

Next, Sara creates a new blog using "semiprivateblog.org." She grants write access to "germany2012crew@genericmail.com" and read access to "germany2012family@genericmail.com". She goes to "sharemyphotos.org", creates a photo album and grants equivalent access.

Finally, she composes an email describing these services and sends it out to the two groups. Since these groups double as email groups the messages get delivered to all of the right people.

While on the trip, lots of stories, messages and photos are shared with the people back at home.

Use Case #2

Max Jones has been attending Notable Community College for two years. He's applying to Potential University where he intends to complete a BS.

First, Max accesses the application page on Potential University's website. So far, he's unknown to Potential University but he's able to log into the site using his public ID, "maxtowin@genericmail.com". Upon logging in, the Potential University site requests access to Max's personal profile. This causes "genericmail.com" to pop up a window asking Max permission to deliver the info. Max clicks "yes" and re-enters his password for verification. The application form is pre-populated with Max's name, address, birthdate, etc.

Next, the application form asks about previous education. Max enters "Notable.edu." Potential U. requests access to Max's transcripts from Notable. As with the profile, Notable pops up a form asking for Max to grant permission to share the transcript. Max grants permission and the information is shared.

Moments later Max is informed that he has met the basic acceptance criteria.

Requirements

A federated permissions system would be based on a set of standard protocols and a network of trusted services. Here are some basic requirements. OpenID and related initiatives fulfill some but not all of these.
  • Public Identifiers that are well-known so that permissions can be granted as easily and conveniently as addressing an email message.
  • Public Group Identifiers that can be used to grant permissions to groups of people with ongoing management of membership. (Notably, the membership of groups doesn't necessarily have to be public.)
  • Revocable Trust relationships between identity providers and content providers.
  • Revocable Permissions for individuals and groups to access content and services.
  • Standard Policies for relationships between identity and service providers.
  • Audit Trails to monitor compliance with policies and regulations.

Today, Facebook's IPO received a lukewarm reception. Could it be that the market is already anticipating a post-facebook option for managing privacy?

3 comments :

Alex Jackl said...

This is a great discussion of the issue facing us in federating identity.

RichardBlot said...

The IDM frameworks are primarily determined by the realm of trust:
1. Public realm - The IDPs serving such realm are open to individual and can be provisioned without authoritative intervention. fb, google, yahoo, live, skype, linkedin, twitter, sina, qq, etc. As a result, the access control normally applies to individual assets/resources and in such scheme the ACLs have to be distributed at the application level. Use case #1 can be achieved under such framework (caveat: trust among these IDPs can really help a lot but even if we don't have that trust, we can still proxy IDs from different system by using your email address as your facebook ID, thus bridging the functional services).
2. Organizational realm - The IDP or directory (normally an enterprise DS such as AD or application-centric IDM) is normally organizationally provisioned and managed. A lot of enterprise level SSO framework can be adopted to provide the education-oriented implementation. For example, in most of the parent-student portal, SIS, LMS, even SLI implementations, such framework will be able to support "organization-aware" applications.
3. Mixed realm - this is when applications, especially pro-sumer type of applications such as blended learning apps or free-mium apps need to support both institution resource permissions and individual choices. For example, to support use case #2, unless both Notable Community College and Potential University trust the same IDP such as SLI or there exists a well-known public exchange (such as credit bureaus), the resource (in this case, the transcript) need to go from institution to individual and then from individual to institution again. In the latter case, depending on the confidentiality and sensitivity of the resource, the transfer of trust might not be suffice to satisfy both legal (FERPA/HIPPA) and usability requirements.

Our current work in SIF, CEDS and AIFWG, especially in SIF 3.0 is focused on the 2nd and 3rd realms, especially for federated and loosely coupled application ecosystems. In doing so, I believe, we can heavily leverage and expand the 1st realm (public/consumer) experience and success to achieve better scalability, interoperability and most of all, economy of scale.

Unknown said...

Great to see that someone still understand how to create an awesome blog.
Good blog.
Thanks for sharing the information.
dewa poker

Post a Comment