{"id":701,"date":"2007-03-04T14:14:57","date_gmt":"2007-03-04T22:14:57","guid":{"rendered":"\/?p=701"},"modified":"2007-03-04T14:20:27","modified_gmt":"2007-03-04T22:20:27","slug":"wrong-headed-impersonation","status":"publish","type":"post","link":"https:\/\/www.identityblog.com\/?p=701","title":{"rendered":"Wrong-headed impersonation"},"content":{"rendered":"

James Kobielus's blog also includes a report<\/a> on his interview with Eve Mahler<\/a>.  I think there are two issues raised that deserve discussion.  The first concerns what Eve calls the “human absent” scenario:<\/p>\n

“She focused on the centricity of the user in the data flow during a login attempt, distinguishing between the “human present” interaction mode (i.e., the actual human user\/subject is online during the transaction, responding to prompts, selecting i-cards, deciding whether or not to disclose this or that personal attribute to this or that relying party), vs. the “human absent” interaction (i.e., the human user\/subject is not actually online during the transaction on which they are a principal, but, instead, an identity software agent\/intermediary or delegated other human user is selecting i-cards, disclosing attributes etc. on their behalf).<\/p>\n

“She pointed out that most of the current crop of user-centric identity schemes (i.e, MSFT CardSpace, OpenID, etc.) focus primarily on the “human present” mode, which, as Eve stated memorably, means that the “user's policy is in their brain.” By contrast, she pointed out, Liberty's ID-WSF was developed to support both the “human present” and “human absent” modes.<\/p><\/blockquote>\n

The essence here is her notion that “an identity software agent\/intermediary or delegated other human user is selecting i-cards, disclosing attributes etc. on [the user's] behalf”.<\/p>\n

On behalf of…<\/strong><\/p>\n

I'm going to make a categorical statement.  No one and no service should ever act in a peron's identity or employ their credentials when they're not present.<\/em>  Ever.<\/p>\n

It's not that there aren't use cases for which this might seem to be desireable.  For example, let's look at the problem of linkback spam, in which fake sites fill bloggers’ comment queues with garbage.  Suppose, one day, we come up with authenticated linkbacks<\/em>.  Wouldn't you want the linkback service to be able to log in with your identity?<\/p>\n

Another example – given to me by someone who thought it was really definitive – was that of the OnStar notification system.  Suppose you're driving, are involved in an accident, and lose consciousness.  You want your OnStar system to call on your behalf so help will be dispatched.  Clearly you can't participate.  Similarly, hospital scenarios provide all kind of grist for the “human absent” mill.  But should OnStar or a hospital system actually be acting “as you”?<\/p>\n

Last-century systems supported exactly this kind of behavior.  We called it “impersonation”.  And anyone who has done practical security work will tell you how many problems this caused, and how wrong-headed it is.  If you give some service the ability to simply appear to be you, you are open to all kinds of attacks – and we've seen them all around us.<\/p>\n

Put another way, I don't want OnStar to be be able to act on my behalf with respect to very many things.  I don't want it to be able to remove money from my bank account.  I don't want it buying gifts, or controlling my insurance, or doing anything else other than calling for help.<\/p>\n

So what I really want is for OnStar to identify itself as Onstar, and for Kim to identify himself as Kim.  Then Kim can give OnStar a Delegation Coupon<\/strong> allowing it to call for help on my behalf.  The coupon should be very restrictive.  And if the service does something improper, that impropriety will clearly be associated with the service's own identity, not with Kim.<\/p>\n

There is no user-absent scenario<\/strong> <\/p>\n

In otherwords, there is no user-absent scenario.  There is a user is present and delegates authority<\/strong> scenario.  After all, how can a user delegate authority if she isn't present???<\/p>\n

CardSpace is built on this principle.  A delegated authority coupon is just a set of claims.  CardSpace facilitates the exchange of any claims you want – including delegation claims.  So using CardSpace, someone can build a system allowing users to delegate authority to a service which can then operate – as itself – presenting delegation tokens whenever appropriate.<\/p>\n

This is the right way to do things from a security point of view.  We need to move beyond the idea of omnipotent services running behind the curtain, which is what we have come up with in the past, to a truly secure model where the user consciously delegates and systems demonstrate this in an auditable fashion.<\/p>\n

Surely it is obvious this is the best way to reduce everyone's exposure and liability<\/em>.  The user has less exposure because she controls what she delegates.  The service has less exposure because it operates under specific and explicit permissioning, and insider attacks are significantly mitigated.<\/p>\n

As much as I think Liberty represented a step forward when it first stepped up to the plate, it needs to embrace the user-centric model and replace the more monolithic “on behalf of” mechanisms with a proper approach to delegation under the control of the affected parties.<\/p>\n

 <\/p>\n","protected":false},"excerpt":{"rendered":"

Moving toward secure delegation scenarios<\/p>\n","protected":false},"author":68,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":[],"categories":[6,8,3,5],"tags":[],"_links":{"self":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/701"}],"collection":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/users\/68"}],"replies":[{"embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=701"}],"version-history":[{"count":0,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=\/wp\/v2\/posts\/701\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.identityblog.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}