XSR Verification Process

The http://tyaga.org/ipp/xotaur-sha1-rsa.html (XSR) verification uses a brand's RSA public key to decode a xotaur-serialization of the payment record. A notification is not assumed to have come from an authorized party unless the decoded string matches the expected xotaur serialization. By caching a string that could only have been encrypted by a brand's private key, the Verifier could later challenge repudiation of a payment offer or decision.

The expected serialized representation of a payment record:

  1. Xotaur Serialization: For each payment record, a white-space concatenation of the following IPP parameters is formed into a string:
  2. Xotaur+Status: Based on the IPP code or status of the payment, one of the following status strings is appended to the xotaur string:

The Notifier performs the following steps:

  1. SHA1-RSA Encryption: The sha1 digest of the xotaur+status string is encrypted using the private key of the Notifier brand.
  2. Base64 Encoding: The encrypted string is base64-encoded.
  3. The Notifier includes the base64-encoded, RSA-encrypted SHA1 digest as the "ver_data" value in its IPP payload.

The Verifier performs the following steps:

  1. Public Key Fetch: Unless it already has a cache of the Notifier brand's current public key, the Verifier must fetch the key using the brand's IPP manifest. The manifest value for the "keyCert" parameter must be URI that points to a valid x.509 certificate with an RSA key.
  2. RSA Decryption: The Verifier decrypts the "ver_data" using the Notifier brand's public key. The decrypted string is then base64-decoded. If the decoded-decrypted string is equal to the expected xotaur+status value, then the verification is successful.
  3. The Verifier should cache the encrypted ver_data, which may later be used to challenge repudiation of a payment offer or decision.