Quicksearch

Archives

Categories

Monday, February 19. 2007

A while ago I was having a conversation in which I mentioned that I was surprised you didn't see Information Cards used with more languages. Without thinking I quipped that even I could easily port the code I wrote in PHP over to Python. I tend to be one of those people who if you say you are going to do something, by god you better see it through; so it was time for me to put up or shut up. I haven't touched Python in a good 10 years so I had my task cut out for me. One of the biggest problems I had while going through this exercise was finding out what modules I need to and/or should use and then figuring out how to use them.

Using a stock Fedora 5 install, the only additional modules I had to install were python-crypto, m2crypto (both used for different crypto aspects) and lastly, PyXML (so that I had access to xml.dom.ext for canonical xml support). The remaining modules I used were already available. Although it took me a few days to port the code, an experienced Python developer (who was also familiar with PHP) could have easily done this in a few hours - and their code would have been much better.

You can find the source code for all of this within the python section of my Source Code page. I have also made a Python Information Card Demo available. The code simply decrypts the submitted card, verifies the signature on the included SAML document, and prints out the included Assertions.

I probably will continue to complete the conversion of the code so that it also supports the (yet to be tested) encryption and signing functionality, but will go no further than that. I am not a good Python developer (if you couldn't tell from the code) and it would benefit much more from someone who knows what they are doing in the language. The only reason that I am planning on completing the remaining the functionality is simply because I started it so will see it through.

One question and comment I often get is why I am re-inventing the wheel. There are already libraries out there that do XMLENC and XMLDSIG, so I am just wasting my time with “just another implementation” (that is also not complete I may add). I am specifically referring to the original PHP code for XMLSec, WS-Security, etc.. To these people all I can say is that they are not wrong and I do not disagree. I would love to be spending my time doing something else, but there is something that these people do not quite get. All of these other libraries are C libraries and/or have a good number of other dependencies. Previously to having gotten my own dedicated server, I was in a virtual hosting environment. Anyone working in this type of environment knows that it is not easy and many times impossible to get a hosting provider to install libraries outside of their base supported development packages. Another issue is that these technologies are difficult to work with. Even using the libraries, a developer still needs to know a lot about how the stuff works. To make these technologies available to a greater number of people, I decided to see how much I could write in PHP code using commonly available packages. The goal was also to make working with the code extremely easy; which means that not everything is supported, but from the feedback I have gotten so far, it has provided at least 95% of the functionality needed by the developers using it. This doesn't mean there won't be a C library for at least PHP. It has been in the works for quite some time, and is close to an initial release. The only caveat is that it will be relying on a yet-to-be released version of The XML Security Library.

Friday, February 16. 2007

It has taken me quite some time to come to grips with OpenID. Why? Because I trust no one. When I first started playing around in the Identity arena, I thought it was a great step forward in protecting my identity. Minimal, and only information I allow, is released to the requesting party. The requesting party has no need (and should not unless absolutely necessary; after informing me they are doing so) to store any of the information provided with my identity. This doesn't mean though that they can't store other information to make my experience at their site better.

Take your favorite on-line store for example. It eventually should be possible to login into their system using your identity (leaving it vague right now what type) and maybe have a profile they store that's tied to your identity so that they can tailor their site to you, say promoting only products in categories you are interested in, like computer gadgets rather than dishwashers. This all sounds great, so what's my problem?

I am paranoid when dealing with companies involved with marketing. I typically would be browsing their system through anonymous proxies and be using site specific email addresses if I need to register. In most case I browse on-line stores to compare products, product reviews and prices and only shop at a handful of stores I actually trust. So to get the personal integration on all these sites, I would either be using my OpenID or an InfoCard to logon. The difference between these two technologies is where I start having some issues with OpenID.

Thursday, February 8. 2007

While playing around with the identity technologies, I decided to get myself an i_name and give it a spin. I am =Rob.Richards (or using my i-number: =!4015.A5A3.AE2A.54B9). An i-name is similar to a domain name. Just like my website is identified by my domain name, I can be identified by my i-name. In the event i-names catch on, I figured it was a good idea to get the one I wanted now rather than take my chances later. Do you know how many people right now confuse me with this Rob Richards? Just so we are clear - that is NOT me .

You might notice that I am using the xri.net url for my i-name, though when you access it, it resolves to 2idi.com. 2idi is the broker where I got my i-name. It is perfectly valid to use their urls when resolving my identity, but by using xri.net, I could move my i-name to another broker down the line and have no need to change any of my contact links. Due to having to resolve the address to my broker, it is a little slower doing it this way, but at least I wont have to change anything down the line if I change brokers.