W3C

Web Payments Working Group

23 Oct 2018

Agenda · 22 October minutes

Attendees

Participants from the Web Payments WG and Web Authentication WG

Present
Most of the same people as yesterday. In addition: Zouhir Chahoud (Edge), Phil Archer (GS1), David Ballaschk (Deutsche Bundesbank), members of the Web Authentication Working Group (for the joint session), members of the Internationalization Working Group (for the joint session).
Chair
NickTR
Scribe
Ian

Contents


Agenda bash and welcome

How many people going to the AC meeting?

(12 or so)

Risk Analysis and the Web (with the Web Authentication WG)

[Ian Jacobs slides]

NickTR: Welcome WebAuthN WG!

<nicktr> anthony: can wrap up attestations as signals

<nicktr> ian: can that be done without registation?

<AdrianHB> scribeassist: Adrianhb

<AdrianHB> IJ: It would be useful to tease out use cases

<AdrianHB> John: There is a spec in dev at IETF called "Token Binding" which binds a token to a user agent

<AdrianHB> ... this covers use cases similar to how cookies are used today

<AdrianHB> ... there is a bit more of an ecosystem that we can consider in evaluating if WebAuthn addresses our use cases

<AdrianHB> [ian covers additional ideas slide]

<AdrianHB> IJ: A device data api could provide data in a controlled and verifiable manner with user consent

<AdrianHB> ... also vouched for as accurate by UA

<AdrianHB> Rolf: Why consider additional ideas before we have precluded Web Authn? Also, this is easily spoofable and nowhere near as valuable as cryptographically signed and attested data

<AdrianHB> IJ: I don't mean to preclude WebAuthn. Keen to discuss further.

<AdrianHB> John: One of the biggest challenges that Web Authn solves for is protection of private keys which can't work if the same key is simply distributed with all browsers

<AdrianHB> [Ian mentions a second proposal that was linked from the deck on a user confidence score from the browser.]

<AdrianHB> Rolf: We know there many risk signals but the reality is they are all very weak and easy for an attacker to spoof

<AdrianHB> ... they are also very noisy. Strong signals require cryptography

<AdrianHB> ... it is essential to bootstrap the trust using keys rooted in hardware

<AdrianHB> IJ: What if the data is signed by Google.com?

<AdrianHB> Rolf: It's impossible to do this with software alone

<AdrianHB> MWeksler: Even a server based solution can be compromised because it could be queried by a compromised browser

<AdrianHB> NickTR: The challenge we have in the payments industry is a balance between getting strong signals and reducing friction

<AdrianHB> Rolf: It would be useful to separate the bootstrapping discussion from the friction discussion.

<AdrianHB> Anthony: There are actually already a lot of existing platform authenticators out in the world already

<AdrianHB> John: We are also looking at using parts of WebAuthn to attest which application is making calls to services

<AdrianHB> ... so there are other things like this that may be useful

<AdrianHB> Athony: IETF also working on the Entity Attestation Token specification.

<AdrianHB> mweksler: In my mind the Javascript sniffing is the current way to do "attestations" in the absence of anything better. However even with Web Authn we still have an issue with enrollment.

<AdrianHB> 3DS may be the solution

<scribe> scribe: Ian

IJ: Let's walk through scenarios

Jonathan: We walked through some scenarios yesterday, talking about tokenization and consumer authentication
... having the possibility to leverage WebAuthn is great
... I'm sure that we can walk through different possibilities to leverage WebAuthn
... one easy example: auth results are fed into the 3DS protocol
... that would avoid the issuer (re-)authenticating the consumer.
... that's one way to combine 2-factor auth with risk analysis
... I think we have a lot of foundations with the WebAuthn and FIDO work ... even if more work needs to be done on how concretely to feed into the rails.
... Ian made a second comment on other signals from the browser.
... outside of WebAuthn discussion merchants may know the consumer (e.g., the user is logged in and there's a history of successful transactions)
... that's a big asset from the issuer to get that data.
... today that exists as a user signal, but we've had the idea that the browsers also know the users and perhaps they can provide that confidence signal instead of merchants

BrianP: We need to separate the authentication into the endpoints
... we look at issuer view and merchant view
... what the merchant knows, unless and until it's known by the issuing bank, the bank needs to know whether to transfer the funds

Tony: Do you care about the provenance of the authentication, where it happened?
... Do you care about the freshness of the authentication?
... are there transitions (e.g., of lower value) that don't require freshness?
... I also understand you are interested in offline situations
... is that correct?
... are there transactions where all you need to do is check the freshness?

Jonathan: Would you still capture the auth and send through the network in this case?
... Note that under PSD2 no auth required under 30 Euros
... is putting fingerprint on phone considered friction?
... can it be avoided in some cases (e.g., under 30 Euros)?

Tony: We don't have silent authenticators in WebAuthn
... that is, where no user gesture is required
... we have those in FIDO but not in WebAuthn yet because things happen in the browser and people may not want signature to happen (e.g., in case of injected JS)
... we ARE looking at other means to provide time-based (or similar) that would let you do confirmation without doing the gesture (e.g., you've already authenticated and it's less than 2 minutes later)

Jonathan: If you really want issuer to take this into account you need to capture the gesture. ...but agree that "recently authed" is an interesting possibility.
... but some regulation requires auth at the moment when the user sees the final amount
... PSD2 will want you to authenticate only upon seeing the final total

NickTR: First, thanks everyone. We've been talking mostly about cards here, but there's also a lot of non-card payments
... some technologies related to offline (e.g., Alipay and WeChat Pay) are push...they are using web technology for physical world payments
... the Web is becoming a transport network for all sorts of payments.
... 3DS2 asks for a lot more data (than 3DS1)
... this conversation kicked off for us at our last FTF meeting where there were concerns expressed about the amount of data

Ken: +1 let's keep offline as not a priority

Tony: We are also talking about lifecycle issues (e.g., what to do when device is lost)
... that becomes more important as you are trying to do authentication

<nicktr> Ian: The fundamental issue that drove 3DS design was reduced friction where possible (I think). What are the "optimisations" envisioned by the Web Authentication Working Group for WebAuthN that might result in less data collection? Time-based (gestureless, cacheable), multiple origins? For example, if the browser could authenticate the user once and if multiple sites accepted that, it would involve fewer user gestures.

John: We have restrictions on domains currently; but that's due to the dependency on the Credential Management API
... but we are starting to look at using Feature Policy to allow us to go outside of the top level domain

IJ: Is freshness or shared auth useful to schemes or issuing banks?

nicktr: It's also a legislative challenge
... in the EU market, the way SCA is defined, using time-based attestations would not be satisfied
... PSD2 requires the real-time authentication

BrianP: It requires that you display the merchant and amount at that time

nicktr: The consumer has to authenticate the amount of the transaction in real-time

Rolf: WebAuthn can be used to auth to merchant or to the issuer, so there's a lot of flexibility for those parties to make use of web authn
... if you need a fresh signature, you just ask for it
... if the issuer has the channel to talk to the consumer ... ask for auth via WebAuthn

(Ian observes that the "channel" could be via a Payment Handler.)

rolf: We don't need to standardize who does what; each party has the flexibility to use web authn in a way that they need.
... you can make risk decisions based on strength of authenticator via the attestation
... we would argue that you can increase both security and convenience at the same time
... protects against phishing

[Next opportunity for discussion on this topic together: W3C Workshop on Strong Authentication & Identity - 10-11 December in Redmond]

John: We are starting to roll out a public key ecosystem via Web Auth; we want to avoid one device per activity that you are doing
... we want to be able to accommodate different scenarios.

IJ: What are top things you plan to do in WebAuthn?

John: We will likely extend charter to Sep 2020. Top items are:

IJ: Is the limiting factor in Europe more a regulatory issue or more technology?

Herve: In my experience it's more technology.
... API can transport authentication results

ChrisMichael: I don't think it's a regulatory issue
... the regulation is pretty straightforward....dynamic linking
... banks do use whatever factor they want as long as it's SCA
... the regulators need have called out that it needs to be consistent in different scenarios
... banks are allowed to allow some exemptions
... it's not clear what an exemption from SCA means
... some have interpreted it to mean "1 factor suffices"
... others have interpreted it to mean "no auth is required at all"
... so long-lived consent would work in that framework.
... I think regulators would probably come down with a consistency approach; not penalizing APIs over direct customer interaction

NickTR: I would like to hear from browsers about views on data gathering

Rouslan: Silent fingerprinting is not the best option
... user has no control over what happens
... we definitely think that WebAuthn is the future and where we should end up
... but few users have the hardware today or understand how to use it, so I think it would be useful in the meantime to provide some kind of signal to the financial services industry about the device and user
... while understanding that this signal is fallible
... so any signal would be need to be weighted appropriately
... and the three options we've discussed (1) score (2) hash (3) attributes about the devicer
... those are middle ground between silent javascript fingerprinting and WebAUthn
... we haven't landed yet

AdrianHB: On browser signaling concept..one way I can see that being more palatable is if it's only available in the payment API
... as opposed to being available to anyone

estes: I agree mostly with Rouslan; we are working to reduce fingerprinting surface area
... we'd also prefer webauthn solution

MattS: +1 to Rouslan and Andy
... would like to have both webauthn and ability to query device data

MattP: We are currently at an in-between state....webauthn and attestation is key...I think in 3-5 years we may not need the other signals as much

IJ: Does WebAuthn WG do adoption work, or is that mostly distributed among the vendors?

Tony: Mostly among the vendors
... we've gotten the technology into the platforms and the browsers
... now it's up to the platforms how they want users to use it
... in the case of Microsoft it's in Hello

Rolf: Many more deployment discussions happen in FIDO where the vendors are

nicktr: EMVCo is working with FIDO to enhance the relationship....and WebAuthn is built on FIDO
... is there an opportunity to close the triangle?
... along with 3DS

BrianP: We are working on the Secure Web Payments Interest Group proposal

Shopify's Experiment and Findings

[ Krystian Czesak slides]

Krystian: Today I'll present findings from Shopify's A/B experiments using Payment Request
... this experiment is mostly around the basic card implementations in the browser
... the numbers you see are medians across merchants

Krystian: Hypothesis....market is ready for users of our platform
... this experiment ran only on our card page; user would see PR API half of the time
... we chose large merchants (most traffic)
... for a buyer to be eligible for the experiment, the browser needed to support PR API
... our traffic was mostly around Chrome's implementation
... then 50% of eligible buyers would go through our experiment group (PR API) and other half through our regular card checkout
... final caveat - we dealt with gift cards by allowing users to go through regular checkout

[Findings]

Krystian: Upon clicking checkout button until redirect to thank you page...
... median times with canMakePayment() true was 2:16
... canMakePayment() false was 3:13 median time...so much faster with canMakePayment true,

and both faster than usual check out

scribe: we saw a drop in completion rates but that demands context
... keep in mind that we have had a dedicated full team for 7 years to work on our checkout flow compared to new Payment Request API, so this is actually not that bad
... most interestingly we tracked progress through the payment sheet
... we have two event listeners - address, shipping option
... we also checked opening the sheet, canceling out of the sheet
... but basically:

60% of customers drop out without interacting with their shipping contact information or providing shipping methods

scribe: that is 60% of all buyers who initiated a flow

Giulio: How many had a shipping address in there?

Krystian: We don't have visibility into that
... all we can say is that 60% did not interact with shipping address/methods

35% of buyers who dropped out preferred clicking on either regular checkout link or discount code

scribe: most of those (85%) clicked on discount link
... so that might mean they didn't see the link initially or didn't realize they could enter discount through either flow
... or something else was going on that we still haven't identified

32% initiated a payment, and 28% dropped out for other reasons (e.g., cvc error, decline)

[Other numbers]

30% of customers tried 1 or 2 times to go through payment rqeuest, so that's encouraging
... they were not put off by the experience

7% tried 2 or more times

[Feedback from merchants]

Krystian: We gave some feedback directly to browser vendors about user experience.

scribe: merchant feedback: they were not used to it and it's different from what they are used to....BUT they recognized in many cases benefits of the new checkout experience
... so we might address this with some branding or other merchant adoption initiatives

Krystian: We were excited to try it out. It is not quite yet market ready for our platform; we don't plan to expose it for now but would like to explore further as this group addresses UX features, as payment handlers take hold, as we work on branding, etc.

Rouslan: Thank you so much for the study! We welcome this type of feedback from everyone to improve the product
... We are making changes to the UX to take into account the situations that you described, e.g., when the user does not have information yet, a new flow is coming soon

UNKNOWN_SPEAKER: the question I have is "is there anything in the API that we could change to improve the user experience?"
... beyond payment handler
... or for example, are more detailed error messages required?
... would that help with analytics?
... another thing we could look into is canMakePayment() semantics
... we have come up with two modes for it (1) payment method available (2) payment method has credential
... does this mean that we need another query to understand presence of shipping address?

Krystian: For shipping address, you are correct - I think "enrolled" query could take into account shipping address.
... I think "ready to pay" should include all the things needed to make payment (including shipping address)

AdrianHB: Is the use case at all resolved by the ability for the merchant to provide shipping addresses?
... e.g., for a repeat shopper?

Krystian: Partly yes

marconi: For customers who had ship to/bill to provision, could you quantify how much faster than standard checkout flow?

Krystian: can't share that detail

phila: Thank you; sounds like some of the negative comments might be addressed through education.

Giulio: Thanks, Krystian! How did canMakePayment() false work?

Krystian: Was a blended rate between both true and false

Giulio: What did a customer see during the path?

Krystian: They would see normal checkout .... in some cases there were branded buttons above and below

Giulio: That might entice some users to go with something they are more familiar with

David Benoit (Remotely): What kind of customization of the sheet would merchants like to see?

Krystian: Good question - definitely one piece of feedback is respecting the favicon...that's a must for the merchants
... the merchants may also wish to change the primary or secondary colors of the sheet to match their site
... in more extreme cases, some of them wanted a header image in payment request
... IMO that's a bit too extreme, but definitely controlling some visual aspects would be a must for them

Ken: Do you think outcome would have been different with branded buttons?

Krystian: We couldn't have done Apple Pay in the sheet due to Apple branding requirements
... we think setting expectations for the buyer upstream helps with conversion

Roy: You mentioned the 7% drop was a mix of true/false...was there a diff between the two?

Krystian: 1%

estes: Had you considered A/B offering apple pay to some users and PR API to others?

Krystian: The difficulty now is that Apple Pay is available to all merchants on our platform
... so might be too late

Visual Identity for Web Payments

[ Ian Jacobs' Visual Identity Slides]

<AdrianHB> IJ: We kicked of iteration 2 of Visual Identity TF

<AdrianHB> ... last year we identified the need to provide something that users can recognise across websites

<AdrianHB> ... response after iteration 1 was "lukewarm"

<AdrianHB> ... Facebook hired a designer to help and new iteration started in July

<AdrianHB> ... Heath (designer) did a brand analysis and produced logos which the TF refined over many iteration

<AdrianHB> ... TF was expecting a final round of logos before now but IJ only got them this morning so we're all seeing them for the first time

<AdrianHB> ... not being shared publicly until (if supported) they are finalized and necessary paperwork is done

<AdrianHB> ... goal (if WG agrees) is to get these out in line with release of standards

<AdrianHB> ... 3 key messages that emerged through iterations

<AdrianHB> ... 1. A wallet

<AdrianHB> ... 2. A globe (global)

<AdrianHB> ... 3. Exchange (commerce)

<AdrianHB> [IJ shows logos]

<AdrianHB> IJ: Opening wallet is unique (not used in other payments branding that we found)

<AdrianHB> ... adding color further distinguishes the design from existing logos

<AdrianHB> ... scales well

<AdrianHB> ... Using the logo within the phrase "Web Pay" has been given initial clearance by legal for use

<AdrianHB> ... Logo in the middle breaks words in an appealing way.

<AdrianHB> ... The anticipated distribution policy would allow people to alter the logo (e.g., to changes colors).

<AdrianHB> [IJ shows what logo might look like in existing browser sheets]

<AdrianHB> ... Discussion to date is that some users are confused when the sheet opens up after pushing the "Buy: button.

<AdrianHB> ... We think it would be useful to link the button on page to the visual identity of the sheet

<AdrianHB> ... Need to obviously discuss with browsers where this could be added to sheet

<AdrianHB> ... want to show the logo used as a checkout button (although need to get designer to mock this up)

<AdrianHB> marconi: Logo looks a but like old ISIS mobile payment logo

<AdrianHB> ... looks like a phishing scam

<AdrianHB> IJ: The perceived need is a common browser experience without a way for UX designers to signal that this is what users should expect when clicking the button

<AdrianHB> ... analogous to RSS logo in some respects. Signals to users that the website has a feature

<AdrianHB> ... challenge is that it is not actually a payment system

<AdrianHB> ... so trying to balance fitting into the expected flow vs being a payment method

<AdrianHB> Eiji: I think Web Pay won't be a trademark issue as it's a payment company in Japan that was bought and no longer trades under that name

<AdrianHB> IJ: We would still need to do more legal work, as I said.

<AdrianHB> Krystosterone: Great initiative. Not sure about wallet. I don't think it will age well. Eg. Icon for "SAVE" is still a 3.5 inch disk which is legacy tech

<AdrianHB> ... Buyers on our platform associate "X Pay" with a payment method so that may add to confusion

<AdrianHB> Phil: Aspect ratio is different to other buttons so may be hard to include in checkout pagees

<AdrianHB> IJ: Work to still do to figure out how it might sit on checkout page

<AdrianHB> Phil: Internationalization?

<AdrianHB> IJ: Haven't got into how the words could be changed. I suspect they could be

<AdrianHB> Zouhir: Have you explored using the icon in the browser chrome, e.g. as is done, for example, with the lock for secure websites

<AdrianHB> IJ: Could have no button but some other browser chrome that triggers sheet?

<AdrianHB> Zouhir: There needs to be some hint before checkout that suggests to the user that the page supports paymentRequest

<AdrianHB> ... or perhaps only show the logo when the flow is kicked off

<AdrianHB> IJ: Could do more in the browser chrome to suggest that a payment is in progress

<AdrianHB> benoit: "Web may be a term that, especially younger users, don't understand. Also the wallet is maybe a little too "Western male"

<AdrianHB> MattS: I think this can help solve the "suprise" users are reporting when paying with payment request.

<AdrianHB> ... over time users get comfortable with the new method and associate it with seeing this logo on the website

<AdrianHB> nicktr: this is just the beginning so feedback appreciated

<AdrianHB> ij: we recognised the need for signalling and helping users understand the connections between the mix of "domains" that a user goes through using PR API

<Roy_> +1 for Matt's suggestion of exploring elevating the checkout button into the browser chrome rather than a web page UI element

<nicktr> adrianHB: I am more inclined to see this as a symbol rather than a brand - like the lock is seen across the web is seen as denoting "secure"

<nicktr> ...this is why I like the wallet as a very simple design

<nicktr> ...so it can provide hints (like when "canMakePayment" is called causing the wallet to appear in the address bar)

<nicktr> ...This is similar to the transition from http to https

<nicktr> Jonathan: I agree with this concept - I am concerned about the notion of trust which will vary between payment methods

<nicktr> AdrianHB: this should be a hint only

<nicktr> [Ian shows the various brand logos that were included in the analysis.]

<nicktr> IJ: we debated what the logo should show - we went with a wallet rather than an abstract image

<nicktr> IJ: We have come to the conclusion that this is related to payments

<nicktr> Jonathan: As Rouslan says, this is either a "chrome" thing or a "web payments" thing

<nicktr> IJ: But Users don't know what "browsers" are

<nicktr> IJ: It's not just about the browser - it needs to work across the browser ecosystem

<nicktr> IJ: I am concerned to hear people say that the concept of "the web" is outdated

<nicktr> Rouslan: from the perspective of an engineer, I like the wallet.

<nicktr> Rouslan: I would like to put this all over the place

<nicktr> Rouslan: +1 to showing after "canMakePayment" is called

<nicktr> ...it would be a good indicator that something magical is about to happen

<nicktr> (strawpool to show whether we should continue)

<nicktr> (about half the room in favour of continuing, about 5 to stop)

<nicktr> (second strawpool)

<benoit_> continue

<nicktr> (likes as is = 2)(ditch =0)(continue to develop = about 20% of the room)

<nicktr> Ken: merchants will do what they want with their check out experience - the logo will be used inconsistently

<nicktr> ...also big companies don't need/want help with branding. But SME/SMBs _do_ need help - does this help this community?

<nicktr> Ian: in the future, can we have the browser render the pay button (issue #777)

nicktr: Consistent "hint" across browsers / a cue

Web Monetization

[ Adrian Hope-Bailie's Slides on Web Monetization]

<nicktr> AdrianHB: the way this works, there would be an API that allows the website to request a stream of money (send or receive)

<nicktr> ...very small amounts (e.g., thousandths of a cent) - over something analogous to a web socket

<nicktr> AdrianHB: the role of the provider is to throttle the stream of micropayments

<nicktr> ...the hope is that websites could then be (for example) ad-free

<nicktr> AdrianHB: proposed Web Monetization specification.

AdrianHB: The provider chooses how much money and the provider
... that's where we think the competitive space will be
... Coil, for example, charges users flat rate of $5/month
... others can choose other models
... our hope is that users will appreciate experience with monetization provider

[Adrian shows a demo where he visits a web site, and money slowly streams to the site]

Ian: Adrian shows that he then has access to content having monetized the site through the API]

AdrianHB: We are interested in bringing a Web Monetization API to w3c that gives payees access to monetization streams.
... is there interest from this forum on Web Monetization? This API?

phila: Very interesting. Would this support a freemium model?
... would it support data services over the Web?

AdrianHB: I don't see anything preventing that
... the API establishes a link between the provider and the funds
... once it has been established, you could put other protocols on top of that.

IJ: Does it use WebRTC for p2p?

AdrianHB: Not currently; that is something we have looked at.
... but it's not really browser to browser it's browser to server

Rouslan: Overall, the idea of micropayments and monetization is really interesting
... I would be interested in exploring it somehow

AdrianHB: For the purposes of the working group, having a task force might be a start

[Scribe note: A W3C Workshop is also a possibility]

Roy: I can readily see consumer demand from a paywall perspective
... do you have any data?

AdrianHB: We don't have a lot of data yet. You can use it on Youtube and Twitch
... paywalls are a bit more challenging
... we had a conversation with someone in the past, and one issue with some types of media is that
... the cost of some types of content (like an investigative column) is too high for small monetization streams
... but might be interesting to experiment with bundled content
... Users may be ok with ads on some sites, monetization through streams on others

Rouslan: Proliferation of ad blockers suggests people are not happy to see a lot of ads...some other monetization approaches would be good for the health of the whole ecosystem.
... I see the point of giving options to publishers for monetizing different types of content.
... you also need user protections like "instant refund" if the user is not satisfied with the content.

AdrianHB: This is an aggregation model: if I a happy with the service overall, I am ok to pay the money. If you are unhappy with content overall you pick a better provider rather than recover money from a particular site. That, at least, is our model.

michel: Refunds are still going to need to happen...even if from the aggregator.
... users may need more recourse than "I don't like my provider"

AdrianHB: Provider might refund user based on complaints, for example. You can even use underlying dispute models (e.g., if backed by card payments)

rouslan: I would like to hear opinions from payment handlers and financial industry participants in the room....have they encountered other challenges?

nicktr: Micropayments is hard due to the cost of friction.
... disputes requires an overarching system with arbitration, and that's a cost to be borne
... micropayments is unsolved, in my view
... I'm not aware of extensive work going on in the mainstream financial services industry around micropayments
... there was some interest in cryptocurrency world, but those are not real-time and there is other friction and transaction fees, so not the panacea
... sidechains also tried, but there's a cost there as well.

Zouhir: Web Monetization is important. There are simple categories of payments, like up front and in-app
... I think can reward users with fewer ads in games if monetized in other ways
... there is also what Brave Browser is doing.

Generic Payment Tokens

[ Adrian Hope-Bailie's Slides on Generic Payment Tokens]

AdrianHB: The word "token" is overloaded. Here's what I think it means:

- represents the authorization of a payment

- redeemable by the payee on a specific network

- produced by the payment authorization authority

- network rules dictate how the token is redeemed

- token data is mostly opaque to payee systems

<benoit_> +1 for "token" being overloaded :)

AdrianHB: I'd like to come up with something generic on the web, that could be used across multiple networks
... Push payments bother me generally.
... I think the experience is less than ideal.
... merchants lose control of flow
... no retry our cancel
... integration at multiple places in the flow
... recurring payments...HA!
... A pattern I like is pre-authorized push payments.
... they are push payments that feel pull-like
... this gives merchant more control
... bank doesn't do push payment, they return a token
... then the payee submits that token to actually cause the payment to happen
... so there are two phases: (1) authorize payment then (2) initiate payment (with token)
... this allows merchants to manage their flows
... Proposal for a tokenization spec
... as simple as saying "I accept tokens from a variety of networks"
... the underlying data depends on network
... some common metadata (e.g., "one-time use")
... a typical response might be as simple as three pieces of information: label, network, token
... So is there appetite for a single tokenization spec (more generic than card tokenization spec)
... leaves specifics to the networks.
... this would make browser implementation simpler

Russell: I am interested (but cf IPR)

Roy: What's the substantive difference between token with network options and a bunch of specific payment methods?

AdrianHB: I think this is an easier integration path
... just one method since they don't care about the differences between the different types
... implementation is simpler for the browser
... they just need to implement one spec and filter on networks

AdrianHB: browser doesn't need to differentiated based on instrument type

Rouslan: Do you envision the browser keeping track of tokens, balances?

AdrianHB: No, only which networks the user can give tokens for.

davidBenoit: We stopped using the term "token" and started using the word "contract" instead
... so +1 to moving to networks that don't have to create their own tokenization method

Internationalization Joint Session

Marcos: In order to implement languageCode other browsers would have had to use a particular library (from Google)
... we didn't want to have a dependency on a library, and we had a hard time specifying the algorithm.

Rouslan: The use case - addresses can be formatted different ways in some countries; usually there is a default way....but when it is formatted for English, the address might be formatted differently
... e.g., from less to more specific components of the address, or vice versa
... in Chrome we had some guesswork and suggested that others do the same guesswork
... we then tried to specify something correct.

Marcos: The conclusion was to remote it from the spec.

Addison: The kind of things you are talking about (e.g., complexity of postal addresses in a global environment), have different presentational formats that can be applied
... Our group would still like to see a language tag to do display but also things like font selection
... I think the current state is that you removed languageCode.

Rouslan: Can you simply look at Unicode code points?

Addison: If you have two distinct writing systems; yes
... but for determining the language of something, no.
... e.g., overlap in characters between Japanese and Chinese

<nicktr> ian: I have a scoping question

<nicktr> ...we say here's a piece of data, it's up to the merchant to know what to do with it

<nicktr> ...so information is lost if you just have a string of text

<nicktr> addison: by not providing language and direction tags, downstream applications can't do a good job

<nicktr> ...whereas if you capture metadata at point of entry, you can do useful things downstream

Roulsan: Eiji and I analyzed several shipping APIs.
... first, they don't include all the fields we think we should include
... but 0% of them have language tag or direction as input to the APIs
... how can we deal with that?

Addison: I am confronting that in my day job at Amazon
... the state of affairs is somewhat broken since the APIs are often optimized for local shipping / first mile / last mile

Rouslan: So if we provide this data, those APIs would drop it on the floor?

Addison: Yes, but other consumers might make use of it.

Richard: If you don't provide the information at all, you can't improve the situation.

Rouslan: Do you think the quality of the data from the browser is high enough?
... all we have is user locale
... the user might have en-us as their locale....we have to guess they are "probably typing in English"

Addison: We would assume the form is localized; not just the browser's localization
... There are guessing thing you can do (as we discussed github)
... no individual thing is a sufficient solution
... but to a motivated developer it's straightforward to add direction and language
... I know it's a hard problem; aware of PayPal and other companies doing extensive work in this space

Rouslan: One issue we have is that the guesswork was kind of subpar....was critiqued by I18N group
... are there are any algorithm descriptions that say the right way to do things?
... in particular, with BCP 47 there's a lot of info

Addisson: BCP 47 is about language/locale, but not specific to address

IJ: Are there user experiences that could be good approximations like "format for this country"
... Does knowing the target country from the shipping address suffice? Could you approximate by looking at characters in combination with the target country (e.g., see latin characters and JP) and that tells you how to format?

r12a: Lots of addresses will have a mix (e.g., some left-to-right text in the middle of otherwise right-to-left text).

IJ: How many variations are there? Big endian/small endian

Addison: Small number of variations....big endian / small endian
... but the next level of granularity has to do with fields that COULD be filled in by the user but you don't want to have to include in the formatted address.
... e.g., Germany has regions but you don't see them when formatted in postal codes.

Richard: My wife might put the name of the country "JAPAN" in English, but the rest of the address in Japanese (at the bottom). She would do this so that the people handling the letter first can read that piece of information.
... We recommend not breaking addresses into small pieces

Rouslan: We talked about giving merchant plain text blob to merchants...but many merchants have restrictions like "we don't ship to Alaska or Hawaii"
... or "there is an extra fee to ship to this city"
... we don't split into house number
... we do allow for "in care of", for example, in addresses.

IJ: What is missing?

Addison: You need the country to be a country code
... with that you could as a merchant use a library to format it in virtually all cases
... with the proviso that it will sometimes look odd where there are more formats in a country
... if you were to provide formats for a country, they would still need templates

Marcos: It's not clear to me that we as Mozilla can do better than the merchant

Addison: If the fields are regionally neutral and you have country code you do formatting

<stpeter> For context, these topics were also discussed on GitHub, see https://github.com/w3c/payment-request/pull/764#issuecomment-418879354 and https://github.com/w3c/payment-request/pull/764#issuecomment-418904998 as well as https://github.com/w3c/payment-request/issues/608#issuecomment-414510456

Richard: You might need to know the language of the text (e.g., Japanese v. Chinese) to do right formatting
... If you are shipping to Israel or Egypt you probably need to know the base direction of the text (e.g., for acronyms or numbers)
... and some variations between Gulf states

Rouslan: Some info will be encompassed in country code
... Does Unicode not include direction?

Addison: Yes, of individual characters

Peter St Andre (Remotely): I want to echo Richard's comments...in the GitHub thread we noted some things we really should have in PR API. I think we came to some conclusions such as the languageCode we had was not addressing some known issues
... there is some work that we need to do ... I want to make sure we get on the table what those are and develop a plan

Marcos: It sounds more like "what is the language of the payment sheet"?

Rouslan: Is that exposed through accept-languages

Marcos: We say in the spec that when you open the payment sheet, it SHOULD use the document language as the language of the sheet.
... we don't, however in practice ship every language
... having said that, we don't expose the language information for privacy's sake
... we could send through the API the primary language and direction of the form
... but the page knows already their language and direction

Addison: You want the language information and direction for the address.
... Individual strings work fine
... mixed direction strings need a base direction
... for people who write RTL there needs to be a way to assert "I want to type this RTL"

IJ: How does user change direction?

Richard: Usually key on keyboard or, context menu, or the text itself

IJ: Could OS features suffice here? (if the browser chrome inherits from a toolkit that has been internationalized)?
... and if the user does a gesture to indicate a direction....then that gives the upstream information that we want to communicate through the API

Marcos: I don't know how we do that today with the right granularity

AdrianHB: If I am capturing an address and I choose to change the locale, then that needs to go through the API

NickTR: Apple Pay is live in Japan, right?
... and you have shipping address in Apple Pay...can you tell us how you solve for this?

Giulio: One thing we learned was that we had to also account for phonetic names
... we focused a lot on transit and physical payments
... ecommerce has been growing; one thing we learned during that growth was that
... in order to ship anything, you also need name expressed as phonetic name, which amounted to name/family name twice

estes: ApplePay.js also breaks addresses down by semantic block, but the input is just text fields, controlled by the OS's locale
... We may be relying on Japanese merchants to adjust

Eiji: One piece of feedback I have regarding the larger address structure .... add a field for phonetic form of name

Nicktr: I am hearing this is a hard problem
... and that it's not consistently solved anywhere

rouslan: We found that in Japanese credit card input forms, they might type in a Japanese character name...you need the label to say "Latin character version of name"
... I think I have a proposal - could we continue the conversation by generating a concrete proposal how you would change the data structure
... then we can review the proposal and see if we can do it.

Addison: That would be a helpful starting point
... I think there are tradeoffs on all side.

<scribe> ACTION: stpeter to work with the I18N WG on a concrete description of the data changes that they think are useful

<trackbot> Created ACTION-107 - Work with the i18n wg on a concrete description of the data changes that they think are useful [on Peter Saint-Andre - due 2018-10-30].

Addison: We look forward to working with you moving forward on I18N issues such as names

Network Tokenization (continued)

Jonathan: We had an interesting conversation about tokenization yesterday about merging tokenization and card security. The biggest question we had yesterday is: who will be the token requestor?
... payment handlers mostly (we then need payment handlers)? Or browsers themselves?

stpeter: It might be helpful to describe briefly what the roles are in the ecosystem. What does it mean to be a token requestor?

benoit_: The merchant/aquirer needs to be able to request a token that they give to a token acceptor without needing to understand anything in the token itself

Roy: I prefer the answer be both browsers and payment handlers
... one of the original value mechanisms was to enable new players to get into the ecosystem. We differentiate the browser's role as "mediator" from the role as "payment handler" (whether built-in or *Pay).

<MattS__> https://w3c.github.io/payment-handler/#structure-of-a-web-payment-app

<MattS__> see URL for architecture

Rouslan: I kind of agree with Roy - should be able for both browsers and payment handlers to do the tokenization
... I think tokenization should be done
... Suppose the browser does this...here are some questions to discuss and answer:

Rouslan: ... payment handlers probably the best starting point now, but open to talking about in the browser as a bigger product question

Jonathan: With SRC we can answer many of those questions.
... if there is willingness, we can look into this.

stpeter: Rouslan raises some important questions
... I kind of like David_Benoit's suggestion to also think about the token acceptor side
... payment handler is one approach to payment method innovation; that's not the only approach
... AdrianHB's universal token model is an alternative approach
... (or complementary)
... I have concerns about the payment handler; I think having a more generalized approach for acquiring tokens and passing them through is a worthwhile model to explore

IJ: Who wants this?
... do browsers want to do this or would it cannibalize their wallets?
... are there any parties that want to distribute payment handlers that do this?
... I have not heard people stepping up, so we have stalled.

AdrianHB: I think we have chicken and egg around tokenization. If I were interested in seeing tokenization, I would be interested in investing in prototype if it's only going to work in one browser.
... l think tokenization is the biggest driver of payment handlers today
... We either need to focus on built-in payment methods or on payment handlers

Jonathan: Who is using basic card? Why would they not want tokens instead?

AdrianHB: I think they would prefer to receive tokens, but there's no ecosystem to provide them

stpeter: I think we need to understand token use cases more generally

Roy: I am confused why we are coupling payment handlers and tokenization

IJ: Let's speak concretely for a moment, choosing Apple as an example ecosystem. I see three options to get network tokens out there (as we've specified them):

a) Apple Pay supports tokenized-card

b) Safari supports tokenized-card

b) Safari communicates with third-party payment handlers that support tokenized-card

Giulio: Is there a model for network token?
... Currently Apple Pay uses a device-based token; there is also HCE based model

Jonathan: Safari could request a token that can be send to different merchants.
... and another use case where the merchant is requesting the token and it's bound to that merchant.

Giulio: Is the network token model supported by all the networks?

Manoj: Yes

Giulio: What does the dynamic element look like?

Manoj: Full cryptogram
... so processing is similar to our Apple Pay token

Jonathan: Safari would have an agreement with each network...to get tokens and dynamic data.
... but the API is standardized

NickTR: Actually agreement is with a TSP who may not be a network (e.g., with The Clearing House)

Giulio: So we would have to initiate a provisioning process to get a token and give to a merchant (or provider) who knows how to process it.

AdrianHB: The advantage here is that there is easier merchant onboarding.

Giulio: Apple does run time checks...not clear those would happen in this model

IJ: Is this better than basic card (and interesting as such) for Safari?

Giulio: If merchants were complaining about onboarding pain, it might be more interesting. But I think the pain is the processing of the cryptogram.

MattP: What if there were a tokenization scheme that allowed Apple Pay to do what it does today for a merchant who only accepts basic card?

Giulio: Interesting situation. That would address one aspect....merchant adoption...that would broaden the base significantly.
... I think including basic card would be more interesting than "network token"
... How does security work in this model, MattP?

AdrianHB: Assume it's the same token, but instead of merchants onboarding with Apple, they are onboarding with another ecosystem.

MattP: Definitely every merchant today registers with a PSP...tokens or FPANs, there is a registration model (e.g., sign up with Braintree)
... they give me a secret
... would Apple support a system where the network says "Please don't stop your network token; we have a mechanism for you to put that token on our network and give you back an FPAN for the merchant who has not yet chosen to do Apple Pay integration with Braintree"?
... it would adhere to the Apple Pay security commitment

Giulio: Anything that improves security of the base.

IJ: There are 2 stories here: (1) is tokenization a sufficient improvement for browsers? (2) is virtual card generation over basic card something to explore?

[MattP has interesting proposal that the scribe didn't get but will follow up on]

AdrianHB: The incentive for browsers goes up to get tokens if downstream they just return basic card data.

MattP: Then Edge can make a promise downstream to users.

IJ: What goes into basic card plus, Jonathan?

Jonathan: ...dynamic data fields

IJ: I am hearing two paths to pursue as next steps:

(1) Basic card with dynamic data (Matt Pisut's idea, and which has some support from others)

<Jeffw> TCH +1 to the basiccard with token and dynamic data (cvc2)

(2) "Basic card+" (Jonathan Grossar idea)

IJ: We will take this up in the next tokenization calls.

Wrap-up

NickTR: Will take to list or a call the topic of scheduling our next FTF meeting
... Minutes from this meeting available in a few days

AdrianHB: As a group we want to get to a point of being more secure than basic card. This is the first time I've heard interest from all the browsers to return a "token"
... I am happy to hear an interest in solving that.

Summary of Action Items

[NEW] ACTION: stpeter to work with the I18N WG on a concrete description of the data changes that they think are useful
 

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2018/10/31 17:12:46 $