- From: Tab Atkins Jr. <notifications@github.com>
- Date: Tue, 16 Aug 2016 16:22:20 -0700
- To: w3c/webpayments-method-identifiers <webpayments-method-identifiers@noreply.github.com>
- Message-ID: <w3c/webpayments-method-identifiers/issues/9/240269489@github.com>
> The payment app registers with the browser, saying "I can support the payment methods x, y, and z" (where x, y, and z are the payment method identifiers we're currently discussing). Ah, I see. It looks like y'all are indirecting thru the "request_url" - an app somehow informs the OS that it will POST payment information to a particular url, and then a website comes along and says "hey, the app that can post to this `request_url` should be associated with this `payment_app_id`, and then *another* website comes along and says "hey, boot up the app that's been connected to this `payment_app_id` and let me know when it's finished". Is this right? If so, is there a reason it's so... roundabout? Is the request_url information somehow already being collected/advertised by apps, such that it's "free" to learn about? If so, why not just use *that* directly as the identifier? Or is the request_url *also* something that an app needs to explicitly tell the OS about via some new communication channel? If so, why not just instead let the app provide an identification token? Or use some other quality of the app that's unique, like the origin it claims to be associated with? It seems like that would allow skipping the "visit webpage so it can register a payment method" step entirely (unless the webpage is registering a SW as a payment method, of course, rather than an app providing that functionality). Apologies if these questions seem basic, but I'm puzzling my way thru several layers of indirection here, and I get the (possibly unfounded) feeling that much of it is unnecessary, and just accidentally accreted as people stumbled towards distributed extensibility. > (in the context of getUserMedia() constraints) I'm not seeing anything like that in gUM; was it thrown out entirely because of such problems? In any case, there's not a ton of precedent here. *If* it ends up being useful to produce a centralized registry of payment methods, it's easy enough to explore the option, rather than assume that it won't work. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/w3c/webpayments-method-identifiers/issues/9#issuecomment-240269489
Received on Tuesday, 16 August 2016 23:22:50 UTC