Web Commerce Interest Group

* Augmented reality, virtual reality

scribe: to create a personalized shopping experience
... lots of booths had big goggles
... they think that goggles will need to shrink in size for the thing to take off
... one thing they envision would be for the user to be able to express filters, and the virtual reality would filter out what you don't want to see
... some applications like virtually trying clothes on

ltoth: Another theme was "smart" wearables
... fitness trackers, smart shoes
... there was a saddle for a horse that was connected. Anything "smart' you can think of
... some appliances now talking to one another like following a recipe triggers oven to heat up
... smart cities big
... store fronts was another popular, newer technology
... you could personalize the store front based on who was standing in front of it
... Product tags also big
... 5G was a big theme
... HTML5 was prevalent
... a lot of robots for education, elder care, medical
... for delivery devices, there was a whole section on drones and self-driving segways
... similarly, autonomous cars for delivery
... The US Post Office was there...curious why...
... Something I saw that was cool was laundroid....folds clothes for you
... Our experiences in the US tend to be product-based...there are recommended associated products (e.g., buy paint, pointed at paint brushes) ... but an interesting thing I was was being connected to other experiences, not just products

<Zakim> manu, you wanted to ask about payments use cases... feels like many of these new concepts have a payments aspect that doesn't necessarily go through the browser.

manu: A number of these experiences would have payments built into them, for example (e.g., upon delivery, etc.)
... did you have any discussions with anyone about how they are planning to process payments? Are these more like IOT devices? Are they running browsers?

ltoth: Ran the gamut. I was surprised that some wearables did not support payments
... in terms of the other devices, it's all over the board
... a lot of the IOT connected devices; some of them have browsers
... I didn't see a particular pattern emerge

dezell: Seems good if robots are not storing payments information
... I'm interested in some of the large topics like education and elder care

ltoth: There was a whole section on robots..I thought it was diverse (e.g., underwater excavation to urgent medical care)
... it's a bit like the Jetsons still
... one robot was playing ping pong against a human

<manu> Ian: You mentioned HTML on the display, can you say more about where HTMl5 was on display?

ltoth: People were using HTML5 in their products
... people were advertising HTML5 in their products

magda: How was HTML5 integrated?

Linda: I have to go...let's follow up.

dezell: I will chat with Linda to find out more about HTML5

Apple Update

Andy: I'd like to speak with you about Safari features to support PR API
... we shipped some Apple API payments support in Safari and have seen good adoption
... we'd like to converge with PR API to reduce burden on merchants
... so we've been exploring apple Pay as a payment method within PR API
... we have mostly a full implementation of PR API and defined a URL-based Apple Pay payment method
... we have a dictionary that goes with it to define some Apple Pay-specific bits
... we've done some things differently in PR API .... e.g., we differentiation of line items by payment method
... unlike ApplePay.js events
... but lots of things are the same such as merchant validation process
... there are rules for showing Apple Pay button and how to display on the site
... for privacy we redact shipping info until user has provided payment details
... we've also been working with the WG to describe how merchant validation should work
... and optional updates
... that is - to adjust the API to allow us do our apple-specific things cleanly
... some of those things MIGHT work their ways into the APIs
... at TPAC we had a few proprietary events; we got rid of all of those
... so now we are using PR API features for those capabilities
... there are still some things that PR API needs at least to work with Apple Pay payment method to rival capabilities of ApplePay.js
... there are open GitHub issues that we are working through
... but we have enough already to fully support Apple Pay transactions for common cases
... we can add support for edge cases over time
... please note that (1) this is not an announcement of support for other payment methods in Safari or (2) not an announcement of support for Apple Pay from other browsers
... rather, this is good news for merchants to lower front end development costs
... available now in Safari Technology Preview
... we'll have more details soon both about documentation of the Apple Pay payment method

<Zakim> manu, you wanted to pre-emptively ask Andy/Magda if Web-based Payment Apps are going to be supported.

Manu: Thank you for the update; I think you answered but want to ask to be sure - are there any plans for Apple to support Payment Handler API?

Andy: I have nothing to announce right now; I'm aware of the spec

Manu: Digital Bazaar has a polyfill for payment handler
... do you know of anything that it's Safari that would stop web-based payment app polyfills from executing?

andy: Are you referring to appr wrapper?

Manu: No, this is a digital bazaar polyfill that runs in Safari today

Andy: If you are polyfilling payment handler, that would not likely create a problem
... one thing we are looking at is to increase security by making PR unforgeable
... so that would affect PR API .. but we are not doing anything yet

<Zakim> Ian, you wanted to ask for links to that documentation when it's available

<manu> Ian: Thanks for the update, you mentioned updated documentation

<manu> Ian: We have been gathering links to developer guides on our portal, as of last week we're trying to work with Mozilla Developer network to migrate content to MDN.

<manu> Ian: I don't currently have any developer guides from Apple yet, please let us know what they are.

<manu> Andy: Not sure if we've published docs yet.

<manu> Ian: Yes, when they're available, please send the links along

<manu> Ian: 2nd question - deployment of Payment Request API in stable browsers - any rough time frame for that?

IJ: Any time frame for "default on in Safari"?

Andy: it's in developer betas

<Ken> +q

Andy: putting in High Sierra but timeline for that is outside my control

<Zakim> dezell, you wanted to ask about VAS?

dezell: Great to hear about the convergence with PR API
... what about Value Added services?
... do you know about those in the NFC world of Apple Pay?
... there was work done to add digital offers to that set
... you could use price reduction mechanisms
... we are sort of interested in hearing about how these "extra payment" things might work

Andy: We do some store card (and origin-based validation)
... card details available to merchant before selection by user, allows merchants to apply discounts
... we don't have that capability via Payment Request API
... we may need to add a full event that fires in PR API that includes all the card details in the case of store card
... to allow the merchant to do more complex computations. See issue 662.

Ken: Thanks Andy for sharing
... have you got any feedback from merchants on the shift to PR API?
... or anything in particular hindering adoption?

Andy: We've gotten some valuable merchant feedback and are looking for more (through developer betas, for example)
... some of the remaining work I have on my plate has come from merchant feedback (such as passing a Promise to the show() member to update details)

<manu> Ian: We've been looking at tokenization, for example...

<manu> Ian: If we get tokenization right, parties that use tokenization could leverage a standard tokenization approach.

<manu> Ian: I'm checking to see if Apple is looking at Tokenization work, even at a high level. Would it be possible to ask for some feedback wrt. how Apple Pay works today to see if there could be convergence as it would reduce costs for merchants.

Andy: I am aware of the effort
... our focus today is on PR API implemented
... it is something we should talk about internally at Apple and decide when and where to give feedback

<manu> Ian: I'm assuming the same answer for 3DS.

<manu> Ian: Happy to engage when Apple is in a position to do so.

Chair remarks

David Ezell Slides

WCIG charter

scribe: to fulfill the goal of identifying opportunities we would like to hear from you

[David lists topics in progress, some in IG, some elsewhere]

Regulatory, ID management, IOT, digital receipts, digital offers, mobile networks, security, VR/AR

scribe: note that work at conexxus is moving ahead on mobile; keen to align with w3c
... security (including web auth WG)
... also discussions going on around automotive payments
... we check in periodically on VC and ILP

david: We'd like to focus on things to standardize; we'd like more open discussion and brainstorming to identify potential topics
... remember we have revised the meeting format for the group - monthly calls
... chairs and staff reaching out to find topics; feel free to volunteer

Manu: What do we do about IOT payments?
... and the HTTP API
... fundamentally payment messages
... how do we come up with a plan?
... is there anyone in the group interested in having that conversation?

or is the conversation shifting to another venue?

dezell: Interfacing with HTTP APIs is important to conexxus
... to serve people with basic connectivity

Ken: Amex would like to participate in the HTTP API dialog
... I'd recommend going back to the TPAC discussions on this topic
... there were a couple of organizations that had expressed interest in implementation (e.g., Worldpay)

Manu: last time the work stalled due to lack of critical mass

<manu> Ian: I can speak to that a little bit in light of recent discussions on Payment Request and Payment Handler.

<manu> Ian: Firefox is focused on PR API implementation, PH does not have a lot of implementation, Chrome is implementing, Firefox not so much, nor is Microsoft of Apple.

<manu> Ian: That suggests to me that implementer focus is still focused on PR/PH

<manu> Ian: I haven't had those conversations w/ other organizations... from WG perspective, there is a lot of energy on tokenization and 3DS, from a WG perspective, that's where the work is being driven currently. When we last broached this topic, there was a question on where this might live.

<manu> Ian: We talked about if it should live in Web Payments CG, or some merging of CGs. I had been under the impression that work would be taken up in some CG.

Ian: I have not checked lately if work is taken up in a CG

Manu: Hasn't happened since no critical mass. I think you are right about browser vendors and where their implementation priorities lie
... I'm not suggesting the work go to the WG, the question is whether there is critical mass to implement in a CG
... there may be other business units, e.g., focused on IOT

<manu> Ian: After face to face meeting, I tried to work with Mike McCool, chair of IoT WG, but didn't get much of a response.

<manu> Ian: Haven't had a lot of IOT payments discussions since TPAC.

Magda: Some of these other task forces...do we have any cross functional people sitting on those groups?
... I will occasionally sit in on other groups
... do we need more people doing that and reporting back?
... let's add those people as potential reporters

<manu> +1 to ask people to report in on what they may need from us

<manu> Ian: Would like to acknowledge that suggestion, and we are at the top of the hour.

Next meeting

10am ET on 26th of February

dezell: Ideas for next time:

* ETA update from Amy Zirkle (Confirmed)

* Google Pay update (postponed)

Some other ideas:

* 3DS