[Disclaimer: The following is a hypothesis I am exploring for the Nov 2009 Internet Identity Workshop. It may not even reflect my current thinking, and certainly doesn’t represent any sort of official position of my employer.]

Chamberlain: A User-Serving Model for Identity Management

Introduction

Most proposals for open identity management on the Internet use the wallet metaphor, where the user is expected to choose from amongst a variety of disjoint identities when accessing a given website. This either requires typing in a complex unique identifier (e.g., a URL) or selecting from one of several provider logos (aka the NASCAR Problem). Worse, this entire ecosystem typically exists in parallel with traditional username/password authentication, increasing the complexity of the choices users are expected to make.

I believe that the best way to solve these problems is to move to an entirely different metaphor. Rather than thinking of identity as something manually managed by the user (like cards in a wallet), I believe the vast majority of users want identity to be something that is managed *for* them — the way a chamberlain in a palace might keep keys to all the rooms, and control who was allowed to go where in accordance with royal policy.

From this perspective, the real challenge is understanding what kind of experience users want when using an identity system, and then building an architecture optimized for enabling that kind of experience. This “chamberlain” approach leads to very different questions and outcomes than the traditional model. Designing such a system will require making hard choices about what sort of security non-technical users truly need and want, as well as about the metadata necessary to support those choices. Moreoever, implementations would require significant client-side support, and create different winners and losers than existing systems — both of which could hinder broad adoption.

That said, the potential payoff is an architecture that would work reasonably well with the web as it is today, and scale cleanly to support more elegant mechanisms in the future. While my initial proposal below is unlikely to achieve all those goals, hopefully it will at least provoke others to come up with something even better.

I. What Do Users Want?

I believe that what users want — in fact, the only security they will willingly adopt en masse — is:

“technology that makes it trivial to wisely balance convenience and safety.”

Most users simply want to not:

• write things down on sticky notes
• remember multiple usernames and passwords
• worry about valuable data being lost

while still accessing a wide range of services and content on the Internet.

In practice, this typically means users have a small number of credentials they use over and over again; most commonly one for “general” usage and a second for “sensitive” data (e.g., financial or work). The premise of Chamberlain is that we need to solve the user experience problem for this class of usage in a way that allows us to seamlessly integrate more secure practices down the road.

II. Use Cases: Access

Let’s start by attempting to idealize the ‘steady-state’ experience where:

• the credentials for the website (or application) are already managed by Chamberlain.
• the user has already authenticated to Chamberlain itself

I hypothesize there are three scenarios of interest:

1. Transparent

The user should be logged in invisibly and taken directly to the “content”, without even seeing a login page. This should be the default mode for the vast majority of websites, where the user is primarily concerned with convenience.

2. Site validation

In this scenario, the user has to explicitly confirm that they want to send credentials to a given site. This needs to be a fairly rare occurrence in order to ensure the user takes such warnings seriously. Possible heuristics for elevating a login to this level include:

1. A site which the user hasn’t visited in a long time, and might have been accessed by accidental or no longer be reliable
2. Sites known to be targeted by scammers, and thus at risk of being spoofed (via DNS or other attacks)
3. Sites which present a user-selected anti-phishing icon precisely to enable this kind of behavior
4. Sites with suspicious markup or deviant/unexpected IP addresses

3. User validation

These are for sites where the user may want to ensure that only they are able to access this site, even if they happen to leave their computer unattended but authenticated to Chamberlain (e.g., for online banking). In such cases, it would be reasonable to ask the user to enter a short passcode or other identifier to “unlock” the credentials before accessing the site. True, that doesn’t solve the problem of the user leaving that site unlocked when they leave, but that is arguably a risk the user can self-manage — plus, such sites typically time out themselves.

It might also be possible to solve this problem by having Chamberlain itself timeout after a short idle period, but it is not clear if the relative inconvenience would be worth it to most users. More importantly, supporting some minimal form of user validation might satisfy the security concerns of sites that currently turn autocomplete off (cf. How to Turn Off Form Autocompletion – MDC).

III. Required Metadata

In order to support the previous scenarios, I believe Chamberlain needs to capture the following data and metadata for each Identity — which I’d prefer to call a “Login”, as that is more familiar to most users, even if it isn’t strictly accurate.

1. Credentials
2. Context
3. UniqueID
4. Service URLs (Access Control List)

The Credentials would typically be a username and password for legacy services, though it could be a URL for OpenID, a Principal for Kerberos, etc.

The Context is a user-defined (standardized?) category reflecting the user’s perception of how that Login is used. In particular, the Contexts would be used to specify what sort of Access rules to enforce; for example, the “Financial” context might require explicit User Validation. Contexts could also prove useful in the Discovery phase (below).

Unlike traditional browser password managers, Chamberlain assigns each Login a UniqueID, which allows that same login to be used with multiple Service URLs. This UniqueID should probably be some form of reverse-DNS name, potentially with a localized human-readable representation. (e.g., com.google.password => “Google Username/Password”).

Perhaps most importantly, all the metadata of Chamberlain (i.e., everything except the Credentials themselves) needs to (in general) be available to the authenticating application (e.g., the web browser). This is essential to allow intelligent Discovery…

IV. Use Cases: Discovery

The final piece of the puzzle is populating the Chamberlain database. The challenge is to not annoy the user, yet still provide sufficient visibility control to prevent unpleasant surprises. The proposal is for Chamberlain to build on the password auto-capture used by existing browsers, with the following enhancements:

1. Capture and track non-password authentication actions (e.g., OpenID and OAuth)
2. Generate a canonical UniqueID for each Login using robust heuristics
3. Infer when reused credentials might represent the same Login, and prompt the user to confirm
4. Prompt the user to specify an appropriate Context for each new Login

All of these would be simplified by the presence of appropriate microdata (microformats?) hints, though there would need to be redundant checks to avoid “hint-phishing”. Eventually, this would allow the user to visit a brand-new site, and still have Chamberlain automatically infer the appropriate Credentials to present — after a perfunctory Site validation check.

Conclusions

This essay describes a low-friction model of identity management that I believe would be attractive to the vast majority existing Internet users. While undoubtedly immature, the Chamberlain model raises crucial questions about metadata and hinting that I feel have not been sufficiently addresssed by the identity community. I hope it provides a useful starting point for those seeking to design seamless user experiences for conveniently yet safely surfing the Internet.

Sincerely,
Ernest N. Prabhakar, Ph.D.
November 2nd, 2009
@DrErnie #iiw9

 

References

1. One OpenID to Rule Them All…or Not? – Feature – Lifehacker
2. Clickpass » Blog Archive » One password less
3. Personal Identity Portal (PIP) – Download the Seatbelt

§ One Response to Chamberlain: A User-Serving Model for Identity Management

• Active Identity Clients (AICs) for OpenID « iHack, therefore iBlog says:

  November 10, 2009 at 5:18 pm

  […] lack of a better term) the Active Identity Client, or AIC (similar to what I previously called a Chamberlain). An AIC boostraps the identity selection process at a new website (aka Relying Party, or RP) by […]

  Reply