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.

Details of firefox bug

From: Chuck Mortimore
Sent: Tuesday, March 06, 2007 5:50 PM
To: Pamela Dingle
Cc: Eric Norman; Neil Macehiter; Kim Cameron
Subject: Re: Figured out the xmldap/firefox issue
 

Weird….Sorry I've been quiet – very busy at work these days.

– cmortOn 3/6/07, Pamela Dingle wrote:Ha, I figured it out.Since you said that nothing had changed on your box since when it
started working and when it didn't, I started going through my software
update logs.  Nothing there. But then I went to mozilla.com
and checked
release dates there.Turns out Firefox

2.0.0.2 came out on Feb 23.  At some point you must
have updated, and things started failing.  To prove this, I just
downgraded to FF
2.0.0.1 — and presto, Chuck's plugin works.  So the
issue is an incompatibility between FF
2.0.0.2 and xmldap 0.8.6.I'm going to blog this ASAP so people know what is going on…  thanks
for twigging me onto the right path Eric, I'm so glad I can finally
explain what's going on!

Cheers,

Pam

Eric Norman wrote:
>
> On Mar 6, 2007, at 2:57 PM, Neil Macehiter wrote:
>
>> All
>>
>> My results are totally consistent with Pam's. I am unable to login to
>> either Kim's identityblog or Chuck's Java relying party using XMLDAP
>> (version 0.8.6) on Mac OS X 10.4.8 (PowerPC) with Firefox 2.0.0.2
. I
>> have JRE 5 installed.
>>
>> Interestingly, on the 2nd March I was able to login to Kim's
>> identityblog using XMLDAP (and I am pretty sure I was also able to
>> login to the Java Relying Party but I can't swear on it).
>>
>> I am encountering no such problems on Windows.
>
> Here's some observations from me that might lead to a clue about Firefox
> on a Macintosh.  Then again, they might not.
>
> With Firefox on a Macintosh, there's an extra icon under preferences
> called “Identity Selector”.  You have 2 choices: Microsoft CardSpace or
> XMLDAP.  I have always set it to XMLDAP.  I have no idea what the
> purpose of this preference is or why it's even offering me a choice
> about Microsoft.  But anyway, I tried them both.  As near as I can tell,
> it doesn't make any difference.
>
> The only reason I'm mentioning this is that it is something would be
> different between Firefox and Windows and on Macintosh.
>
> When I get to the page with the “Invoke Identity Selector” button,
> I get two buttons.  The source for the page says there should only
> be one — see attachments 1 (.tiff) and 2 (source).  So I think that
> the <OBJECT> element is messing up the rendering.
>
> If I click on the upper button, I get an identity selector and don't
> see the error until I select and send a card.  If I click on the
> lower button, I get an error immediately.  And it's a different error
> page that says code = EMPTYTOKEN.
>
> However, I sure don't think I saw the double button Sunday when
> this used to work at KIm's blog (but maybe I did and just don't
> remember).  Anyway, this sure is curious.
>
> Eric
>
>
>
>
> ————————————————————————
>
>
> <!DOCTYPE html PUBLIC “-//W3C//DTD XHTML 1.0 Transitional//EN” “
http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd “>
>       <html xmlns=”
http://www.w3.org/1999/xhtml“>
>               <head>
>                       <meta http-equiv=”Content-Type” content=”text/html; charset=UTF-8″ />
>                       <title>Information Card Invocation</title>
>               </head>
>               <body>
> This site is under maintenance – anything is possible<br/>
> <br/>This page contains the hidden form object that specifies required and optional claims, and invokes the Identity Selector.<br/>
>
> View the page source to see the object.<br/>
> Net Agent: septemberAgent
> User agent string:<br/><br/><pre>Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:
1.8.1.2) Gecko/20070219 Firefox/2.0.0.2</pre><br/>                         <form name=”ctl00″ id=”ctl00″ method=”post” action=” https://pamelaproject.com/debug/wp-content/plugins/wp-infocard/processing/infocard-post.php“>
>                                       <OBJECT type=”application/x-informationCard” name=”xmlToken”>
>                                       <PARAM  Name=”tokenType” Value=”urn:oasis:names:tc:SAML:1.0:assertion”/>
>
>                                       <PARAM  Name=”requiredClaims” Value=”
http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress http://schemas.xmlsoap.org/ws/2005/05/identity/claims/privatepersonalidentifier“/>
>
>                                       </OBJECT>
> <br/>No clickback detected<br/>
>               <input type=”submit” value=”Invoke Identity Selector”/>
>
>   </form>
> </body>
> </html>
>
>
>
> ————————————————————————
>
>

Temporary problems logging in?

A number of people have had problems logging in to my blog from non-CardSpace identity selectors.  Eric Norman writes:

As of the upgrade today, I can't get to Kim's blog any more. The same thing happens with either Firefox or Safari.

When I click on the link to log in with an InfoCard, I get redirected to an error page that says I submitted an invalid one (see attachment).

I suspect that the problem is in on the WordPress side since it happens with two separate browsers, but I suppose it's possible that they both share some bad code.

In any case, I would be glad to help diagnose the problem…

I do come from an academic environment and we here do care a lot about interoperability across platforms. While I understand that all this code is still very experimental, I am faced with the problem that it worked yesterday and doesn't work today.

As long as I'm trying to help debug, I'll mention one other thing.

I don't know if this is still a problem since I can't get far enough any more. Neither of the above identity selectors have the ability to export and import cards, so I just had to install a new card on each. Whenever I would switch browsers, I would have to go through  the email verification bit again. This could get rather noisome.

It appears that the server side just remembers the last card that contains an email address instead of all of them.

So first, let me say I threw my blog into Pamela mode as part of the Pamela beta – hoping people who come here would be willing to put up with any inconvenience.  Maybe I should have asked first!  And I probably should have asked for Project Pamela's permission as well.  What can I say?  I'm an architect and I get excited about things.  I've really wanted to get on to production code. 

Make a note not to hire me as your operations manager…

We'll get it sorted out ASAP.  I'll post when we get things fixed.  In the meantime, if you use the Safari or Firefox Java identity selectors please use my i-name (or my email) to send your comments and I'll post them.

In terms of Eric's comment that it should be possible to register several cards at once, I know Pamela Project wants to work on that.

Finally, we need a cross-vendor automated test suite that includes tokens produced by everyone's implementations.  All of us will want to test with such a resource.

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.