How many people going to the AC meeting?
(12 or so)
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
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
[ 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
[ 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.
[ 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
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
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.
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.