Category: User centric

Delegation tokens and impersonation

I've been asked to clarify a couple of points by Devlin Daley and Bryant Cutler, who are studying with Phil Windley.

Delegation tokens 

Delegation tokens, as you've described them, (according to one of Dale Old's recent posts) are not yet implemented in CardSpace.  Is that accurate? Is it soon to be added to specification or is it still a work in progress?

I like Dale's piece, but think the “not yet implemented” statement might lead to confusion. 

One of the key characteristics of CardSpace is that it has no idea what kind(s) of token it is carrying.  It's hard to get this across – the practical meaning isn't obvious.  But your question about “delegation tokens” provides  a good concrete example:  delegation coupons can be conveyed through CardSpace without any changes or extensions to it.  This doesn't mean anyone is doing so yet.  That is likely what Dale is talking about. 

I've actually been thinking of putting together some demo code to show how this would work.  If you look at my “HelloWorld Card” tutorial,  you will see that rather than requesting and sending a “HelloWorld Card”, the relying party could easily be requesting a delegation coupon.  So CardSpace is actually ready for “delegation coupons”.

One can then ask what a delegation coupon would look like in concrete terms.  What's the best format for the (possibly multiple) constituent tokens?  The blogosphere discussion about delegation shows lots of people are thinking about this, but so far we haven't built the “early implementations” that let us explore the issues and problems concretely enough to emerge with a new standard.  I would be interested in learning about research systems built in the academic community to explore this territory – perhaps you can share your research with us.

Impersonation

Devin and Bryant continue:

We've been bantering about the idea of delegation vs. impersonation. Clearly impersonating someone without them knowing is wrong and a serious problem. But, is impersonation “bad” if I give my express permission for someone to do so? (assuming there is a mechanism for revoking this permission).

In your Powell's and Amazon example, what if I don't want Powell's to know that I am supplying this information to Amazon? Obviously there are cases where we want to let others know that services are acting with our permission. Perhaps there are cases where we don't want to disclose that. Is granting the choice to me more user-centric?

You are quite right that, as per the first law of identity, the choice of what to disclose must always be in the hands of the user.  Further, if a user wants to delegate to a machine the ability to “be her”, that should be possible too.  Let's call it extreme delegation.  Our job is not to tell anyone that they should live in some particular way.  We might, however, have the responsibility of pointing out the technical dangers of this extreme, perhaps even recommending some interesting science fiction readings…

But I'll point out that it isn't necessary to do impersonation to achieve the goal you want to achieve in your example – preventing Powell's from knowing that you are supplying information to Amazon.  In fact there are two ways to use delegation to do this. 

The first is simply to create a coupon saying, “the holder of this key has the right to see my Powell's behavior”.  Then you give Amazon the coupon and the key.  In return, Amazon might give you assurances about how it will protect the coupon.  Meanwhile, it can retrieve the information it wants without revealing its identity.

Or you may wish to have an agent of your own to which you delegate the ability to assemble your behaviors, and the right to pass them on according to your dictates.  I personally think this is the most likely option since it provides optimal user control.  But even in this case, designing secure systems means limiting the capabilities delegated to that particular piece of software, rather than “making it into you” by having it operate in your identity.  There is zero need for impersonation.

Your use case of information hiding can be handled without departing from my delegation maxim:

No one and no service should ever act in a peron’s identity or employ their credentials when they’re not present.  Ever.  

Putting several threads together, the user should act through a transducer to delegate to well-identified processes.

Transducers and Delegation

Ernst Lopez Cordozo recently posted a very interesting comment about delegation issues:

“We always use delegation: if I use a piece of software on my machine to login to a site or application, it is that piece of software (e.g. the CardSpace client) that does the transaction, claiming it is authorized to do so.

“But if the software is compromised, it may misrepresent me or even somebody else. Is there a fundamental difference between software on my (owned? managed? checked?) machine and a machine under somebody else’s control?”

Ernst’s “We always use delegation” may be true, but risks losing sight of important distinctions. Despite that, it invites us to think about complex issues.

Analog-to-Digital transducers

There are modules within one's operating system whose job it is to vehicle our language and responses by sensing our behavior through a keyboard or mouse or microphone, and transforming it into a stream of bits.

The sensors constitute a transducer performing a conversion of our behavior from the physical to the digital worlds. Once converted, this behavior is communicated to service endpoints (local or distant) through what we’ve called “channels”.

There are lots of examples of similar transducers in more specialized realms – anywhere that benefit is to be had by converting physical being to electrical impulses or streams of bits. And there are more examples of this every day.

Consider the accelerator pedal in your car. Last century, it physically controlled gas flowing to your engine. Today, your car may not even use gas… If it does, there are more efficient ways of controlling fuel injection than with raw foot pressure… The “accelerator” has been transformed into a digital transducer. Directly or indirectly, it now generates a digital representation of how much you want to accelerate; this is fed into a computer as one of several inputs that actually regulate gas flow (or an electric engine).

Microphones make a more familiar example. Their role is to take sounds, which are physical vibrations, and convert them into micro currents that can then be harnessed directly – or digitized. So again, we have a transducer. This one feeds a channel representing the sound-field at the microphone.

I’m certain that Ernst would not argue that we “delegate” control of acceleration to the foot pedal in our car – the “foot-pedal-associated-components” constitute the transducer that conveys our intentions to engine control systems.

Similarly, no singer – recording through a microphone into a solid-state recording chain – would think of herself as “delegating” to the microphone… The microphone is just the transducer that converts the singer's voice from the physical realm to the electrical – hopefully introducing as little color as possible. The singer delegates to her manager or press representative – not to her microphone.

So I think we need to tease apart two classes of things that we want done when using computers. One is for our computers to serve as colorless transducers through which we can “become digital”, responding ourselves to digital events.

The other is for computers to “act in our stead” – analyze inputs, apply logic and policy (perhaps one day intuition?), and make decisions for us, or perform tasks, in the digital sphere.

Through the transducer systems, we are able to “dictate” onto post-physical media. The system which “takes dictation” performs no interpretation. It is colorless, a transcription from one medium to another. Dictation is the promulgation of “what I say”: stenography in the last century; digitization in this.

When we type at our keyboard and click with our mouse, we dictate to obedient digital scribes that convert our words and movements into the digital realm, rather than onto papyrus. These scribes differ from the executors and ambassadors and other reactive agents who are our “delegates”. There is in this sense a duality with the transducer on one side and the delegate on the other.

Protection of the channel

No one ever worried about evil parties intercepting the audio stream when Maria Callas stood before a microphone. That is partly because the recording equipment was protected through physical security; and partly because there was no economic incentive to do so.

In the early days, computers were like that too. The primitive transducer comprised a rigid and inalterable terminal – if not a punch card reader – and the resulting signal travelled along actual WIRES under the complete control of those managing the system.

Over time the computing components became progressively more dissociated. Distances grew and wires began to disappear: ensuring the physical security of a distributed system is no longer possible. As computers evolved into being a medium of exchange for business, the rewards for subverting them increased disproportionally.

In this environment, the question becomes one of how we know the “digital dictation” received from a transducer has not been altered on the way to the recipient. There is also a fundamental question about who is gave the dictation in the first place.

In the digital realm, the only way to ensure integrity across component boundaries is through cryptography. One wants the dictation to be cryptographically protected – as close to the transducer as possible. The ideal answer is: “Protect the dictation in the transducer to ensure no computer process has altered it”. This is done by giving the transducer a key. Then we can have secure digital dictation.

Compromise of software

Ernst talks about software compromise. Clearly, other things being equal, the tighter the binding between a transducer (taken in a wide sense) and its cryptographic module, the less opportunity there is for attack on the dictation channel. Given digital physics, this equates to reduction of the software surface area. It is thus best to keep processes and components compartmentalized, with clear boundaries, clear identities.

This, in itself, is a compelling reason to partition activities: the transducer being one component; processes taking this channel as an input then having separate identities.

Going forward we can expect there will be widely available hardware-based Trusted Platform Modules capable of ensuring that only a trusted loader will run. Given this, one will see loaders that will only allow trusted transducers to run. If this is combined with sufficiently advanced virtualization, we can predict machines that will achieve entirely new levels of security.

CardSpace

Given the distinctions being presented here, I see CardSpace as a transducer capable of bringing the physical human user into the digital identity system. It provides a context for the senses and translates her actions and responses into underlying protocol activities. It aims at adding no color to her actions, and at taking no decisions on its own. 

In this sense, it is not the same as a process performing delegation – and if we say it is, then we have started making “delegation” such a broad concept that it doesn’t say much at all. This lack of precision may not be the end of the world – perhaps we need new words all the way round. But in the meantime, I think separating transducers from entities that are proactive on our behalf is an indispensible precondition to achieving systems with enough isolation between components that they can be secure in the profound ways that will be required going forward.

New Visual Studio Toolkit for CardSpace

If you use visual studio and are interested in CardSpace, you'll be interested in Christian Arnold's brand new “Visual Studio 2005 Toolbox for Windows CardSpace”.  It looks like it makes the task of CardSpace enabling .NET 2.0 apps as easy as pie.  I'm out of the country now but can't wait to try it.

You can download the tools here.  Christian also runs what he calls a “little support forum“.

The ToolBox provides an easy way to use Windows CardSpace in your ASP.NET 2.0 Web-Application to register and validate your users. It´s also possible to use the controls to receive a SAML token and get the decrypted values of provided claims. The token decrypting process is build based on the community sample.

The install process looks pretty straightforward – you just add the tools to your toolbox:

 

That adds two new controls to your Visual Studio 2005 ToolBox:

Here's a taste of how you use the CreateCardSpaceUserWizard Control:

 

You need to add a little configuration:

<cc1:CreateCardSpaceUserWizard ID=”CreateCardSpaceUserWizard1″ runat=”server” BuildInRegistration=”False” OnUserRegistered=”CreateCardSpaceUserWizard1_UserRegistered1″>

<cc1:IdentityClaim ClaimUri= “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier” />

<cc1:IdentityClaim ClaimUri= “http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress” />

</cc1:CreateCardSpaceUserWizard>

Christian explains that this causes the system to request the privatepersonalidentifier and the emailadress of a new user powered with CardSpace or other Information Card identity selector.

He explains that by defining the claim

http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress

the control will store the emailaddress automatically, so you don't have not to worry about this 🙂

After registration the control will fire the UserRegistered Event. The eventargs will tell you the result of the operation and the provided claims as a NameValueCollection.
 
Christian goes on to explain how to use the system with the default ASP.NET 2.0 Membership-Provider. 

Clearly, there are a great many sites built on this Membership-provider technology and the emergence of this toolkit in the identity ecosystem is a major event.

An example of delegation coupons

Even if the true meaning of uber-geek is “incomprehensible”, my last comment on the use of delegation in VRM was a real winner in terms of terseness. I was discussing Whit's notion that he wanted to give Amazon access to his behavior at Netflix, Powell's and lastfm – the goal being to improve Amazon's relationship with him by revealing more about himself as a complete person. So I'll try to unfold my thought process.

If you ponder the possible architectures that could be used, it becomes clear, as usual, that the identity aspects are the hardest. Let's build a little picture of the parties involved. Let's say the user (I know, I should be calling Whit a “customer”), shares his behavior with Amazon and Powell's. Now let's call some subset of his behavior at Powell's “BP“. Whit would like an outcome that would be modelled in the following diagram, assuming for the moment that U->A:BP just represents Amazon asking Powell's for the customer's relevant information.

But how does Powell's know that Whit really wants it to release information to amazon.com but not snooper.com? How does it know that the amazon.com which calls for information is really the same Amazon that Whit was dealing with? Why should Powell's ever take the privacy risk of releasing information to the wrong party? What would its liability be if it were to do so? Can it protect itself from this liability?

When I mentioned delegation, I meant that while the user is “behaving” at Amazon, it gives Amazon a “coupon” that says “User delegates to Amazon the right to see his Behavior at Powell's”. I represent this as U->A:BP, where:

  • U is the user;
  • A is Amazon;
  • P is Powell's; and
  • B is behavior

Amazon can now present this coupon to Powell's, along with cryptographic proof that it is the “A” in the coupon. By retaining this coupon and auditing any release, Powell's can indemnify itself against any accusation that it released information to the wrong party – and better still, actually defend the user's privacy.

‘Breaking up is hard to do.’

I have left two of the most important questions for another time. First, is it really necessary (or advisable) for Powell's to know that the Whit is sharing information with Amazon, rather than “some legitimate party”? Second, how does Whit revoke the permission he has granted to Amazon if he decides the time has come for them to “break up”?

But without even opening those cans of worms, it should be evident that, for reasons of privacy, auditablity and of liability reduction, everyone's interests are served by making sure no service ever acts as an end user. In this example, Amazon continues to act as Amazon, and even if its access is one day anonomized, would would always be identified as “the user's delegate”. The approach constrasts starkly with current approaches – as spooky as they are cooky – in which users release their credentials on “good faith” and eventually, if enough secrets are shared, anyone can be anyone.

Note:   The notation above is my own – please propose a better one if it is just as simple…

SeaMonkeyRodeo on Amazon and VRM

Good description of Vendor Relationship Management (VRM) by Whit B. McNamara  at seamonkeyrodeo (“karaoke mind control…”).  Seems like another place that user control and delegation is the right answer:

Kim Cameron, identity urber-geek, posted an enthusiastic endorsement of Amazon’s recommendation emails over the weekend.

I know what he means — I blogged about the very same positive experience with Amazon’s recommendations a couple of years ago, shortly after noting the inverse experience with eBay’s sad little attempts to send personalized email to me.

While I, like Kim, am still pretty happy with Amazon and continue to view their recommendations as useful (and not spam), my thinking about VRM has taken some of the luster off of this relationship with Amazon.

The problem isn’t anything that Amazon is doing — what they offer is already far better that what most of the market is doing; the problem is that my expectations have grown while Amazon’s capabilities appear to be fundamentally the same as they were two years ago. You see, I’d like to offer Amazon the chance to have an actual relationship with me, rather than a relationship with the incomplete model of me that they’ve built from the transactions that we have in common (I call that construction “Whit: Amazon Virtual Edition”).

Just taking the easy examples, real-world Whit leaves trails of data across the Internet that I’d be happy to share with Amazon, just to see what they could do with them. (With the explicit understanding that both the data and the decision whether or not to continue sharing it is mine, of course.)

I get at least five or six DVDs per month from Netflix, and tend to rate them after viewing. Amazon knows only that I don’t buy DVDs often at all. No recommendations for me, no opportunity to prey on my secret desire to own every episode of The Tick for Amazon.

While I buy a reasonable number of books through Amazon, the overwhelming majority of my book purchases are from Powells. Amazon knows nothing about them. No recommendations for me, and no opportunity to take business away from Powells for Amazon.

I buy some music from Amazon, but not a huge amount. last.fm doesn’t know what I’ve bought, but it knows all about what I’ve been listening to. Amazon knows nothing about it. No recommendations for me, and no chance to take business away from eMusic, Apple, CD Baby, and a host of others for Amazon.

Now I know that I could work around this to some extent by using Amazon’s lists, wishlists, and what-have-you, but why should I? I’ve already created all of this information in a variety of places, why can’t I just use that information now, to make my own life easier? And if that means that Amazon gets the chance to make more money by knowing me better, where’s the harm? Isn’t that scenario better for everyone involved?

I know that this isn’t just Amazon’s problem: even if they make it possible for me to put data in, everyone else that I’ve mentioned needs to make it possible for me to get data out. But that’s the way I want these relationships to work. All this metadata I’m creating is mine. I should be able to actively and selectively share it with others. I should be able to offer vendors data that they can’t collect themselves, so that they can build a relationship with me, rather than a relationship with their transaction database.

And that right there is the “R” for one big piece of VRM.

I could give Amazon a “packet” of delegation coupons they could present to netflix et al in order to serve me better. 

The umpire delegates back

Pete Rowley of RedHat has to win the Witty Title Award for “The umpire delegates back“:  

Recently Kim Cameron has been defending CardSpace against various assertions that it won’t work offline. As I pointed out some while back, that is pure nonesense. I’ll let you read Kims blog for the details of how such a system might work with CardSpace, but I’ll just say it has to do with delegation. And that’s just a big word for access control, in this case user centric decentralized access control.

There really is no big secret to how this stuff is possible – at some point in time an offline user will be online, and during that time instead of ceding their credentials to the service in the sky (or worse, it happens without choice), they spend the time granting access specific to the service that needs access. That’ll be a statement along the lines of “Pete’s blog is allowed to view this flickr photoset.”, not “here’s my password dude, do as you will”, or indeed “hey, IdP, see that service? That’s me that is.” I have to agree with Kim on the notion of impersonation – at no time should anybody give the required access level for impersonation of themselves, on or offline.

There be dragons.

Pete has a fascinating blog and it's really worth following his People In The Policy series.  This is good stuff.

Services should use their own credentials, not mine

Dave Kearns, who is usually not without wisdom, takes on my “bold and forceful” assertion: 

Aided by Jim Kobielus, Kim Cameron and Eve Maler are having a snit. Well, Eve's taking potshots at CardSpace and Kim's defending his baby….

As part of the exchange, Cameron states categorically: “No one and no service should ever act in a peron’s [sic] identity or employ their credentials when they’re not present. Ever.” Bold and forceful, certainly. But also as wrong as wrong can be.

We all (even Kim) often ask services to do things on our behalf – and don't sit around watching to be sure they do it! The most obvious example is my email inbox – it patiently logs in (as me) to multiple servers periodically 24 hours a day, seven days a week, 52 weeks a year. From time to time I visit the inbox to see what's there, but no way can I be said to be “present” at all times it's acting for me.

Dave is missing the point – maybe I wasn't clear enough. 

I'm not saying you have to “stand around and watch” while your mail client picks up your mail.  I'm saying your mail client should identify itself as a particular instance of a mail client, and present an authorization from you allowing it to pick up your mail. 

They're all ME 

If you share identity (even, in some cases, secrets and credentials) the way Dave is proposing,  we don't know what process is accessing what resource because all the the services I run are ME. 

That's really the computing model we have had until now.  Where has it led?  Well, for example, my email client is ME, and a trojan on my desktop is ME,  and the resources they access can't tell the difference, because they're all ME.

So any trojan that gets into my environment can get my email addresses and send worms to my friends, or pick up my mail and feed it to spam machines.  My mail server and other resources don't know the diffference.

Things don't have to be this way

We can instead build systems where my mail client will identify itself as my email client (e.g. be iteself), and present an authorization token from me saying it can pick up my mail.  

On such a system, my trojan will have to identify itself as “trojan”, and will thus have no authorization coupon to present at all!  It is harder to build systems that behave this way, but given what we now understand, it is doable.  Wouldn't we want actual auditability and proper factoring?

That's why I say:

“No one and no service should ever act in a peron’s identity or employ their credentials when they’re not present. Ever.”

The approach Dave describes was fine when we all lived in the Garden of Eden.  But we've been sent out of it into the grown-up world of virtual reality, where there are evil processes as well as good ones, and we need to be able to distinguish one from the other.  This metaphor – and the whole discussion – doesn't come from a “snit with Eve”…  It results from the vulnerabilities of the current generation of software and distributed architecture – regardless of platform – and a desire to make sure we don't repeat the same mistakes going forward.  

Blog posting delegation and third-party auth

LesOrchard at 0xDECAFBAD (…t’s all spinning wheels and self-doubt until the first pot of coffee) expands on the idea of how delegation can be used to improve our blogging experience:

Here’s something I’ve been meaning to post about, brought back to mind from Kim Cameron’s post on “Wrong-headed impersonation”:

I wish that blog posting interfaces (ie. MetaWeblog API and Atom Publishing Protocol) offered a way to delegate blog posting to a 3rd party app (desktop or web) in such a way as to avoid providing one’s login details (i.e. user name and password). For instance, consider both Flickr’s and Upcoming’s 3rd party token-based authentication / authorization schemes.In particular, I’m looking at things like del.icio.us’ own Daily Blog Post and others. These can be used to auto-post content to one’s blog generated elsewhere – but at the price of sharing login details. Granted, you can mostly trust these 3rd parties not to do anything nasty with your credentials, but it would be nice not to have to.

I figure that something RESTful like extending HTTP authentication (ala Atom Authentication) with a token scheme could be interesting, and possibly fit nicely into APP itself. It could probably be retrofit into the MetaWeblog API by specifying a per-app user name and password. I can imagine a WordPress admin plugin that issues approved authentication tokens to restrict the categories and other activities allowed by 3rd party apps.

Just something I’m thinking about, as more services may or may not grow into delegated blog posting.

Drilling further into delegation

Still further to my recent piece on delegation, Eric Norman writes to give another example of a user-absent scenario.  Again, to me, it is an example of a user delegating rights to a service which should run under its own identity, presenting the delegation token given to it by the user.

For an example of user-absent scenarios, look at grid computing. In this scenario, a researcher is going to launch a long-running batch job into the computing grid. Such a job may run for days and the researcher needs to go home and feed the dog and may be absent if a particular stage in the job requires authentication. The grid folks have invented a “proxy certificate” for this case. While it’s still the case that a user is present when their “main” identity is used, the purpose of the proxy cert is to delegate authentication to an agent in their absence such that if that agent is compromised, all the researcher loses is that temporary credential.

Perhaps this doesn’t count as a “user absent scenario”. Nevertheless, I think it’s certainly relevant to discussions about delegation.

I agree this is relevant.  The proxy cert is a kind of practical hybrid that gets to some of what we are trying to do without attempting to fix the underlying infrastructure.  It's way better than what we've had before, and a step on the right road.  But I think those behind proxy certs will likely agree with me about the theoretical issues under discussion here.

As an aside, it's interesting that their scheme is based on public key, and that's what makes delegation across multiple parties “tractable” even in a less than perfect form.  I say public key without at all limiting my point to X.509.

With respect to the problem of having identities on different devices, Eric adds:

Um, I think one of the scenarios Eve might have had in mind is the use of smart cards. A lot of people think that the “proper” way smart cards should operate is that secrets (e.g. private keys) are generated an the card and will reside on that card for their entire life and cannot be copied anywhere else. I’m not commenting on whether that’s really proper or not, but there sure are a lot of folks who think it is, and there are manufactures that are creating smart cards do indeed exhibit that behavior.

If users are doing million dollar bank transfers, I think it makes sense to keep their keys in a self-destroying dongle.  In many other cases, it makes sense to let users move them around.  After all, right now they spew their passwords and usernames into any dialog box that opens in front of them, so controlled movement of keys from one device to another would be a huge step forward.

In terms of the deeper discussion about devices, I think we also have to be careful to separate between credentials and digital identities.  For example, I could have one digital identity, in the sense of a set of claims my employer or my bank makes about me, and I could prove my presence to that party using several different credentials-in-the-strict-sense:  a key on smart card when I was at work; a key on a phone while on the road; even, if the sky was falling and there was an emergency, a password and backup questions.

If we don't clearly make this distinction,, we'll end up in a “fist full of dongles” nightmare that will even make Clint Eastwood run for the hills.  When I hear people talk about CardSpace as a “credential selector” it makes my hair stand on end:  it is an identity selector, and various credentials can be used at different times to prove to the claims issuer that I am some given subject.

Speaking of smart card credentials, one of the big problems in last-generation use of smartcards was that if a trojan was running on your machine, it could use your smartcard and perform signatures without your knowledge.  Worst of all, smartcards lend themselves to cross-site scripting attacks (not possible with CardSpace).  To me this is yet another call to have the user involved in the process of activating the trusted device.

WordPress 2.1.2 and Project Pamela

I've installed a new version of WordPress – and Project Pamela's InfoCard plugin (more later) – and I'm using it to run my blog as of NOW.  If you see anomolies, let me know.

The good news is Project Pamela's InfoCard plugin is really slick.  It worked right out of the box. 

It doesn't require WordPress 2.1.2, but I wanted to get to the latest revision.

The bad news is that if you currently log in with an InfoCard you will have to respond to an email sent by the system in order to be switched over to the new way of doing things at my end.  Pretty painless though.

ISSUE: Password registration is still not enabled while I figure out exactly how it works