PSP Encryption Option

[cyberphone]

The current specification is based on that Issuers (or delegates of theirs), decrypt FWP assertions.

There may be scenarios where PSPs would be more suitable performing this step. Suggestion:

Make encryptionKey, contentEncryptionAlgorithm, and keyEncryptionAlgorithm in a credential entry optional.

The following modified sample code shows how this could be accomplished:

const methodData = [{
  supportedMethods: "fido-web-pay/v1",
  data: {
    payee: "Space Shop",  // Shown in the UI
    networks: [{
      name: "https://emvco.com/fwp/mastercard",
      encryption: {                           // New optional element
        encryptionKey: {
                                              // JWK
        },
        contentEncryptionAlgorithm: "...",    // JWE compatible
        keyEncryptionAlgorithm: "..."         // JWE compatible
      }
    },{
      name: "https://emvco.com/fwp/visa"
    },{
      name: "https://europeanpaymentsinitiative.eu/fwp",
      networkData: "additional stuff..."
    }]
  }
}];

That is, the payment method https://emvco.com/fwp/mastercard may use PSP encryption and decryption.

If a selected credential contains the encryption parameters and they are supplied in the associated networks object as well, the credential parameters takes precedence. That is, Issuers always stay in control of the encryption policy.

If neither the selected credential nor the associated networks object contains encryption parameters, an exception MUST be thrown.

In all cases all three parameters MUST either be available or absent, otherwise an exception MUST be thrown.

[cyberphone]

This is probably a rather bad idea, Delegated Authorization can do the same thing and can also control who is actually allowed to decrypt. If the purpose for finding out peoples account numbers is only related to aggregating data, this is not the right way. Loyalty cards is the way to go for managing relations.

[cyberphone]

I think this idea needs more work because the current draft may a bit too static with respect to encryption. The issuer should still be in control. Discovery services may be the right approach although they add some complexity to the client application.

PSP-based encryption should only require merchants supplying a URL which merchants could fetch from the PSP on a daily basis. The client could then cache key URLs so that only when there is a new URL there would be a need to fetch encryption parameters. The encryption parameters would then be:

• Public Key
• Key Id
• Key Encryption Algorithm
• Content Encryption Algorithm

For issuer-based encryption things are slightly more complicated since there is no way to signal that a new key is available. However, it should be sufficient if the client updates this on a periodic basis with low frequency, like once in a week. Maybe an expiration time could be motivated? Note that issuers must be prepared to deal with old keys as well.

A static URL in the credential database would then return encryption parameters like above but a list of supported PSP domains as well. That is, if a PSP-suppled encryption key URL is not in the list of trusted domains, the client must reject the payment request.