Authentication of Bank, Merchant and User/Payment Credential

[cyberphone]

Since this is a payment method, shouldn't it be comparable to other payment methods like Apple Pay?

If that's the case the current proposal is lacking quite a lot, particularly with respect to authentication of the entities involved. Making this an "implementer option" would effectively imply another standardization effort in which the original proposal may be substantially changed or even be ignored.

[adrianhopebailie]

Making this an "implementer option" would effectively imply another standardization effort in which the original proposal may be substantially changed or even be ignored.

Not so. Apple Pay is both a payment method and a scheme. This spec is just a payment method. i.e. It simply standardizes the data model exchanged via the API.

The specifics of how authentication will be down to the scheme

[cyberphone]

Not so. Apple Pay is both a payment method and a scheme. This spec is just a payment method. i.e. It simply standardizes the data model exchanged via the API.

@cyv @adrianhopebailie The line

"How do we ensure that fields are not tampered with (e.g., malicious changes to the beneficiary)?."

from the current draft indicates that even the authors are confused about the scope. This not entirely obvious information belongs to the introduction of a payment method specification.

I still don't see who is going to create the scheme and why they would bother with this specification which BTW introduces lots of information into the "Wallet" (where it IMO doesn't belong).

[ianbjacobs]

Our current expectation is that payment apps will take responsibility for authentication. The specification needs to ensure that payment apps have all the information they need to fulfill the DATA requirements of different payment systems (e.g., ACH, BACS, CHAPS, SEPA). If those systems have additional requirements (e.g., related to how authentication takes place), those requirements would be met by the payment app.

The spec says: "Payment apps are responsible for payer authentication. They may delgate this responsibility to issuing banks or third-party providers."

I am going to close this issue, but if there are more specific requirements for this specification to address, we can open another issue.

[cyberphone]

The specification needs to ensure that payment apps have all the information they need to fulfill the DATA requirements of different payment systems (e.g., ACH, BACS, CHAPS, SEPA)

This does not match existing Web payment systems and IMO for very good reasons.

[cyberphone]

You might be interested knowing that the system described on https://cyberphone.github.io/doc/saturn/saturn-v3-presentation.pdf#page=2 probably can do all the payment methods listed above (and several other as well), without dragging in a single payment method specific keyword (except for the type ID of course), into the payment app.

That is, it is first in step 4, payment method specific data is introduced which potentially makes the "Wallet" fully universal.

The full sequence using a fictitious SEPA payment method: https://cyberphone.github.io/doc/saturn/bank2bank-payment.html

[mattsaxonwp]

@cyberphone, can you elaborate on your "very good reasons" please?

[cyberphone]

@cyberphone, can you elaborate on your "very good reasons" please?

@mattsaxonwp The short answer is that "checkout" is user authorization of payment requests which motivates keeping payment specifics in the background (=outside of the client), which I guess is the most common solution except in the [rare] case payment specifics have direct impact on the user experience.