search

w3c / secure-payment-confirmation

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

Describe protections against "wrong credential" attack #155

Closed ianbjacobs closed 2 years ago

ianbjacobs commented 2 years ago

New text to cover the attack where a caller intentionally or accidentally calls the API with an instrument string and completely unrelated (but valid) SPC credentials.

Preview | Diff

stephenmcgruer commented 2 years ago

Isn't this just 10.2? (https://w3c.github.io/secure-payment-confirmation/#sctn-security-merchant-data)

ianbjacobs commented 2 years ago

@stephenmcgruer,

It's sort of 10.1 and sort of 10.2. We haven't called out the case of "wrong credentials" yet. If you think this fits better in 10.2 I'm happy to move it there.

stephenmcgruer commented 2 years ago

Hrm, it sort of depends which way you look at it 😂 . I view this as a spoofing attack where you're spoofing the instrument descriptor, whereas you're describing it as a ??? attack where from your view the instrument is valid but the credentials are wrong.

Probably fits in 10.2, as a paragraph after "This could lead to a spoofing attack", saying something like 'the caller may also use the correct details for the transaction but pass a credential that doesn't match what the RP expects'.

There's an undertone of assuming that a credential is for a given payment instrument (or set of instruments) in this PR, and I just want to re-mention that SPC makes no strong statement about payment instruments - to SPC, payment instrument details is just another blob of data as interesting (or not) as e.g. the payeeOrigin. It's entirely up to the RP to decide what they accept for a given credential.

ianbjacobs commented 2 years ago

@stephenmcgruer, let me know if this fix suits you. Thanks!