I’ve just been hit by the most incredible rain storm. I’m sure it will be gone in the next half hour. I’m writing mainly because it’s the first rain I’ve seen in close to two months. Secondly it’s really hard. The Car Alarms are going off because of it and the road has turned into a river in less than 5 minutes.
So forgive me if I’m a bit excited. All of Panama is preparing it self. Carnival starts tonight with the Coronation of the Carnival Queen. After that it is 5 days and nights of non stop partying in the City.
While I can normally keep up with the best of them, I’m not entirely sure I can handle 120 hours of straight Seco (White Cane Spirit), Ron Carta Vieja (My favorite) and dancing to the latest Reggae, Soca and Merengue.
This will be my first carnival here and I will definitely chill out and not get too in to the spirit, if for nothing else for monetary reasons.
The main center of the Carnival in the city is the very long and very wide Via España, whch is less than 5 minutes walk from my apartment. I’ve been promised that I wont be able to sleep anyway do to the 24 hour music going on that close.
So what is it supposed to be like. I have no idea except that I know I will be soaked in water nonstop, have confetti thrown in my eyes and probably forced to down much rum.
The party kit here consists basically of T-shirts and shorts as well as various kind of excercise bottles converted to rum duty.
Many people outside of Latin America doesnt know this but Reggae is virtually the national music of Panama. It’s all in Spanish and a bit different than Jamaican reggae. Fortunately just like Jamaican Dancehall it’s got a kickin base that gets everybody moving.
The other big music is Soca (just like in Trinidad, but in Spanish) which is always excellent for dancing and Merengue. Merengue is often mixed with Reggae and Hip Hop, such as the latest big hit out of Dominican Republic or Puerto Rico thats called Kulikitaka. This song is so infective that I know I’m going to be singing it my head way past getting tired of it.
I’ll attempt to bring my camera and take pictures. Assuming it doesn’t get too wet.
IBM’s DeveloperWorks have a neat little article entitled Web services security, Part 1
The security methods discussed provide simple, but effective, solutions to secure your Web services transactions over HTTP. However, a word of caution. As the complexity of Web services transactions increases, these methods may become unsuitable. Consider, for example, that the methods discussed above would be unsuitable if the same SOAP messages were exchanged using SMTP (Simple Mail Transfer Protocol). Similarly, the solutions presented above might not be applicable if there were legitimate intermediaries present. In order to address these issues, a comprehensive WS-Security specification is being developed and standardized. The second article in this series will introduce the WS-Security specification and provide a detailed account of how it can be used to take the security of your Web services applications to the next level.
It mainly covers http basic authentication and https. Which are both simple, but it’s a pretty good little article. The next one covering WS-Security promises to be more interesting.
My own SOAP implementation that is currently part of XMLSignatures for Dom4J should theoretically be able to handle HTTPS. I‘m guessing adding Basic Authentication shouldnt be to hard. What I do need to look at is adding XMLSignature WS-Security support to it. It already supports most everything needed for it. Maybe in the next rev.
Tim Jones the former Head of Retail banking of NatWest and one of the guys behind MasterCards Mondex electronic cash system as been appointed head of the new Mobile Payment consortium from Orange, Vodafone, Telefonica and T-Mobile.
What does this mean? I’m glad they’ve got some one with experience in the field heading this. He comes from a payment background and not a comunications background.
Russel as usual has a great article about payment options for mobile commerce.
He links the obvious ones, but also some of the less obvious but defacto systems such as Handango.
A day or so ago, I posted about the success of DoCoMo’s iMode and how the content providers were making money. Well, the reason they’re making money is because iMode provided a way for them to get paid right from the start. This in my opinion is what’s lacking right now in the Western world and why this new group is so interesting. Without a standard, your ability to attract paying customers is limited.
I was always fascinated with the DoCoMo model. Super simple yet impossible to integrate into the GSM model. Which brings me to one of the reasons that DoCoMo was so successful in this department and at least the first few iterations of Mobile Internet on GSM werent.
DoCoMo came in with a software company mentality. They didn’t create any revolutionary new standards, as a matter a fact since they started trying to do new stuff they’ve not been doing to well.
GSM was designed by comitte. It was designed by Telecoms Standards engineers, which is not necessarily a bad thing. I mean GSM works and it works well. However they never tried to think of it as being anything but a telecommunications standard. Where DoCoMo where thinking as a Software Platform, the GSM Engineers were thinking, we need to communicate and charge per minute like we’ve always done.
Now the 4 largest carriers are planning a system that can be billed to the users mobile phones. I think its a great idea. We’ll see if they can work it out.
I’m guessing once all the phones have Java VM’s and gprs we will see some interesting new payment systems.
My old Pals at E-Gold have had a wap based interface to their payment system for years, which at least used to work quite well.
One of my future plans for NeuClear is either a book entry payment system using Digital Signatures or a Digital Cash wallet using Lucrative or similar all based on Mobile Java.
[February 24th, 2003] New Release with much improved Interop. Some major problems were found here which have been fixed. Please upgrade to this version to allow compatibility with other XMLSignature implementations.
Currently it supports the following:
- Enveloped Signatures
- Enveloping Signatures
- Detached Signatures
- RSA-SHA1 Signatures
- DSA-SHA1 Signatures
- Base64 Encoding
- SHA1 Digests
- Canonical XML
- Canonical XML With Comments
- RSAKeyValue
- DSAKeyValue
- Support for arbitrary Transforms in the Reference tag
- XPath Transforms (Already written but not integrated)
- HMAC-SHA1 MAC
- X509Data
Our next release 0.9 will hopefully have support for all of the remainding features above. Once we are satisfied that they all interop perfectly we will release 1.0 which should be relatively stable, both API wise and code wise.
Ramsés Morales has been helping me out on the XMLSig library. He has contributed several sections regarding DSA support.
In CVS we now have support for DSA KeyInfo Elements as well as SHA1-DSA
What we are doing right now is setting up a proper infrastructure for interop testing with other implementations. The main thing we need for this is Enveloping signatures as well as X509Data elements.
When this is done and we’re moderately happy that we support most features we will release v1.0, we will probably release a 0.8 version before then to allow other people to test it.
While on SlashDot I caught this article about Overture to buy AltaVista. I used to work there back in 1996 as their web master and have followed the whole sordid affair since then. (Any other old Altered Vista employees out there????)
I was brought in during the time that Digital Equpiment Corp. (Now Compaq oops HP) wanted to capitalize on it’s accidental success with the original Alta Vista search service. Digital who as usual were doing poorly tried to group all it’s networking related products under the Alta Vista brand and it spin it off as a seperate company.
I guess it made sense with all the early internet frenzy. But the end result was an operation much like Dilbert in everyway. The Digital culture was traditionally Engineering led. However the management of Alta Vista was very marketing oriented. I was stuck as the main engineer in the Marketing Department and was constantly caught in cross fire between the two departments.
How about when we were getting ready to release the first version of our AltaVista Personal Search edition. For searching your hard disk and email. The development team were a bunch of class A guys out in Australia. Who received their 4 weeks notice 2 weeks before the release deadline of the product. Hmm.
There was also the near religious fervor about the quality of the AltaVista search engine. I used to quietly mention that Excite turned up more relevant results. But this was always laughed at. The true secret behind the search engine was the TurboLaser the AlphaServer 8400. When I left we had I think 12 machines with each 10 cpu’s in production and 2 waiting to be thrown in if the average query time was more than 2 seconds.
I did get to work with some cool people such as Jim Gettys, Dan Kalikow and Richard Seltzer.
Many of the projects I worked on were fun as well. I did everything from perl to tcl, to Oracle to ISAPI. And I got my first real exposure to real corporate internet security. I believe Digital was one of the first companies to have such a strategy inplace.
I guess it’s Payment Systems day here on Talk.org today. Just noticed the article on SlashDot about PepperCoin
PepperCoin has been around for a few months now (as a company that is), but it’s an interesting new approach to micropayments. Ron Rivest (The “R” in RSA) has always been good at thinking out of the box.
The basic idea from what I can remember is that lets say you want to buy something for one cent on a web site. Your 1 cent payment is grouped together with say 200 others to make a 2$ payment. The system chooses one of the payees in random an this person pays 2$. Thus lowering the transaction costs througout. If you use the system a lot you will end up on average paying the amount that you have purchased for. The key to PepperCoin is whatever clever way using probaility Rivest has thought up to make it fair for all users.
Transaction costs have always been the problem with Micro Payments. Rivest’s idea is definitely unique. It does sound familiar to something he might have presented at one point at a Financial Cryptography conference. (We are BTW trying to get the next one to come here to Panama)
The Financial Crypto community has been a buzz over the last few days over a new implementation of Digital Cash called Lucrative
Lucrative is a fully fledged implementation of Ben Laurie’s Lucre which is an implementation of David Wagner’s Diffie-Hellman variant of Chaumian blinding.
Chaumian Blinding is described in more detail here in the Cyphernomicon but essentially it is the algorithm that makes anonymous digital cash possible.
Lucre is important as it’s the first implentation of Chaumian blinding that is not thought to be covered by patents. Chaum’s original DigiCash company made him the most hated man in the Financial Crypto community. Allthough I have to say that I thought him a pretty nice guy (business practices aside) when I had breakfast with him at FC98 in Anguilla.
So Lucrative is here. It is a Java implementation which uses SOAP. I‘m trying it out and it seems allright. Patrick has a weblog describing his efforts. The whole thing should definitely be congratulated. I’m going to see if there is any thing we can do to work together. NeuClear would provide an excellent book entry backend for Lucrative.
I guess this is a bit of a meta blog entry, but I’ve just updated to MT 2.62 and also enhanced the layout a bit.
Great news for all Java developers out there. The beta8 version of Maven has finally been released.
If you havent tried maven yet, you really should give it a go. It's an automated build tool, but so much more. It works well for both open source and internal development projects.
I've been using the cvs version for a while now and have been happy with it. I might just stick with this for a while.
You can get your fresh baked mave here
According to Prensa yesterday Dell VP Kip Thomson signed a deal with the Panamanian Government to open an "International Services Center" at the old US Howard Airforce Base.
The deal makes sense for Dell. I'm guessing they are popular throughout the region. They are definitely very popular in Panama. In fact you can buy them in shops here.
Howard AFB is being promoted as the ideal international logistics center and it's quite hard to argue with that. It's huge, has a decent sized landing strip is very close to the Port of Balboa a large container port that is currently being doubled in size. The Port of Balboa is owned by Hutchison Whampoa the large Hong Kong conglomerate. Offering easy shipment of parts from Taiwan and China.
Update: To all the people who have written below concerning Dell positions you should go to PanamaJobs.com and click on the Dell banner. I am in no way affiliated with Dell and posting your CV here will have no wanted effect for you.
Just to get some sizing idea's for NeuClear based financial applications. I decided to play with some quick benchmarks for my XMLSig library for dom4j.
I ran the tests very unscientifically within the IDE (IntelliJ IDEA of course) on my 700MHz linux P3 notebook with 512M of ram. My email and everything else was running in the back ground.
The tests them selves consisted of 1000 iterations of xml parsing and signing.
Followed by 1000 iterations of xml parsing and verification.
I got the following results per iteration:
| Signing phase | 270ms |
| Verifying phase | 18ms |
My comments on this is that this is absolutely usable in large scale applications. In the NeuClear Model every transaction is verified by the transaction processing server. The server it self, in many instances doesnt have to actually sign anything. Signing takes place on client machine's, where the 270ms wont be a big deal.
The Benchmark Code itself can be found here.
New Release of my implementation of XML Signatures for Dom4J with much improved support for the W3CCanonical XML standard. It also includes a set of testcases to prove it. This brings us a lot closer to full XMLSig Interop.
Currently it supports the following:
- Enveloped Signatures
- Detached Signatures
- RSA-SHA1 Signatures
- Base64 Encoding
- SHA1 Digests
- Canonical XML
- Canonical XML With Comments
- RSAKeyValue
Missing but coming soon are:
- Enveloping Signatures
- Support for arbitrary Transforms in the Reference tag
- XPath Transforms (Already written but not integrated)
- DSA-SHA1 Signatures
- HMAC-SHA1 MAC
- X509Data
- DSAKeyValue
- PGPData
An other small feature is a simple SOAP Client and Server implementation, which will probably be pulled out into its own project soon.
Ive done a lot of work of getting rid of unnecessary dependencies and improved the installation documentation. In other words it should be considerably easier to use now.
It's been a bit quiet here on the blog for a bit over a week.
Well I've been to Boston, London and back.
I have been doing a lot of coding. It's amazing how productive you can get when you're bored in an airport.
My NeuDist XML Sig library is coming along strongly. I'm trying to get it fully standards compliant. The CVS version should be pretty much compiant now. In particular for the area's that I'm using in NeuDist. There are still a few small changes that have to be done before I release 0.7.
The Canonicalizer has been rewritten from scratch and besides a few very small points passes all the standard compliance tests.
I'm in the middle of implementing a bunch of things for handling just about anything you can throw at the XMLSig part of the library. This includes a Transform library and many other things.
Besides this I also have a new Panamanian coder who will be helping me out on some of these things. So I'm quite excited about all.