I almost forgot…

I’ve been so wrapped in code and new features for PamelaWare, and the Interop next week at Catalyst, that I haven’t mentioned here that I am speaking at Catalyst!

My talk is entitled “What I learned when I stopped thinking about Information Cards and started Using them — a drama in 3 acts”. It is a gripping tale of romance, revelation, and ultimate wisdom that I hope you all will enjoy. The soundtrack will be out shortly :)

If you are attending Catalyst, be sure to come and heckle on Wednesday afternoon, June 27 2007, in Grand Ballroom B – and don’t forget to wander by and say hello at the Interop that night, which is in Plaza A, on the first floor. I’d be happy to give you a tour of at least part of what will be the most comprehensive collection of Identity Metasystem components assembled to date, working together across multiple hardware, operating system, and development platforms, and representing both open-source and proprietary interests.

See you there!

Fun with XHTML Selector Triggers

As part of the upcoming Burton User-Centric Identity Interop at the end of June, I have updated PamelaWare to be able to optionally trigger identity selectors from an XHTML ‘binary behaviour’ object instead of the typical plain-jane HTML object. The difference between using HTML and XHTML is ostensibly that an XHTML object should validate in an environment which requires conformance to the XHTML 1.0 W3C standard.

I made a tragic mistake in not closely reading the XHTML syntax example in the Information Cards Web Application Guide. I didn’t notice that on the very first line, there were 8 critical little characters listed on the first line of the example that are needed for the object to work. As a result of not reading that example closely enough, I spent a long long time trying to figure out what the problem was, creating new problems for myself, and ultimately coming out of the whole thing a lot wiser. I’ve listed below some of the interesting details that I stumbled upon during my adventures. If you couldn’t care less about the dramatic exposition and just want to see working code, check out my example page here.

The Final Result – and Weirdness #1

Here’s the ironic outcome of my studies –the object that works with CardSpace doesn’t perfectly comply with the XHTML 1.0 standard! See if you can spot the problem in the object below (note that for display purposes I unnaturally split the schema URI within each of the <ic:add> elements — if you paste this for your own use, you will need to remove my formatting from those attributes, so that they are on a single line) :

 <html xmlns="http://www.w3.org/1999/xhtml"
        xmlns:ic="http://schemas.xmlsoap.org/ws/2005/05/identity">
<head>
      <title>Example of a Working XHTML Selector Trigger Object</title>
</head>
<body>
        <form name="ctl00" id="ctl00" method="post"
                action="https://pamelaproject.com/pwwp1/example.html">
        <ic:informationCard name='xmlToken'
                style='behavior:url(#default#informationCard)'
                tokenType="urn:oasis:names:tc:SAML:1.0:assertion">
                <ic:add claimType="http://schemas.xmlsoap.org/ws/2005/05
                        /identity/claims/emailaddress" optional="false" />
                <ic:add claimType= "http://schemas.xmlsoap.org/ws/2005/05
                        /identity/claims/givenname" optional="false" />
                <ic:add claimType="http://schemas.xmlsoap.org/ws/2005/05
                        /identity/claims/surname" optional="false" />
                </ic:informationCard>
        <center>
        <input type="submit" name="InfoCardSignin"
                value="Trigger the Selector" id="InfoCardSignin" />
        </center>
        </form>
        </body>
</html>

Did you see the problem?


Section 4.2 of the W3C XHTML 1.0 specification states that “Element and attribute names must be in lower case”. But if you try to turn the claimType attribute into claimtype, or the tokenType attribute into tokentype, you are going to get this error:CardSpace Policy Validation Failure error

In fact, this is the error you’re going to get if you make any mistake at all in the XHTML object. You get this if you have no xmlns:ic definition in the html tag at the beginning of the document. You get this if you try to lowercase the attribute names. Let’s just say that the CardSpace development team didn’t put a lot of time into making the syntax errors for selector trigger objects descriptive or helpful in any way (the errors for syntax problems in HTML are no better). Avoiding this error began to take on a superstitious voodoo-like feel for me after a while, because there where times where the object suddenly stopped working, and I couldn’t remember what I’d done since the last time it worked, and I couldn’t see a single thing wrong with the object that was being sent. Several times I just gave up and began again to reverse engineer from my one semi-operative example. My suggestion is — get your object working and NEVER TOUCH IT AGAIN, because I definitely haven’t documented here all the things that can cause the evil “Policy Failed Validation” message to crop up.

Weirdness #2 – <ic:informationCard> and <ic:InformationCard>

The other interestingly odd thing about this XHTML object is that it is named EXACTLY the same as another object within the <ic> XML Namespace. The same, that is, with the exception of the capitalization of a single letter of the name.

<ic:informationCard> is the XHTML selector trigger object. <ic:InformationCard> is the signed XML document that represents an actual digital information card (explained here).

Now I know that XML is case sensitive, and I also get that these two objects are used in very different places and therefore never would collide in the real world — but google searches aren’t case sensitive, and with all the possible names to give two different concepts within the IC namespace, wouldn’t it have been smarter to differentiate between these two items by more than just the case of a single character? Yegads. I believe that the architects may come to regret their naming decision one day.

The Mistake I made

I did not notice the critical definition of xmlns:ic on the first line of the Web Guide example. Turns out these eight little characters make the difference between the object working or failing, and the Web Guide does not discuss or highlight the necessity for the namespace definition anywhere in the document, so if you don’t recognize the significance of those characters from the example, you are right out of luck.

The Document that Worked:

Given that I’d misread the Web Guide, the only document which otherwise had an example of a page containing an XHTML binary behaviour that successfully triggered CardSpace without running into the evil “Policy Failed Validation” brick wall turned out to be this white paper, written by Dan Connelly, comparing various web security architectures. It is a fascinating read, as it turns out, and I’m amazed I’d never seen it until now. The XHTML example in this document had all of the syntactical elements necessary to bypass the evil “Policy Failed Validation” error, although it took me a bit to figure out why it still wouldn’t let me select a card (the actual error message was that the site required a managed card that I the user didn’t have — but that turned out to be an easy fix, the example used out-dated schema URIs for the claims, as well as an outdated xmlns:ic namespace). The ability to finally be able to create a web page that properly triggered the selector was a huge breakthrough, I’m so glad that this page was out there for me to find.

Weirdness #3: No schema description file for <ic:informationCard>

The official xsd for this object doesn’t seem to exist. Various parts of what would be in a schema description file are described in the Web Guide – but for example, the “name” attribute isn’t described in the web guide, but is present in the examples. What other attributes are validly part of that object? Who knows…

Weirdness #4: A totally different way to use <ic:informationCard>?

Both the Eclipsipedia CardSpace Support Page and Cesar De La Torre’s Blog show the <ic:informationCard> object in the <HEAD> of the document, not within a form inside the document body. They also don’t have the requisite capital “T” for the element names. I’m not sure what exactly is *supposed* to happen when you put the object in the document header instead of in the body surrounded by a form — the only thing I can imagine is that the object would automatically be executed, triggering the selector on page load, but I couldn’t get this to work under any circumstances, and since this header usage is not documented anywhere, only shown in example, I don’t know how to get from what appears to me to be non-functioning examples to actual working code. I have a second theory that when you consume the XHTML object from WCF instead of from a browser, the case sensitivity of the claimType and tokenType ceases to be an issue.

If anyone knows how this <HEAD> usage of the XHTML object works or can point me to a working example, I would appreciate it, it might be very very useful to me :)

The Moral of the Story

Documents are great, but working code is much much better… the more of that we have, the happier we all will be.

Information Cards @ Catalyst 2007

Yes

there will be an Information Card Interop Event at the Burton Group’s Catalyst 2007 conference in San Francisco on Wednesday June 27, 2007 from 6 – 9:30pm.

Yes

all of the cool kids from the world of information cards will be there, and ready to show each other, the Burton analysts, and most importantly – YOU, the folks who might just want to use this technology to solve a few important problems, just what this technology can do – not in theory, but in demonstrable practice.

Yes

we’ve already started — everyone got together at the IIW conference in Mountain View on May 15, 2007, and started testing combinations – 11 Relying Parties, 7 Identity Providers, and 5 Identity Selectors (also known as Identity Agents) all worked together to see what combinations of 4 different token types, 2 different managed card authentication mechanisms, and 10 different required claims, of varying types.

Yes

the Pamela Project is participating in the Interop — please make a point of dropping in to say hi, I’ll be hanging out in the Relying Party section, and I would love to talk to you.

So are you coming out to see us?

YES!

I got the issuer blues…

Here is a simple and likely RP scenario that I’d like you to consider:

A given site wants to allow users to pay with either their Visa or their Mastercard information card. They do not, however, accept American Express. How should they create their security policy such that Visa and Mastercard managed cards are both highlighted in the Identity Selector if present, but also such that an American Express Card is grayed out and not clickable?

Would you all agree that this is a pretty important thing for a Relying Party to be able to implement? I think it’s important too, but I don’t see an easy way to actually accomplish it.

To my knowledge, there are two ways to choose what cards are highlighted and what cards are grayed out in the identity selector:

  • if a card’s issuer matches the value of the issuer parameter
  • if the entire set of required claim types are all present in a given card.

In the scenario above, the issuer parameter is a non-starter, because Windows CardSpace v1.0 only accepts a single issuer. And at this point in the identity metasystem, what WCS says, goes. I can specify Visa’s STS, or I can specify Mastercard’s STS, or I can choose not to specify an STS at all, but I cannot specify exactly two of them. Bottom line: as soon as I need to create a policy that lists more than one issuer, but less than all issuers, I cannot use the issuer statement.

So – that leaves us claims. Claims are great – when you can use what’s in them. In this case, however, the RP can’t work with claim values, only with claim types. In order to succeed in my scenario using claims, I would need to be able to specify a claim type that both Visa and Mastercard offer, but that AmEx doesn’t, in order to have the right cards show up and the wrong cards gray out. What exact claim type would that be? The only way I can see to architect such a thing is to have a commonly agreed upon but different claim type for every possible distinct combination of credit cards. Let’s say that there are 6 major credit card companies out there. How many permutations & combinations of claim types would be necessary to cover every single combination of 2,3,4, and 5 accepted cards, and how ugly would it be to add a new credit card?

It could theoretically be done. Identity Providers would have to start publishing two very separate types of claim types — contentless claim types that advertise capabilities, and content-rich claim types that would deliver actual data values. If you implement the capability claim types as constants and not as directory schema, it isn’t so bad — but the big problem is, it takes the ‘distributed’ out of this wonderful distributed system.

Unless things change (or unless I’m proven wrong, maybe I’m just missing some answers and need to be educated), here is what I fear will happen: users would go to a Relying Party Site, only to be presented with an HTML “menu” of supported managed card providers. They would then click on the card provider logo, and an HTML object would be invoked which has an issuer tailored to that single provider. Is this what we want to have happen?

If it does happen, I can see all sorts of fallout:

  • Common claim types are no longer needed to ensure the user picks the right card. This is good.
  • Every RP has to alter HTML to support a new Identity Provider. This is bad, or at least worse than adding a url to an allow or deny list.
  • The ability for a Relying Party to require the same claims from every Identity Provider becomes damaged. This is bad. Of course, with issuer in the state it is in, I would say that no matter what, this is already the case.
  • The system is more distributed, but MUCH less consistent for the user. This is bad.
  • It opens the door for the more established Identity Providers to set arbitrary rules on what attributes “must” be asked for in order to interoperate, forcing Relying Parties to embed different code for each provider. This is bad.

Of course, all of this hinges on how important the initial card presentation ceremony becomes to the world. Remember that we are not talking about the RP’s ability to accept or reject a card once it has been selected. We are only talking about how to get the most user-friendly initial display of highlighted or grayed out cards when the selector opens. Maybe this small part of the information card ceremony won’t end up being that important — but I predict that it will. If I could have have any kind of solution to the problem, it would be the ability not just to list multiple issuers, but to apply Boolean logic to the list, so that I could represent ideas like “every issuer except these two”.

Kim, Mike, what can we do? Is this as big a problem as I’ve made it out to be, or am I just whining about something inconsequential? What is your vision of how my scenario could be implemented? Can this be solved with a few best practices, or do we need to change the way that information card RP security policies can be specified?

Update:  Kim answers here – thanks for being so responsive   :)

Hot Chicken!

I`ve barely recovered from this year`s Directory Experts Conference. As always, the NetPro folks found a great location, fed us well, and kept everything running like a finely oiled machine. Even a Wookless event couldn’t kill the fun — Wook took his challenge from Stuart Kwan remotely and exceeded all expectations as usual. This time the challenge was to adapt the kermit-the-frog song “rainbow connection” to describe strong authentication… it was priceless.

This year, it wasn’t the partying that tuckered me out at DEC – it was the coding marathon! We had a last-minute sprint to finish up our information card adventure for the attendees at DEC, cooked up by a few of us for the purpose of getting people at the conference to use and understand the Identity Metasystem as a real thing and not merely as a lofty concept.

Hot Chicken!Our adventure was a website called HOT CHICKEN!. Hot Chicken! is a site where you can go to vote on the best picture of a DEC attendee with the DEC Chicken — in this case a 6’5″ rendition of said chicken. The attendee who gets the most votes for their picture will win a Microsoft Zune – but you have to use an information card to see the pictures and to vote. If you are wondering what on earth any of this has to do with a chicken, the answer is that the chicken has a long and venerable history at DEC, which I am nowhere near qualified to explain. You’ll have to check out Gil`s blog for that kind of insider information :)

The Hot Chicken! site is built with Joomla (the open source Content Management System) and has PamelaWare for Joomla installed, not quite a version of PamelaWare that I can release (I hard-coded most of the admin settings) — but it is pretty darn close. Using PamelaWare for Joomla (PW-jos for short), users can authenticate to Joomla via information cards.

Even MORE interesting is that you can authenticate to Hot Chicken with one of two Identity Providers:

Nice Wings, BabySo please go and give Hot Chicken! a try! You’ll see there are still loose ends & holes (there are a few blog entries that will come from my chicken experience, that’s for sure), and we’re missing some critical validation bits & testing, but I’m still pretty sure that by enabling Joomla and opening up 2 new identity providers, we have taken a big step.

The Pamela Provider is up and running as a direct effort on the part of the Bandit team, and particularly of Daniel Sanders and Dale Olds, who managed to plow through all sorts of barriers and issues with dogged determination to get the provider running in time for Gil’s announcement on DEC day 2, as I worked on RP code (which was originally contributed by Pat Felsted, another Bandit, and then “pluginified” by me). The Bandit team as a whole has earned my eternal respect & gratitude, many thanks everyone (even Tom) :). I’m really looking forward to growing and maintaining the Pamela Provider for a long time to come, and to contributing back to Higgins in as many ways as I can.

Of course, all of these shenanigans were really a prelude to my talk on CardSpace — a summary of which I will save for another day.

So go vote!!! And tell me what you think…

The next two months

This is going to be a fun summer for anyone interested in information cards. Everyone seems to be on the cusp right now, and I hope to see an explosion of available code, products, and services surrounding the identity metasystem.

Just to put a bit of skin into the game, so to speak, here is what you can expect to see from the Pamela Project before June:

  • A new PamelaWare Joomla plugin (available by May 10)
  • A release candidate for the WordPress Plugin (available by May 10)
  • Updates to both plugins that allow:
    • integration with native username/password functionality
    • integration with the WP-OpenID plugin (not sure about Joomla)
    • ability to specify & map claims to database fields for adaptation to managed card requirements
    • ability to specify & advertise a privacy policy
    • Audit capabilities that are compatible with the XDAS standard and hopefully contribute to the OpenXDAS project.
    • a prettier, more web-standards-compliant login page
    • Ability to choose either an XHTML or HTML compliant login page
    • A release candidate for the WordPress Plugin (available by May 10)
  • More surprises, just wait and see

Before the above can be rolled out, I need to finally & totally grok subversion branching & tagging. The textbooks have been ordered… but if you are a subversion guru and would like to contribute to the PamelaProject, you would be my hero.

I had the chance last week to hang out at Bandit HQ, and they are doing some really exciting things. It was a blast getting to geek out and they really took care of me – we even had a photo day! I have dastardly designs on most of the infrastructure that they and others are putting together, and the code is now at the point where I, as someone wanting to develop that next layer up, can actually depend on the foundation. It isn’t perfect, but I do think that having someone actually working on top of a layer is a great way to vet the solution. I’ve already warned the Bandits that I’m really talented at breaking things :)

The Directory Experts Conference is on next week in Vegas — be there or be square, we are planning a few of what I hope to be information card firsts for the attendees, stay tuned for more information.

XMLDAP on Mac – the Final Answer

It turns out that my last post was not the end of the XMLDAP on Mac story.

If you couldn’t care less about the why/wherefores and just want the answer – you need to install Kevin Millar’s perpetual motion browser extension along with the XMLDAP extension on the Mac, to be guaranteed that the identity selector will work with all the RPs out there. Big huge thanks to all the people who worked on this problem, I think I would have gone clinically insane at about 11am yesterday without you.

Now – onto the geeky explanations:

After downgrading to FF 2.0.0.1, some subsequent further instability, and a reboot, I found that although I could finally successfully get to Chuck’s RP, I still couldn’t use the PW-wp test blog. I had made the mistake of conflating two issues, and assumed that because one was working, the other should be too.

So I started troubleshooting all over again – but this time with a solid example of a service that worked, to compare to my non-functional service. I copied the page source of Chuck’s form object to my test blog, and started changing it, line by line, to match my form object. Here is the line that eventually caused Chuck’s form to fail:

 <input type="submit" id="submit" value="Invoke Identity Selector"/>

And here is the line that works in Chuck’s RP form:

<img src="../images/cardlogo.gif" onClick="infocard.submit()"/>

Yeah, so a basic, HTML 101 type of form submit fails. No way. But it’s true. Feel free to test this out, if you have a Mac: try this link:
With an html submit (first example above, which fails)
and this link:
With an onClick Javascript event attached to an image(2nd example above, which succeeds)

Even if you embed a document.form.submit() call in the document, it fails:

With an embedded submit call

At this point I had enough solid information to talk to Chuck, and bless his heart, he responded right away with a suggestion – if it was a parsing problem, we could diagnose it by installing Kevin Millar’s perpetual motion Firefox extension – because when that plugin is installed, Chuck’s plugin uses the perpetual motion parser instead of the xmldap parser. Sure enough, when the xmldap and perpetual motion plugins are installed together on Firefox, everything works beautifully. Try the 3 links above with the 2 plugins on a Mac — you’ll find they all work.

I *could* change the PamelaWare login page to use the one type of form submit that is guaranteed to work with Chuck’s plugin, and not push the idea of using both plugins together, however from the user’s perspective, this is only a partial solution. As more and more people start writing RP code, there are going to be a million permutations & combinations of a million different forms out there, and I would rather see people installing that extra plugin, so that they can get everywhere, without having to diagnose issues on an RP by RP basis.

So I’m going to update the documentation on the Pamela Project website, and I would suggest that others do so too, to recommend that if you want to use the xmldap identity selector on a Mac, you install both the xmldap and perpetual motion plugins. Yay, case closed, now onto new feature development…

Firefox 2.0.0.2 on Mac breaks the XMLDAP Plugin

Note:  for anyone searching on this issue – it was resolved in version 2.0.0.9 of Firefox and subsequent versions of the xmldap selector.  More info here:  http://ignisvulpis.blogspot.com/2007/11/new-versions-for-firefox-2009.html

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 :)

Did you see?

Pat Felsted posted this sneak peak on his blog — by george, we might have a new contender in the Identity Selector client department.  I can’t tell you how happy this makes me, we can’t really get serious about this technology until access to it can happen in a dependable way, from anybody’s local computer.   I can’t wait to get the opportunity to push all the buttons and see what busts.   It’s a mark of affection, really it is :)

McAfee and Managed Cards

If you have a McAfee security product on your computer, and you try to use CardSpace to get to a managed card, you might run into trouble.

Actually the problem isn’t really the managed card, it is that McAfee hasn’t got any special rules figured out for CardSpace as a program yet, and I’m reasonably sure that any transaction that uses the fancier authentication model where CardSpace calls out to an endpoint to discover & retrieve policy looks suspicious to McAfee’s default rules. As a result, McAfee silently blocks the transaction, without even sending a verification prompt to the user. The blockage also doesn’t show up in McAfee’s “Recent Events” screen either. I saw this behaviour with managed cards, but it seems likely to me that the same problem would crop up with a Relying Party STS too, and in that case I think it would happen for any kind of card. I don’t know of any RP STS’s out there, so it’s hard to test that hypothesis.

I hope McAfee will get their act together and put a little research time into CardSpace – but until then, there will be people out there who won’t be able to perform some card transactions and will probably have a heck of a time figuring it out.

So – if you are trying to use a card at a site, and you get this message:

Your data could not be retrieved from the managed card provider. Check your network connection and verify that you have supplied the correct authentication credentials.

And you have McAfee, you need to follow these instructions:

  • Open up Security Center
  • Click on the “Reports & Logs” menu item on the left side
  • Click on the “View Log” button
  • In the new window that pops up, select “Internet & Network” on the left hand side.
  • Select “Outbound Events” under “Internet & Network”.
  • You will then (finally) see a log file that will show you that Windows CardSpace was blocked.
  • Click the “Grant Access” or “Grant Outbound only access” button to solve the problem.

There is a “Learn More” button on that screen. The “Learn More” button just informs you that McAfee has no clue what Windows CardSpace is. Doesn’t that seem a little embarrassing for a Security company not to have heard of or prepared for something like CardSpace? McAfee does provide an application feedback form for end-users to describe programs to them – perhaps if we were all to fill out that form and describe the issue, they would add CardSpace sooner rather than later. The form is here.

MacAfee Blocking CardSpace