What mechanisms (if any) do we need to prevent data tampering?

[ianbjacobs]

@mattsaxon wrote: "How do we ensure that fields are not tampered with (e.g., malicious changes to the beneficiary)?. Similarly, it is important that the payeeName not be changed by the payer or the payment app in order to be sure that automatic controls at the payee’s bank will work. "

[CYV]

I aggree these are two important issues : nor the "payeeAccountNumber" nor the "payeeName" should be tampered (this is a major fraud scenario).
Could we imagine to sign those two fielsd with the merchant (payee) https key: controls could be made by payment app and also by the payerbank.

[mattsaxon]

Why don't we sign the whole response or indeed encrypt it to prevent tracking? I'd suggest we provide the key in the requestData as the payment app may not have easy access to the merchants public key in the https very if it is 3rd party.

[CYV]

I aggree, it seems better to put the public key in the request data. Actually, this key must be a certificate in order to be controlled independently. (doing this, arn't we recreating SCAI by the way ;-)

ok to mention that the message (with IBAN) could be signed either by merchant or third party.

nevertheless, I suggest we sign only and let the encryption for the https.

[ianbjacobs]

One thing we have been talking about in the tokenization task force is to pass a URL that identifies a public key. The payment app (which could be the browser) fetches the key and does the encryption.
Thoughts?

I will keep you posted of other ideas about encrypting data from the tokenization task force.

Ian

[mattsaxon]

So for Payer/Payee-Credit-Transfer we propose to sign the request only. There is no signature of encryption needed on the response.

For PISP-credit-transfer there is no requirement for signature or encryption.

Can we get consensus to that choice?

• Cyril
• Vincent
• Ian

[cyberphone]

@mattsaxon

For PISP-credit-transfer there is no requirement for signature or encryption.

All PISP APIs define their own security mechanisms.

[mattsaxon]

@cyberphone, watch this space for a proposal on signature or encryption. My view is that it should be optional for PISP-credit-transfer, do you believe it should be mandatory? If so, can you provide an explanation?

[cyberphone]

@mattsaxon I would start in another end by defining the possible purpose (and consumer) of a security solution.

Although message encryption may be cool, it introduces key distribution issues which must be addressed from the very beginning. Saturn (my "brainchild"), encrypts Authorization Data, Card Numbers, and Private Messages using three entirely different (but for the use case optimized), key distribution methods. They are all worth a study IMO. The encryption schemes work as follows:

• Authorization Data objects are encrypted by Issuer-specific public keys of the associated payment credential deployed in the Wallet during credential enrollment
• Card Numbers are encrypted by public keys retrieved through lookup of the Acquirer. The same concept but targeting the Merchant Bank is used for encrypting Payer Account Data needed for supporting convenient refunding of CT payments
• Private Messages (including Risk Based Authentication requests) returned from the Payer's Bank to the Payer through the payment back-end are encrypted by symmetric keys created by the Wallet and supplied in [encrypted] Authorization Data objects

[cyberphone]

Since your system doesn't build on an end-2-end security scheme, there are probably huge limitations to what you can add in terms of signatures and encryption.

[cyberphone]

@CYV @mattsaxon Signatures is a generally difficult (to agree on) issue. The Financial API folks rejected the signature solution used by the Berlin Group as well as STET. See 9/G:
http://lists.openid.net/pipermail/openid-specs-fapi/attachments/20171115/86bf05d0/attachment-0001.pdf
"It is just an individual IETF draft that any person can come up at any day"

http://lists.openid.net/pipermail/openid-specs-fapi/2017-November/000629.html
"http request signing is impossible"

The root of problem is that there is no standard for signing REST requests. My solution to that was simply dumping REST which was an easy one since WebSocket is way more powerful for "Wallets"