Category: Digital Identity

My first i-names spam

 I've been using an I-name (it is here) for a couple of years now and have never received anything I considered spam.  It's been a great way for me to get feedback and input (even if I haven't always been able to respond in a very timely fashion due to the demands of my “day job”). 

But today, that period of initial innocence came to an end.  It seems that Mr. Gerg, below, has built a little contraption that makes it past 2idi's email verification process.  I'd say my friends Fen and Victor, who created the Eden in which I've been living, need now to add a Turing test to their system.

Meanwhile, the proposal made by Mr. Gerg is “too muchie”. 

If the search engines are smart enough to figure out this kind of goofie manipulation, why go to all this trouble? Just because you can?

As shown at right, Dane Carson's memey little Technorati applet calculates the value of Mr. Gerg's property as being zero, compared to the bizarre value it places on mine (if anyone wants to buy, please send check).  When I look into Google's page rank, Mr. Gerg's property is just a “5”, even though it has about 4700 links, so Google has figured out the links are to things of very low value.  Seems like we might be getting somewhere with reputation.

So you would wonder why he would he spend his time building an engine that sends me i-name spam to do something that doesn't seem to be working in the first place. Anyway, if anyone wants to look at the pages he is referring to, you'll have to add the “p” to shopping that I removed from the URLs below – so as not to contribute any further links to his site or person.  I've also purposely misspelled his name.

Hello Kim Cameron,

My name is Alex Gerg and I am the manager of the project for http://www.shopingwallet.com

I have a proposal I would like to make. I have looked at your BLOG https://www.identityblog.com and think we can benefit from a partnership. Our site has more then 10,000,000 pages. Google, Yahoo and MSN each has already indexed over 300,000 pages with projected 2,000,000 pages in the next 2-3 month.
Google cached pages:

http://www.google.com/search?hl=en&rls=GGLJ%2CGGLJ%3A2006-34%2CGGLJ%3Aen&q=site%3Ahttp%3A%2F%2Fwww.shopingwallet.com%2F+online+shoping

I would put your site’s text link to my site http://www.shopingwallet.com. Your link will be placed in our Partners  section at the bottom of our site on every single page, over 10,000,000 pages.

In exchange we would like to ask you to put a text link in the footer or in other section on your web site.

I am open to any other suggestions you might have for partnership. Please fell free to ask any questions or offer other forms of partnership. I would appreciate your reply.

Sincerely,
Alex Gerg
advertising@shopingwallet.com

***********************
Ths message was sent via your 2idi I-Name Contact Service.
Sender Information:

Email: advertising@shopingwallet.com
Real Name: Alex Gerg

Doing my research on how many links he has on different systems, I noticed that he's also spammed the list at the debian project.  I'll bet he's really going to pick up a whole lot of support there too…

Of course, maybe this is just a digital centrifuge intended to separate out the real suckers that he can then go after in some other way.

Hackers selling IDs for $14

This post is from David Evans, at The Progress Bar: 

Did you see the rejected Superbowl commercials for Godaddy? One particularly funny one was about two guys, one kept asking the other what his girlfriends name was, then his mother and his dog. The guy would immediately purchase their names as a domain name, to the others guys frustration.

Why do I bring this up? Macworld writes about a Symantec report that says hackers are selling ID’s and credit card numbers on the net.

U.S.-based credit cards with a card verification number were available for between US$1 to $6, while an identity — including a U.S. bank account, credit card, date of birth and government-issued identification number — was available for between $14 to $18.

Now it’s even easier to buy someone on the internet, for only $18, scary.

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.

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.

Wrong-headed impersonation

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

“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).

“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.

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”.

On behalf of…

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.  Ever.

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.  Wouldn't you want the linkback service to be able to log in with your identity?

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”?

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.

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.

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 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.

There is no user-absent scenario 

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???

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.

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.

Surely it is obvious this is the best way to reduce everyone's exposure and liability.  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.

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.