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