Active Identity Clients (AICs) for OpenID

November 10, 2009 § Leave a comment

“Enough is enough! I have had it with these #@%!*$ AICs and their #@%!*$ panes” — Samuel H.S. “Hammer Stack” Jackson (with apologies to Neville Flynn)

Introduction

The OpenID community is still wrestling with how to deliver a first-time login experience that is acceptable to mainstream users. Research indicates we need something less open-ended than typing into a blank URL field, but neither is it desirable to push users to choose from a few (or worse, many) pre-selected identity provider logos.

One approach for solving this problem is called (for 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 storing some amount of identity information on the user’s home computer. The AIC uses that identity to access a persistent record of the user’s interaction with multiple sites and identity providers (IdPs) to negotiate and streamline future such interactions. This (in theory) allows the user, rather than the RP, to prioritize which providers to use.

A number of such AICs were demonstrated at last week’s Internet Identity Workshop. Rather than attempting to standardize on a single AIC, a group of us discussed developing a common infrastructure that might enable a broad spectrum of AICs to innovate and compete. Specifically, we attempted to identity conventions, best practices, and extensions to existing standards that would support both “native” and “in-browser” AICs.

This article is my idiosyncratic attempt to synthesize what we discussed into a coherent vision for Active Identity Clients. It may not fully reflect the opinions of any given participant, and certainly does not represent the views of our respective employers. Rather, it is a subjective snapshot of a still-evolving problem space, and is intended to provide a concrete starting point for further discussion, critique, and clarification. « Read the rest of this entry »

Chamberlain: A User-Serving Model for Identity Management

November 2, 2009 § 1 Comment

[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.
« Read the rest of this entry »

OpenID: The RESTful approach to Single Sign-On

December 7, 2006 § Leave a comment

Been spending a lot of time on
regular
work
, but a friend recently
suggested I check out
OpenID
– the de facto distributed authentication standard for Web 2.0. I think of it
as “Decentralized Kerberos for the Internet”, in that provides the ability to do
Single Sign-On without the need for everyone to agree on a single directory
server or implement a bunch of hairy
protocols.

If I understand
it correctly, all you need is:

? an account with an OpenID
Provider (usually, but not necessarily, a username and password)
? a publicly-reachable URL
with an autodiscovery link to one or more Providers (like the links to RSS/Atom
feeds)

If you’re
ambitious/paranoid, you can even be your own provider. The reason is that the
“principal” (globally unique identifier) is really the URL (or a weird mutant
threof, like an
XRI).
All the Provider does is validate that you (as defined by your login information
with them) have access to that URL. That’s it — pure authentication, no
authorization whatsoever. All it is doing is ensuring that nobody else can claim
that URL.

To use it, you
just tell a Consuming website, “Hey, this is my URL: I’d like to use it as my
OpenID identifier on your website.” Then, they deference that URL, find its
Provider, and (if necessary) jump you over to the Provider’s website to
authenticate (and, optionally — if you allow — get your basic
name/email/contact data). Once that’s done, they can let you setup a local
‘nickname’ (not globally unique) to avoid the need for the complete URL.
Importantly, though, you never have to give a password (or any data you’d like
to keep private) to any Consuming site, and
they
never (really) need to trust the Provider; they just trust DNS and HTTP
(hopefully HTTPS) to ensure that you really have the right to claim that
link.

Now, in practice
there will probably be concerns about spoofing, so Consuming sites will have
whitelists, and which is why you may need multiple Providers to ensure they have
one that works everywhere they need it. But — crucially — all of that is an
out-of-band business opportunity. The protocol itself is (so I’m told) drop-dead
simple, so that (if you’re starting from scratch) you can get up and running in
a couple hours, especially if you leverage the pre-built libraries for PHP,
Ruby, Python, etc.

Most
importantly, it sounds like they really believe the “collaborative intelligence”
part of the Web 2.0 hype. They’re working with Dick of
Sxip,
Technorati,
and even some
SAML
refugees. If they can keep everyone happy without falling prey to bloatware,
they may really have
something.

And oh yeah:
their protocol appears to be thoroughly
RESTful,
so it plays nicely with the web.
Woot!

References
below.

« Read the rest of this entry »

Where Am I?

You are currently browsing the Identity category at iHack, therefore iBlog.

Follow

Get every new post delivered to your Inbox.

Join 1,503 other followers