Category: Identity

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. 

Comment problem seems due to Firefox bug

As Pamela explains, it was neither the upgrade to WordPress 2.0.2 (made necessary by a security vulnerability discovered in WordPress 2.0.1), nor the nifty Pamela Project code, that has been causing problems when using non-Windows Card Selectors with Firefox on my blog.  Instead, it is the latest rev of Firefox itself (bugs are being filed).

For anyone who is using the “xmldap Identity Selector” Firefox plugin on the Mac and has suddenly found that they are unable to log into the PamelaWare Test Blog or Product Blog or Pat’s or Kim’s blogs, the problem is not with the blogs themselves. The problem appears to be buggy nastiness in the Mac version of Firefox 2.0.0.2, which wreaks havoc with Chuck’s plugin (xmldap Identity Selector v0.8.6) . If you uninstall Firefox 2.0.0.2 and then install Firefox 2.0.0.1 from mozilla.com (get release 2.0.0.1 here), you will again be able to authenticate to everyone’s blogs once again. The Safari plugin works as well, so if you want to remain on Firefox 2.0.0.2, you could satisfy your Information Card needs by using that plugin on your Mac instead.

We now return you to your regularly scheduled blog commenting :)

A number of people also discovered a less severe problem where comments ended up in a manual approval queue rather than being automatically posted even after InfoCard login.  If you have logged in with an InfoCard you should be getting automated instant access.  As far as I can tell, this now works properly.

Please keep me posted about any other issues.  This will help everyone using WordPress with the Pamela Project plugin.

Final note:  automated trackbacks will also be slowed down for a while I strengthen the trackback spam filter (gee – too bad there is no delegated authentication yet…)  If you want me to see a posting quickly please drop an i-names email.

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

Separating the identity of users from services

Geoff Arnold added a comment to an earlier piece that helps tease out the issues around delegation:

In otherwords, there is no user-absent scenario. There is a user is present and delegates authority scenario. After all, how can a user delegate authority if she isn’t present???

That's fine as long as one of the rights that can be delegated is ability to delegate further. And I'm guessing that that's what Eve is really talking about. Not delegating 100% of her rights to some agent, but delegating sufficient rights that the agent can act as a more-or-less first class entity, negotiating and delegating on her behalf.

In fact the only (obvious) right that I should not be able to delegate is the right of revocation….

OK.  So delegation is recursive.  If we accept the notion that services operate within their own identity when they do something a user has asked them to – then if they want to delegate further, they need to create a Delegation Token that:

  • asserts they have the right to delegate in some particular regard; and 
  • defines exactly what they want to delegate further, and to whom.

They need to present this along with the user's authorization.  One ends up with the whole delegation chain – all of which is auditable.

In this scenario, the user's identity remains under her control.  That's one of the things we mean when we say, “user centric”.  By issuing an authorization for some service to do something, she actually asserts her control over it.  I think this would be true even if, given a suitable incentive, she delegated the right of revocation (there are limits here…)

Multiple tokens to capture these semantics 

CardSpace is built on top of WS-Trust, though it also supports simple HTTP posts. 

One of the main advantages of WS-Trust is that it allows multiple security tokens to be stapled together and exchanged for other tokens.  

This multi-token design perfectly supports strong identification of a service combined with presentation of a separate delegation token from the user.    It is a lot cleaner for this scenario than the single-token designs such as SAML, proposed by Liberty, or the consequent “disappearing” of the user.

I guess I find Eve's contention that, “By contrast, Liberty’s ID-WSF was developed to support both the ‘human present’ and ‘human absent’ modes” a bit triumphalist and simplistic.   

Going forward I'll write more about why I think WS-Trust is a step forward for these delegation scenarios.  And about why I think getting them right is so very important.

Identities on multiple devices

As I said here, I want also to look at a second strange claim by Eve: 

On another issue, she noted that OpenID 1.0 has a vulnerability in that it leaves users’ identities open to possible correlation by unauthorized third-parties.

But that CardSpace has a vulnerability of an opposite but equally problematic nature. Given that each CardSpace is associated with a particular client device (i.e., a particular desktop, laptop, or mobile phone running Vista), and given the fact that each user might have multiple such devices, each with a multiplicity of cards running on them…that the more such devices, cardspaces, and i-cards multiply for a given user, the more difficult it will become for a particular user to correlate the various fragments of their identity across their own personal “space.”

This really strikes me as bizarre.  Maybe Eve was asleep while the entire world learned to copy mp3s onto their music players and carry them around?  Duh.  We know how to move files from device to device.  In fact there are probably many hundreds of millions of people who can do it better than either Eve or I can.

The idea that this is the big vulerability of CardSpace boggles my mind.  The whole criticism “Does not compute.”

Then again, I actually use Information Cards, and move them from device to device, so maybe that's why it's so clear to me how easy it is to do. 

Let me share the exact experience I have installing the Information Cards from my PC's CardSpace onto my mobile phone.

 Moving Information Cards from device to device

1)  I open up CardSpace and select Back Up Cards.  This will create a file containing my cards.  I decide to call it “cardset”.

2) I copy ‘cardset’ to my phone and click on it:

3) The phone asks for the password I used to protect my file

 

4) It verifies I'm importing the right cards

5)  And now I have the same cards on my phone device as on my PC.

How hard is that?  It would be the same process copying the file to some other device.  It works fine.  As easy as getting a word document or powerpoint or mp3 from one place to another.  Dongle anyone?  How about email?

Still, the uberpoint is this:  once Information Cards live on my phone, they go whereever I go. 

There are lots of ways phones can potentially talk to other devices.  So who says we have to copy our cards to all our devices once they live in a secure, personal device like a phone that we always have with us?

NOTE:  I want to point out that the mobile implementation of CardSpace I'm showing here is NOT a product.  It's a way of learning about the issues, and collaborating with colleagues in the world of telecom and secure portable devices.  But hey!  It's still a lot of fun.  More later.