As Inland Revenue, Microsoft and developer EDS all sought to play down the furore over the Windows-only nature of IRD's new ir-File electronic filing system this week, one question loomed above all others - how on earth did it get this far?
IRD was carrying documentation on Macintosh support on its Web site little more than a week before launch - yet the system was never going to work on anything other than a Windows platform.
EDS was declining comment last week, and did not repeat the explanation it reportedly gave to Apple New Zealand Solutions manager Richard Stevens - that Microsoft's product documentation for Internet Explorer was incorrect. Microsoft was defending is documentation and rejecting any comparison with antitrust issues.
The chief development issue appears to have been the extremely rigorous requirements stipulated by IRD when it commissioned the project, which went beyond conventional e-commerce requirements.
Both IE and Netscape Navigator and Communicator support SSL (Secure Sockets Layer) 3.0 on all platforms. But neither fully supports one SSL 3.0 option demanded by IRD - client-side digital certificates.
IRD, for its part, claims to have demanded three basic requirements for the system – Data security, certification of users and protection for both parties in any dispute.
“Inland Revenue originally asked for a universal solution that would support all computers, but the research indicated that of the employers that had computers, 99% had PCs and 1% had Macs,” says an IRD media release sent out on March 17.
“Unfortunately we could not find a solution using present technology. Various companies are working on a solution and as soon as one is available Inland Revenue will use it to support Mac users,” says the release.
To achieve non-repudiation, IRD wants the payroll files sent to its back-end server by the 12,000-odd large major taxpayers required to use ir-File to be signed with a digital certificate at the client end. It acknowledges such files with a receipt signed with a certificate held on its own server.
Although the system uses Web browsers at the client end, they are really only tasked with maintaining a secure connection with the IRD server. Netscape browsers have a certificate store that allows import and export of certificates, but not their opening and use for signing other documents and in itself, IE doesn't support client-side certificates at all.
So EDS created a separate application - an ActiveX control - to take the client-side certificate and use it sign documents. It is that application that has access to the Windows Cryptography API (CAPI), a part of the OS that includes its own document store. (Interestingly, Microsoft is saying that the OS and the browser are not the same thing.)
The workaround for Netscape browsers requires a plug-in to allow them to recognise the ActiveX control. Also, a copy of a certificate can be exported from the browser's store and also stored in the OS, where it can be used by the ActiveX control.
Because CAPI only exists in Windows, the IRD/EDS solution won't work on any other OS - or at least any one which doesn't have a similar set of APIs exposed to the browser or any other application.
These may be available in some third-party applications, but only Microsoft has been able to win from US authorities a blanket 128-bit crypto export license (for Exchange Server, Server gated Crypto and IE) for supply to NZ government entities.
In the near future, Apple may license or create such APIs, Microsoft could port CAPI to the MacOS along with IE 5.0, or Netscape could expand its client-side certificate services on non-Windows platforms. But at the time of development, there was never any way that the Web-based solution would work with anything other than Windows. Again, why didn't anybody notice?