Additional Thoughts

Further possibilities

Encryption of request

The model described above can be simply extended to allow encryption of request data also as follows;

  {
    supportedMethods: "https://example.com/bobpay",
    data: {
      encryptedData: {...}
      }
    }
  }

The encryptedData would be the data object encrypted using the public key of the Payment Application as specified in its manifest file.

Using in tandem/recursively

The unencrypted data in the envelope could itself be signed and/or have responseEncrpytion specified within it.

Furthermore, these techniques could be embedded to an arbitrary depth. E.g. a signed envelope containing a signed document that specified response encryption. It should be noted that use cases for this level of cryptography have not yet been identified in Web Payments at this point.

Implementation Considerations

1. The representation of the objects to allow for encryption/signing needs further consideration; use JOSE/JWS or JSON-LD Signatures and associated libraries need investigating. It's probably necessary to experiment with some basic implementations to decide on the exact structures.