Re: Just Released: W3C Web Payments Polyfill and Demo (video)

On 09/07/2017 02:07 AM, Marcos Caceres wrote:
> Be mindful that we should start seeing support for *Payment Request* 
> in all of the above around the same time the polyfill lands. As such,
> be very *really really REALLY* careful not to squat or otherwise
> override any standard behavior. And please please please (please)
> follow the TAG's guidance on Polyfills.
> 
> https://www.w3.org/2001/tag/doc/polyfills/
> 
> The above is critical for *Payment Handler*, which is still super 
> unstable! Please make sure you put that into a completely different 
> namespace (e.g., window.DigitalBazaar.PaymentHandler etc.).

Agreed, and will do. We haven't yet gone back through the TAG polyfill
advice and ensured that we're doing everything listed in the doc (yet),
but we agree that the TAG guidance is a sane way to proceed and will
endeavor to make sure that we stay compliant with that document.

> Ok, but it's absolutely critical that you pass the test suite. If
> any developers start coding against your polyfill, and it doesn't 
> conform, they are going to have a really bad time as real 
> implementations land (as they will break).

Agreed.

> So please be super vigilant with conformance testing. This will be 
> really good for the whole WG, because it will help us verify the
> test suite.

Agreed.

> Please be sure to also steer developers to relying on HTML5 
> autocomplete too (as a fallback)... I imagine whatever pollyfill you 
> produce will rely on HTML5 autocomplete.

Hmm, don't quite understand what you mean here. Do you mean, "make sure
developers fall back on HTML5 autocomplete /for credit card and address
input forms/?

We're fine w/ giving that guidance, but don't really understand if you
mean we should provide the fallback in the polyfill. Like, if the
browser doesn't have IndexedDB support or has cookies/local storage
turned off, then our polyfill can't run, so the best next thing we can
do is inject a a set of HTML5 input fields that are credit card and
address input forms?

> Absolutely - and could provide critical feedback during the CR 
> process! (though it won't count as an implementation for CR 
> unfortunately - but that's ok!)

Why not? If the polyfill is capable of passing the entire test suite
(not saying it'll be able to), and it's deployed to hundreds of millions
of browsers... why can't it count as a CR implementation? If it walks
like a duck and quacks like a duck...

> Tests are your friend. And lots of tests incoming. Would be awesome 
> to have Digital Bazaar use the tests, and also contribute.

We plan to use the tests and see how the polyfill does against the test
suite. There may be parts of the test suite, like the execution of
native apps to perform a payment, that we can't pass because... we can't
make native calls in the polyfill. That is, unless that bit is broken
out of the spec, which may be a good thing to do.

> 🎸 - again, be mindful that Payment Handler will likely change.

Understood.

>> * We'll pick an open license that works for all orgs and 
>> implementers.
> 
> C0! :D

We tried to move fast, which means we used some of Digital Bazaar's IP
on the server-side code (all code is on Github, but the license is
closer to a Community License than an Open Source License). Note that
almost everything is client-side code and that code will be released
under C0 or BSD 3-clause or similar. We can either 1) cut the
server-side IP out and do a complete open source implementation on the
server side (which may take way more development resources than we're
willing to commit) 2) have someone else do #1 (again, time and cost but
for someone other than us), or 3) just provide a license that says
"anyone can use any of our source code royalty and patent free for the
purposes of the web payments polyfill".

We expect choice #3 to be the fastest, easiest, and most economical...
and it will effectively grant the same privileges as an open source license.

>> * There are some issues in Safari that require preference changes 
>> that we're trying to work around.
> 
> Will be interesting to see how you work around the lack of service 
> workers ATM.

The short answer is a polyfill website, iframes, script pre-loading in
the background, and a JSON-RPC-like mechanism. All the source that does
this is available here (lowest level libs first):

https://github.com/digitalbazaar/web-request-mediator/
https://github.com/digitalbazaar/payment-mediator-polyfill/
https://github.com/digitalbazaar/payment-handler-polyfill/

>> * The foundation of the polyfill is, as predicted, almost exactly 
>> the same as the verifiable claims polyfill, which may have 
>> repercussions for how these sorts of APIs are designed at W3C. 
>> We'll produce a report detailing the similarities before W3C TPAC.
> 
> Looking forward to reading it. Particularly if it can better inform: 
> https://www.w3.org/2001/tag/doc/polyfills/

We expect that it may better inform the way we do cross-domain
information sharing on the Web. The first attempts at Web Intents (and
similar data sharing approaches) failed.

Pay particular attention to the way the libraries above are layered. We
are now asserting that there is a generalized way to do payment
request/response and verifiable claim (credential) request/response. The
polyfill could be used by some of the people deploying Social WG stuff
to share social data as well. So, this is kind of another more
generalized attempt at Web Intents but this time building off of a
pattern that the WPWG has established and implemented in the browsers.
In any case, we'll write up where we're going with that part of this
work in a separate blog post or something.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
blog: Rebalancing How the Web is Built
http://manu.sporny.org/2016/rebalancing/

Received on Friday, 8 September 2017 13:52:58 UTC