Comments (13)
There are at least two ways to accomplish this:
- Create an independent channel between the merchant and customer payment processor to send the payment request over.
- Digitally sign the payment request.
I suggest that #2 is more flexible in the long run as the payment request could travel through a variety of communication channels that we can't imagine today. For example, HTTP -> NFC -> Bluetooth -> HTTPS.
from webpayments.
Some elements in the payment response may need to be hidden from the merchant also (e.g. card number), so signatures don't meet this requirement. Since we are creating other connection from the browser, e.g. to cloud payment instruments, couldn't the connection to the PSP be via the same means? My view is we may need to support both methods.
from webpayments.
I may be rude, but the SCAI approach was:
- to avoid any tampering of the data by digital signing
- to enable some data could be hidden from the merchant (or from any other actor) (tunnelling)
regards
from webpayments.
Cyril is referring to this proposal:
https://www.w3.org/Payments/IG/wiki/Main_Page/ProposalsQ42015/SCAI
from webpayments.
Some elements in the payment response may need to be hidden from the merchant also (e.g. card number), so signatures don't meet this requirement.
I'm wondering if you're raising another important issue.
This particular thread is about how you can trust a particular payment message.
I think what you're talking about could be broken into two sub-issues:
- How can you obfuscate information in a payment message (encryption), and
- What do you do with data that a PSP should not see (such as receipt information intended for a customer), or data that a merchant shouldn't see (such as a card number)?
Care to split it out into a different issue, @mattsaxon?
Since we are creating other connection from the browser, e.g. to cloud payment instruments, couldn't the connection to the PSP be via the same means? My view is we may need to support both methods.
For things like the PAN, I think the PSP would just drop that on the floor and not include it in the payment response message.
You do raise another interesting point, though. For example, when we get to digital receipts, how is that handled? The merchant could:
- Provide a digital receipt at the point of the payment request
- The pop-up takes over (keeping the merchant channel open), splits the digital receipt out (storing it temporarily), sends the payment request (sans receipt) onto the payment processor channel
- The payment processor responds with a success via the payment processor channel
- The pop-up opens a receipt storage channel to the customer's receipt storage location w/ the receipt and proof of success
- The pop-up then relays the proof of success via the merchant channel back to the merchant.
In this example, the pop-up has 3 channels open:
- merchant channel
- receipt storage channel
- payment processor channel
To be clear, I don't think this is what we should do - receipts would most likely be best handled as after-the-fact storage decisions. I can't think of a realistic use case where we'd need to open more than two channels, but I can certainly conjure up edge-case ULTRA SECURE payment instruments that require you to piece together data from different servers at different data centers around the world.
Just food for thought - we may need to open more than 2 channels in the payment selection pop-up/message relay component (aka wallet).
from webpayments.
the SCAI approach was:
- to avoid any tampering of the data by digital signing
- to enable some data could be hidden from the merchant (or from any other actor) (tunnelling)
Yes, but I expect that not everyone feels that digital signatures are absolutely necessary and there may be others that don't believe that in-message encryption is necessary.
I'm merely raising the point that both will most likely be necessary, if not for phase I, for later phases and we should keep this in mind as we do the design work.
from webpayments.
Merchants sometimes do want to see card number though. It might not be best
practice but it is certainly allowed today and supported.
Nick Telford-Reed
e: [email protected]
m: +447538177619
On 3 Dec 2015 3:32 a.m., "Manu Sporny" [email protected] wrote:
the SCAI approach was:
- to avoid any tampering of the data by digital signing
- to enable some data could be hidden from the merchant (or from any
other actor) (tunnelling)Yes, but I expect that not everyone feels that digital signatures are
absolutely necessary and there may be others that don't believe that
in-message encryption is necessary.I'm merely raising the point that both will most likely be necessary, if
not for phase I, for later phases and we should keep this in mind as we do
the design work.—
Reply to this email directly or view it on GitHub
#19 (comment).
from webpayments.
Care to split it out into a different issue, @mattsaxon?
We perhaps don't need a separate issue at this stage, the flows I am referring to are covered by the documented flows from the task force.
from webpayments.
I agree with @msporny that there are two issues here.
- How do we ensure that the payment request from the merchant is not tampered with before it gets to the payment app.
- How do we protect certian data in the messages from certain parties in the flow as the use case requires.
I think issue 2 is a problem for the designers of payment methods to solves ASSUMING we have solved issue 1.
The payment request from the website to the payment mediator (User Agent) and then to the payment app needs to be tamper-proof. Only then can the payment methods specific processing kick-in and implement whatever security mechanisms the payment method prescribes.
Is it sufficient to say that the API calls are only made in a secure context?
What happens if my UA has been compromised and whenever I get a payment request the merchant details are changed so my payment goes to the wrong person?
Do we need a standardized way to sign the payment request?
from webpayments.
As mentioned on a separate thread, I think W3C WebCrypto [1] is relevant here but I don't know whether it meets all our needs. As the spec is fleshed out we'll know more.
@adrianhopebailie asked:
"What happens if my UA has been compromised and whenever I get a payment request the merchant details are changed so my payment goes to the wrong person?"
It seems to me that, like other topics, Web apps and payment apps can determine the degree of security they wish to guarantee. Some apps will use signatures, I assume, and perhaps they will distinguish themselves in the market by doing so. We make it easier to do through the WebCrypto API.
Thus, in the spec we can call this as a "Security Consideration".
Ian
[1] http://www.w3.org/TR/WebCryptoAPI/
from webpayments.
As long as you imagine the person being payed is a merchant, as opposed to say a friend, then they do not need cryptographic deniability, so signatures work in principle. I suppose the question can be more clearly phrased as, how does the payment applicaiton get the merchant's key material, no?
Apologies if this is dealt with elsewhere, but does the standard address how should one deal with signing JSON data? It's obviously possible to construct a canonical JSON representation, as a string and sign it, but that proves tricky in practice. We wound up signing C structs encoded with C code compiled to JavaScript using emscripten, which although hacky at least always works correctly.
from webpayments.
Apologies if this is dealt with elsewhere, but does the standard address how should one deal with signing JSON data?
There's work in this area: JWS, a proposed standard at the IETF, and Linked Data Signatures, work from the Web Payments and Credentials CGs at W3C.
from webpayments.
Migrated to w3c/payment-request#41
from webpayments.
Related Issues (20)
- [Payment apps] How can we optimize user experience when there is only one match? HOT 1
- Pull filters out of payment method data HOT 2
- Overview document figure 5 HOT 13
- Propose a payment method specification that includes an example of field level security HOT 1
- propose to add encoding attribute to data set HOT 18
- European market - Security concerns HOT 10
- [Tokenized Card Payment] Replace usage of 'last4' with 'suffix' HOT 8
- [Tokenized Card Payment] TokenCardRequest should inherit from BasicCardRequest HOT 3
- 3D secure support HOT 4
- Sepamail WebIDL syntax and algorithms HOT 4
- Payment Method Manifest spec - should enable country specific app discovery HOT 9
- Fingerprint and version metadata (in Web App Manifest spec) HOT 36
- Should the WPWG develop a cryptocurrency payment method specification HOT 14
- Adopt a "test as you commit" policy HOT 10
- Just a question, curious HOT 1
- Visual Identity for Web Payments HOT 14
- Specify both pickup and delivery addresses in a single payment request HOT 2
- QR use cases HOT 5
- Proposal to restore charter text around UI being out of scope HOT 10
- Pagos alex
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from webpayments.