CDATA Zone

You might have guessed by now, but I'm pretty keen on the xmldap identity selector. Most of the time I am running Fedora 6 with firefox and this was the first functional selector available for that platform. I have played with some others (also yet to be released) but until I find a compelling reason to switch, I am going to stick with this one.

Now, granted it is still a work in progress and bugs are to be expected, but it really drove me crazy this past month while I worked on the code for my managed card demo (the Microsoft Cardspace selector btw worked flawlessly). As of this time, the current xmldap selector doesn't seem to work with managed tokens. I have filled a bug report with a proposed fix, and until it is either fixed or I find out that I am doing something terribly wrong and its not the selectors fault, I am making available an unofficial 0.9.2 selector containing that one change (meaning with it you can use my demo).

Unofficial xmldap-0.9.2-cdata selector:
You can download it here: xmldap-0.9.2-cdata.xpi.

Now, my initial problems began prior to this bug. After my code created the managed token, I could not for the life of me get the selector to create a card based on it. Unlike Cardspace, which thankfully logs all the errors in the event log, this selector did not make a peep. It simply would not do anything after selecting the card from the filesystem through the selectors gui. This is where opensource really shines. I was able to open up the xpi, enable debugging and add some additional debugging routines for myself. Come to find out the card I was creating contained a BOM. There is nothing wrong with this, perfectly valid with XML documents and worked fine with Cardspace. The xmldap selector however craps out bad. Once making sure the created cards did not contain a BOM, I was back on track.

My next problem had to do with my testing. I was repeatedly installing cards to test out the affects of some of the optional fields from the managed card structure. The problem now ended up being that the selector doesn't update the cards (based on the card ID and the version). I ended up with a store containing a good number of the same card. This really wouldn't have been so bad except once this happens, it seems like the selector gets confused making it impossible to selecting any of those cards (my other self asserted cards still worked fine). Again, thanks to the wonders of opensource, I saw that the store was an XML file located within my firefox profile. I was able to open it up, remove the offending cards, and start again. With a single card for my demo system in my store, I was now ready to fully try out the relying party.

Ok, next roadblock (and this was the big one). When submitting my card to the RP, the token is retrieved so my username and password are required. Things were looking good until I got a big popup on the screen with a Java exception error. Something about a chainLength. This one took me a good few days to find out what was going on, which ultimately lead me to that bug report and the code change. Hopefully that patch is correct as this was the only problem that I could not work around on my side and had to modify the selector code itself. Again, feel free to try it out: xmldap-0.9.2-cdata.xpi. It is a copy of the xmldap released version with that one line added to the infocards.js file.

I finally finished putting together a demo of a system using the PHP code I wrote for Managed information cards. Other than the minor problem I previously had with namespaces, getting it working with Cardspace was simple. The xmldap selector, on the other hand was not so simple (more on that in a separate entry). Anyways, after having been first introduced to infocards, I envisioned a system where I would be able to surf the web maintaining my anonymity, yet still be able to achieve some personalization on sites. Sounds a bit like an oxymoron, but let me explain.

My surfing experience is pretty bleak. I use anonymous proxies to shield my IP. At most I only accept cookies during a session. I wont register with a sites unless I have some specific reason, and I wont give a site information (requiring another login mind you) just so they can tailor the site to my interests. I don't really care about the social networking sites - though I've tinkered with LinkedIn so dont have much of linkability. Software cleans up any non-trusted cookies and scrubs the disk each time I shut down the browser. I am probably the thing marketing people hate the most.

Now, when I was first exposed to this technology, I envisioned the possibility that I could pass some of my personal preferences to a site I was visiting, allowing them to tailor their site to me, all the time then not knowing or having any further information (no email address, no username/login, etc...), simply just a list of things I am interested in. While creating my libraries in PHP for an identity provider, I decided to create a working demo of what I envisioned. I went so far as to create the identity provider on a different domain than the relying party.

Getting a Managed Card:
How this system works. You first need to register at https://www.ctindustries.net/icard/index.php. Registration simply involves setting up a username and password (in order to retrieve the card and manage the account) and selecting from 1 to 3 of the listed categories you are interested in. Once you have successfully saved this information, you can then click on the Retrieve Managed Card link to download and/or install the managed card. Although I set a custom type, I decided upon SAML to convey the claims.

Using the Card:
The relying party side resides at https://www.cdatazone.org/demostore/index.php.

When not logged in, the system will randomly select 3 categories for you and then randomly display the top 3 items for sale within those categories. This is done leveraging the Yahoo! Shopping API. Each time you refresh the page the results will either be displayed from a local cache or are fetched and cached. (So Please be patient if it takes a few seconds making remote requests behind the scenes).

When logging into the demo system, the identity selector will retrieve your previously selected categories and pass them to the system. These results you now see are based on your personal categories rather than the system randomly picking them for you. Each time you refresh the page the results returned will only come from one of your categories.

Now, I really don't know how feasible of a use of information cards this really is, but it something I really wanted to see if possible and the reason for this demo. I will be releasing the code over the next week. I am currently debating whether to use native ext/soap, so all conditions (like errors) are handled properly or just leaving the code as is (some XML build on the fly and some embedded within soap structures). Until then, I am at least providing the code used to create the managed card, which in turn uses my new library code: createcard.phps

Work has been keeping me extremely busy over the past few months, so I haven't had much time for any new entries. This, however, doesn't mean that there hasn't been anything going on. I figured it was about time I provided an update so people will quit asking if I'm still alive

XMLSec/WS-*:
Contrary to what I said in the past about no longer maintaining these libraries, I have been quietly releasing updated versions of the code with bug fixes. There are quite a number of people using them for various reasons so I have decided to continue supporting and developing all the libraries. There will be a few changes though. I have had far too many emails and questions concerning the lack of licensing (For some reason people don't get the public domain concept). To hopefully reduce the amount of questions I get about this, I will be releasing the next versions under a BSD license. I will also being maintaining versioning information for each file and the changes made between versions. The changes made so far have primarily been concerned with fixes when used through a SOAP server context, some ability to perform encryption in a SOAP message from the client side and some new features that I have needed for an Managed Identity provider (see the Infocard section for details).

Identity/OpenID/Infocard: