- From: Manu Sporny <msporny@digitalbazaar.com>
- Date: Sun, 19 Jun 2016 20:56:07 -0400
- To: public-payments-wg@w3.org
Hey Kris, This is a response to your change requests to the HTTP API specification. On 05/03/2016 01:25 PM, KETELS Kris wrote: > *Web Payment HTTP API* > > /Payment Flow Overview/ > > 1) The roles mentioned do not correspond with the names in the > swimlanes. Can we use consistent (ISO 20022?) terminology? I have refactored the diagram using the names defined in the Web Payments Architecture proposal. The new image can be found here: https://w3c.github.io/webpayments-http-api/#payment-flow-overview Commits are here: https://github.com/w3c/webpayments-http-api/commit/7d931f2eb8a6dd6ebd5fc0f1bfeab76d1953f217 https://github.com/w3c/webpayments-http-api/commit/56f6a34a91fa99eead70d5f65d2c6f3f3b9f9f60 > 2) “The payee provides a URL where a payment request for the > resource can be fetched” > > In a RESTful design, I would imagine the resource is the payment > instruction (with at this stage contains only the information owned > by the merchant, and lacking the info that the client still has to > add. The client would then use a PUT to complete the payment > instruction). The design you're proposing assumes that payment instructions get a permanent resource identifier on the Web. It's an interesting proposal. I'm going to push back on it a bit and see what your responses are: The upside here is that every single payment instruction ever gets its own identifier. That's great for global identification of payment instructions (and auditing). The downside here is that Web Payments systems must now start locally tracking every single payment instruction they create, and this could be used as a denial of service attack vector against services (think IoT devices and other low-memory footprint devices). It may be true that systems need to do this anyway, but I can think about ways around this via some trivial cryptographic tricks (short lived cryptographic bearer payment instructions, for example). You are also assuming symmetry between the PaymentInstruction that goes out and the PaymentResponse that comes back. There is currently no symmetry between those messages in the Browser API spec and I'm hesitant to assume that will be the case in the future. Payment requests and payment responses may look very different from each other and that's problematic w/ a PUT. Typically, the resource you're PUT'ing should be a new version of what you GET, but in this particular case, based on where the Browser API is going, it won't be. Looking forward to your thoughts on this. > 3) See also my comment in the Core Components: would it not be > better to specify all resources there (e.g.. The payment instruction > with all its properties such as the payment method) as this > structure (or part of it) will be the basis for any exchange between > any of the participants defined in the swim lanes). Agreed, that's the goal. > This payment instruction is in a first stage partially completed by > the merchant, and in the second step the customer completes the > payment instruction and posts the payment to the PSP? Yes, also correct. That's what the current flow is. I think you think the flow is different from this... why? > 4) Putting my ISO hat on ;) : The resource (ie. The payment > instruction) can then be defined using ISO 20022 components. If they > do not exist in ISO, we will submit them. That would be great! Let me know what you think of the above. I think we're aligned, but I may be missing something. -- manu -- Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny) Founder/CEO - Digital Bazaar, Inc. blog: The Web Browser API Incubation Anti-Pattern http://manu.sporny.org/2016/browser-api-incubation-antipattern/
Received on Monday, 20 June 2016 00:56:33 UTC