An Elvis Impersonator
An Elvis Impersonator
(click to enlarge)

A couple of my students, Devlin Daley and Bryant Cutler, are doing some work on delegation in OpenID. Kim Cameron has been posting about delegation and that led to some interesting discussions in the lab.

First we distinguished between impersonation and delegation. The former is an authentication issue, the second is an authorization issue. Kim's point, and I think fairly made, is that you don't ever want some one other than the entity to whom the identity belongs to authenticate as that identity.

Rather, you want the entity (be it a service or human) to authenticate as itself and then use authorizations that have been delegated to it. As Kim says, this is the best way to reduce exposure and liability.

Now, back to OpenID. OpenID is nothing but authentication, so any OpenID "delegation" will necessarily be an impersonation. There's no way around it. You can't delegate authority because there's no universal authority model in OpenID. If Flickr accepts OpenID, they'll build their own authority model on top of it.

This, of course, assumes that you're doing delegation at the IdP. The relying party could build it's own delegation service inside of the Web app and it would work just fine. This will be spotty and as different as there are ways of authentication at systems now. Maybe that's the way it has to be.

So, what of OpenID impersonation? Is it "bad" in the general sense that Kim talks about? Yes. But in a relativistic sense, I think it has some advantages that might be worth the dangers. Assume a few things with me: OpenID becomes wildly popular and it's used at lots of Web sites.

You want to give your administrative assistant the ability to make changes to your calendar. The calendar site you use has no delegation mechanism. In the absence of an OpenID delegation (impersonation) scheme, you've got one choice: give your assistant the password to your OpenID (and every site you've used it at) or do your own scheduling.

An OpenID delegation (impersonation) scheme can at least provide you with a method that allows (a) the rights to be restricted to a given URL, (b) the rights to be revoked at will, and (c) an audit trail to be kept at the IdP of when those rights were used.

The biggest hurdle, in my mind, is that there is an ethical problem in allowing anyone, even with good motives, to pose as you. The relying party has the right to know who's acting for who. In many cases they might not care, but in some cases, the replying party is being put at risk through impersonation.

Say for example that you're purchased an account with T-Mobile for Wi-Fi hotspots or a single user account on a Web site. With impersonation, you can spread the use of that license to multiple parties without the replying party ever being the wiser. Sure, people do that with accounts right now, but building it into a system and making it easier to do, with less risk to the user, is problematic.

Should the research be done? Should a paper be published with the ideas? Yes. That's just information and is likely to be useful to others in solving similar problems--perhaps in a way that allows true delegation. But actually building them into an IdP is something that should be carefully thought through. If nothing else, being an IdP that allows delegation might hurt your IdP reputation.

Please leave comments using the sidebar.

Last modified: Thu Oct 10 12:47:19 2019.