I'd like to report otherwise, but this Websphere token decoding is proving a mite more challenging than I had first expected. The kicker is in the trailer.
The way the Domino Ltpa token works is by hashing the first part of the token (one-way MD5 fingerprint) into a chunk of bytes. These bytes are the appended to the token a little like a tamper proof seal. If you change any of the first part (name, expiry date, creation date) then the finger print hash will not match and the token is therefore invalid. Quite clever really.
I believe the trailer on the websphere token works in the same way, but it's not a one-way MD5 hash. I think it's either public key encrypted or signed. Trouble is we're having a real struggle with the RSA data. There is a field on the Domino configuration doc called WS_RSAData, but RSA is a public/private key PAIR. Here we have only one field. To make matters worse, it's 259 bytes long. 2 * 128 != 259.
Next step was to try to decode the websphere export file directly to reveal the public and private keys (since they are in the file seperately). Again unfortunately, it would appear that you need some salt to reverse the password based encryption. Salt is 8 bytes of "random" data to make guessing the password difficult. To decrypt you need to know: the password, the salt and how many iterations were used to encrypt. This means a brute force attack take so long that it's not worth it.
Back to the drawing board. Unless some kind soul who knows a ton about encryption has some clues....