search

w3c / secure-payment-confirmation

Secure Payment Confirmation (SPC)
https://w3c.github.io/secure-payment-confirmation/
Other
110 stars 39 forks source link

11.3 & 11.4: define the mitigation #143

Closed samuelweiler closed 2 years ago

samuelweiler commented 2 years ago

Can we standardize this mitigation, and is this mitigation sufficient? So rather than "One possible way to defeat this ..." just provide instructions? As in https://github.com/w3c/secure-payment-confirmation/issues/142, the instructions might better fit elsewhere in the doc.

stephenmcgruer commented 2 years ago

This issue is effectively a dupe of https://github.com/w3c/secure-payment-confirmation/issues/77, where this attack is being discussed. The spec should possibly be reworded to make it clear that there is nothing a website (Relying Party or otherwise) can currently do to achieve this mitigation - it is for the spec/user agent to figure out.

samuelweiler commented 2 years ago

Additionally, I would prefer to see a mitigation that does not require the RP/bank to be well-behaved. What mechanism can we use that works even if the RP won't cooperate, e.g. with the salting scheme?

cyberphone commented 2 years ago

W3C Pay - Everything needed is (almost) in place

If you instead of deprecating https://www.w3.org/TR/payment-method-basic-card/ added a credentialId attribute to each card entry and as a final step encrypt generated authorization data, W3C would have the industry's most privacy preserving user payment authorization standard, and with a UX that would be second to none!

Since basic-card is still available in Chrome, the card (payment instrument) database is already in place. Then https://www.w3.org/TR/payment-request/ would finally get the important role it was once designed for. Merchant integration code (with respect to user payment authorization), would be a mere 30-40 lines of JavaScript since no complex and privacy-impeding external communication would be needed for locating and fetching credentialid, logotypes, or account data. That is, all user data required is already featured in the locally registered payment instruments.

After a locally performed payment instrument selection, the core https://www.w3.org/TR/secure-payment-confirmation/ mechanism would kick in: user action to indicate accept followed by cryptogram creation. The latter would though be upgraded with time stamps and payment instrument data like featured in EMV, avoiding the "challenge" data roundtrip.

With yet a minute addition to card entries, the scheme could support any account based payment system which also would be an industry first.

The scheme outlined requires no updates of WebAuthn/FIDO whatsoever since the entire user authorization process runs in a "black box".

stephenmcgruer commented 2 years ago

(Without wanting to re-litigate discussions that have happened over and over, nor get too off-topic in this issue.)

As far as I can tell, the proposed solution by @cyberphone requires no new browser technology. Whilst it is described above on top of basic-card, is there a technical reason that a digital wallet provider that is not the browser could not build such a system?

cyberphone commented 2 years ago

As a developer of Android apps I can attest that you are essentially only limited by your imagination. However, creating globally accepted standards is another story. As we have already seen with the market-wise rejected PaymentHandler, you apparently need a very competitive solution in order to stand a slim chance getting industry traction, even if it runs in Chrome. There were never any "discussions" (see https://github.com/w3c/secure-payment-confirmation/issues/32), there were only my monologs which of course is totally uninteresting. Even for me 😟 The predecessors to RFC 8785 were publicly slammed more than once which of course was quite depressing but I also learnt a lot along the way which made the final solution much better so in retrospect I'm actually thankful 😀 Anyway, what I'm advocating has the same need for new browser technology as SPC since a slightly upgraded SPC is a part of the plot.

stephenmcgruer commented 2 years ago

(Note: this is now 11.3 & 11.4)

ianbjacobs commented 2 years ago

@samuelweiler, there was agreement at today's call that this is a dup of #77 and we can close it in favor of 77. Do you want to remove the privacy-needs-resolution label?

samuelweiler commented 2 years ago

I thought I did that earlier. grumble grumble labels grumble.

ianbjacobs commented 2 years ago

Closed as a duplicate of #77.