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.