[Demo of detecting errors]
<rouslan> present?
Andy: Granular errors on shippingAddressChange and also retry()
Trent: Why not detect post office box earlier?
Andy: Not part of redacted shipping address
jalpesh: In Apple Pay is Total required?
Andy: Yes, it can be $0.
... for something like Uber, I think it works where total is $0
but marked at pending
Jalpesh: There are scenarios where merchants want the credentials but don't know the final total
https://github.com/w3c/payment-request/issues/858
nicktr: Gathering credentials is not a payment. In EU you need to show the user the Total.
Jalpesh: We should separate the
payment aspect from the collecting credentials aspect.
... when the final amount is decided the merchant initiate
auth
NicKTR: In V1, PR API was to make the payment. We can consider these use cases (where total not known when credentials are gathered) in 1.1
Jalpesh: You need to be able to provide a limited functionality to allow for more use cases (with more flexibility)
Lawrence: How would PR API be useful in Uber use case?
aestes: In PR API, payment item as a "pending" value. In Apple Pay, this leads us to not display the total
https://w3c.github.io/payment-request/#paymentitem-dictionary
<scribe> pending definition: "A boolean. When set to true it means that the amount member is not final. This is commonly used to show items such as shipping or tax amounts that depend upon selection of shipping address or shipping option. User agents MAY indicate pending fields in the user interface for the payment request. "
Lawrence: On the Apple Pay $0 implementation, I was never able to specify $0....
aestes: Recent change to Webkit
Marcos: As we start discussion about feature requests, I would like to remind people that adding features requires resources
Ian: Today is not a decision session; just info gathering, but including prioritization sense
rouslan: +1
[Talking through Candidate Feature List]
<Ian> Kanban board of feature ideas from issues list
<Ian> AdrianHB: One use case was that if I pay in a particular currency, only some payment methods may be available
<Ian> ..I think most common use case would be split tender (e.g., loyalty points + currency)
https://github.com/w3c/payment-request/issues/592
<Ian> AdrianHB: we should figure out the use case driving this with more clarity (e.g., split tender)
<Ian> benoit_: You can use billing address information (through the event) to update the total and currency
<Ian> https://github.com/w3c/payment-request/issues/145
ian: Not split tender. More about ability to provide a discount code and/or voucher
<Ian> Krystian: I still feel this is important
ian: original motivation was that this is not "re-used" data so wasn't same as address etc
<Ian> Krystian: Our studies show that if the discount code is provided earlier, it may reduce conversion rates.
<Ian> (earlier = before calling payment request API)
<Ian> ...which lowers the value of PR API
<Ian> ...I think this issue merits more investigation, but no strong feeling on the priority
<Ian> lte: Merchants should have the ability to discount based on payment type.
<Ian> Itai: Why is form in a page different from form in the sheet?
<Ian> Marcos: Limited UX in the sheet
<Ian> ...UX around unknown strings can be challenging
ian: my recollection of browser concerns here relate to the challenge of capturing ad-hoc data
<Ian> Marcos: You might also want to scan a card while in the sheet (instead of typing a number)
<Ian> NickTR: The issue is really about putting codes in the flow rather than before it.
<Ian> Giulio: We've struggled with this one at Apple Pay.
<Ian> ...we haven't found a strong enough reason to put it into the sheet
<Ian> ...it would obviously be an optional field
<Ian> ...we think of the sheet as something you are in and out of quickly.
<Ian> ...but promo codes create a different psychology...and also there is error recovery if the promo code is not applicable.
<Ian> ...,this leads to not getting out of the sheet as quickly as possible.
<Ian> ...and presenting error messages to the user for inapplicable promo codes challenging
<Ian> rouslan: My recollection of the last discussions on this is that UX challenges notwithstanding, we see this is an important use case
<Ian> ...we do plan to do _something_ about promo codes
<Ian> https://github.com/w3c/payment-request/issues/389
ian: if you look at the spec we
have shipping options which are an enum
... when a user picks and address the merchant gets an event
that allows the merchant to adjust the options
<Ian> Rouslan: In the "in-store pickup" use case, the address is where the USER goes to pick up something at the merchant's store.
<Ian> NickTR: This matches "service pickup" in Apple Pay
<Ian> Justin: I think it's somewhat similar to selecting a coupon. Some stores will have complex store selection. E.g., you can use geolocation. Or a given item in a basket will be available at an address, and another in another. But perhaps there's an 80/20 point we could hit
<Ian> Giulio: I agree that it's complex and probably difficult to standardize in-store pickup. There's probably also inventory check you want to do up front
<Ian> ...we've had a hard time finding rules that are standard enough
<Ian> ...what we've done is essentially use the sheet as a REMINDER
<Ian> ...you do the store-pickup work up front with the merchant in the page; once the user has decided to pick items at a store, the merchant can send an address and label that is displayed in the sheet.
<Ian> ...thus the sheet can show the chosen store and address.
<Ian> lte: To recap - the objective of Apple's implementation is to remind the user.
<Ian> Giulio: Right, just a confirmation
<Ian> https://github.com/w3c/payment-request/issues/480
<Ian> marcos: This issue was to match up with Apple's original implementation.
<Ian> ....is this still relevant?
<Ian> aestes: Today we compose a full name from components.
<Ian> ...I think we would prefer NOT to do that
ian: is this an issue
aestes: no. it comes down to if merchants need the decomposed name
<Ian> Dee: Personalization is extraordinarily important
<Ian> Benoit: But it's a hard problem
<Ian> Aestes: That's an argument for browsers to manage it.
<Ian> Benoit: Decomposed name is only useful for merchant interaction with the user (e.g., "Thanks, Andy!")
<Ian> Ian: Perhaps we could add a "preferredName" field like "Andy"
<Ian> AdrianHB: In many cases, this is delegated to the platform
<Ian> Aestes: In our case we get from contact database (of OS) in decomposed form
<Ian> Puneet: What was rationale for single string?
<Ian> NickTR: Simplicity. Leave it to the consumer to say what their name looks like (according to their preference)
<nicktr> https://www.w3.org/International/questions/qa-personal-names
<Ian> Alaric: This is a challenge from an issuing perspective...names can differ between what appears on a plastic card, a shipping address, and a billing address
<Ian> ...I can have "not my given name" on plastic card
<Ian> NickTR: Also corporate cards
<Ian> Puneet: And gift cards
<Ian> AdrianHB: Question for the networks - would the decomposed name be more useful for 3DS scoring?
<Ian> Puneet: IMO, irrelevant
<Ian> benoit: Does decomposed name matter for payments?
<Ian> Trent: But part of what we are trying to solve for is guest checkout
<Ian> ...you can to personalize it and make it easier for users to create a profile
<Ian> ...decomposed helps us
<Ian> AdrianHB: May be an option is to return decomposed if available
<Ian> Dee: We have to think through the experience on the merchant side.
ian: sounds like ongoing interest
<Ian> https://github.com/w3c/payment-request/issues/537
<Ian> Ian: Anybody doing something like this?
<Ian> aestes: You could do this with apple pay, but only by failing the transaction.
<Ian> ...there's no way to do that through the sheet
<Ian> Trent: We do this today, but not part of payment. It's part of information the user has given us
<Ian> ...the flow happens when you are entering information in before confirmation of payment
<Ian> ...we need to know shipping address because it may also affect total.
<Ian> ...we allow the user to confirm their entered address or to accept the recommended address.
<Ian> Puneet: This is one of those topics where, if everybody does the validation up front, you would not need to do this in the payment sheet.
<Ian> AdrianHB: A key piece of the use case is that the shipper has a database.
<Ian> NickTR: Marcos offered a proposal.
<Ian> https://github.com/w3c/payment-request/issues/537#issuecomment-304562882
<Ian> Marcos: There are UX concerns about showing a new address.
<Ian> NickTR: I am hearing this is a valid use case
<Ian> https://github.com/w3c/payment-request/issues/548
<Ian> Justin: How standardized are the fields? An empty box will not be useful
<Ian> AdrianHB: And if you hard code the label (e.g., "Delivery instructions") it can't be updated...you'd have to add a new block
<Ian> DaveFortney: Could you do this after the flow?
<Ian> AdrianHB: Perhaps.
NickTR: Suggestions in the issue to do after the flow
<Ian> Justin: I don't have a good sense of how common this is for retailers.
<Ian> Dee: It exists.
<Ian> Alaric: GrubHub has this frequently
<Ian> aestes: I've never been confused by a site that has a special instructions box
ian: keep on the backlog, low priority
<Ian> https://github.com/w3c/payment-request/issues/592
<nicktr> closed
<Ian> https://github.com/w3c/payment-request/issues/613
<Ian> Marcos: This is part of a larger discussion. We need some kind of way for browser vendors to be able to share information for testing (e.g., to help with automation)
<Ian> ...and to make it easier for developers to get a payment response automatically without having to click on screens
<Ian> ...there are various proposals
<Ian> ...maybe we have a short string payment method like "test-payment"
<Ian> ...and a set of options that can be used to inform the simulated user experiences
AdrianHB: Is the model captured anywhere?
marcos: Yes in a few places
ian: What are you testing?
... sounds like this is something that can be designed by the
browser vendors and we don't need to discuss it at this meeting.
<Ian> https://github.com/w3c/payment-request/issues/701
<Ian> Lawrence: Could you change the word "Pay" on the button to something else?
<Ian> Rouslan: That's a feature request
<Ian> ...e.g., "pay", "confirm", "subscribe"
<Ian> Giulio: We don't have this in Apple Pay
<Ian> Dee: The Pay button is problematic in the sheet. You may not actually be paying
<Ian> Danyao: What are some examples?
<Ian> - Continue
<Ian> - Return to checkout
<Ian> - Subscribe
<Ian> - Donate
<Ian> - Schedule
<Ian> - Buy
<Ian> Lawrence: Also, non English
<Ian> Rouslan: Does this have to be free-form text, or can we enumerate possibilities?
<Ian> ...this would make the job of the payment handler easier.
<Ian> ...and browser can do translations
<Ian> NickTR: So the question is whether there's a dictionary versus open string
<Ian> Rouslan: My pref is a dictionary, but if merchant say free-form text, that's a different issue
<Ian> Ita: You could also contemplate string length limitations
<Ian> Dee: IMO, the more flexibility the better.
<Ian> Lawrence: Maybe a hybrid solution is that there's guidance
<Ian> estes: We have this concept for the site buttons (but not by sheet) and there we have an enumeration, which allows proper localization. We might want some symmetry with the browser UX
<Ian> Justin: We could start with enumeration and then if we can't solve it then move on to open strings
<estes> marcosc: https://developer.apple.com/documentation/apple_pay_on_the_web/displaying_apple_pay_buttons
<Ian> PuneetS: Suppose merchant can specify the button text. Would a payment method owner have a stake in what the string is? And if so, how do you resolve that conflict.
<Ian> rouslan: I think the way to resolve this is to use an enumeration, where the merchant says "I would like this to be a subscribe button, or a buy button" without specifying the precise phrasing. The button might end up saying "Subscribe with Google Pay"
<Ian> ...the decision from the payment handler might change in the future
<Ian> Trent: The customer is not always making a purchase at time of checkout
<Ian> Rouslan: So the enumerations would include those as well
<Ian> Puneet: The fundamental question is who should control the content of the button?
<Ian> Trent: Merchants are looking for control of the payment sheet in general. This is just one of those things
<Ian> ...if a merchant elects to have a custom sheet, they can have it, or there could be a backdrop default sheet
ian: strong interest in having this
<Ian> https://github.com/w3c/payment-request/issues/859
<Ian> benoit: In some markets we need more customer info. E.g., in Brazil we need taxid and birthday
<Ian> ...that information is sent to tax authorities
<Ian> NickTR: In Finland there's an extra field with your age
<Ian> Ian: Traditionally we have only included things required in many use cases and regions
<Ian> benoit: My use case is even more complicated depending on whether the transaction is purely domestic or cross-border
<Ian> rouslan: There's a related issue of gathering credentials incrementally...e.g., start with country and then requesting additional information according to country
<Ian> NickTR: Is there an explicit opting in for how my data is used in *Pays?
<Ian> Rouslan: RTFT&Cs
<Ian> AdrianHB: Another thing to always determine when we are considering new data collection, is when in the flow you know you need it
<Ian> ...is it something you can ask for in the payment request, or only after someone picks an address.
<Ian> lte: I thought it would be useful to start with our goals (Laura, Dee, Trent)
<Ian> ...then go into merchant considerations when choosing to adopt payment solutions and standards
<Ian> ...then talk about some additional use cases.
<Ian> lte: Both Dee and Trent are on the MAG board.
<Ian> ....MAG members now include 150 or so merchants across US mostly (but some global companies)
<Ian> ...we represent those members with regards to payment-specific matters.
<Ian> ....we advocate on their behalf
<Ian> ...we want to be part of the process of new payment solutions, and earlier in the process
<Ian> ...so we have joined various organizations to get involved more, and sooner
<Ian> ...we rely on merchant expertise through our members
<Ian> ...through our participation here we want to educate you about merchant requirements and also bring back facts to our membership
<Ian> ...with your help
<Ian> ...the general population of payments people in our merchant population is non-technical.
<Ian> ...we are looking for ways to explain work to them (e.g., visuals help)
<Ian> Dee: When you communicate with the merchant community, you need to get outside of tech speak and speak the language of merchants
<Ian> ...one thing I found interesting yesterday was how often the word "merchant" was used; that was fabulous
<Ian> Itai: When we talk to merchants, we will need to translate W3C terms into the terms they know.
<Ian> NicKTR: And language in the US differs from language in UK etc.
<Ian> lte: We (MAG) can offer value as far as communicating to our members
<Ian> Itai: We can help you work on messaging
<Ian> lte: next topic is "merchant considerations" for adopting new technologies
<Ian> Dee: We don't think for a sophisticated checkout experience (such as Best Buy's) there's not a lot left to solve.
<Ian> ...so the question is "what will this API solve"?
<Ian> ...I think it would solve for the most basic use cases...and it does not take a lot off of what we need to do for the whole consumer experience.
<Ian> ...we talked about recurring billing, in-store pickup. Also, for example, we sell mobile phones, which is an extraordinarily complex checkout experience
<Ian> Chris: Does MAG also represent small-to-medium sized merchants?
<Ian> Lte: Some of our members have franchises
<Ian> ...we think that small merchants without expertise or resources would get more out of PR API
<Ian> lte: We try to think of providing merchant POV even though we have large merchant members
<Ian> Dee: We have an education component (including working with NRF)
<Ian> ...in many cases, smaller merchants would use the API through Shopify or similar
<Ian> Puneet: Can you give some additional insights into how you go from concept to execution?
<Ian> ...both Best Buy and Walmart have experimented with payment methods....how do you go from concept to realization?
<Ian> Trent: Even if cost of failure is high, we need to experiment in order to evolve. What would it take for us to pilot something using a W3C PR API? We have like everyone limited resources. So piloting on walmart.com is a higher bar than some other of our properties.
<Ian> ...I would look at use cases that would help the business and make their checkout more streamlined, or to lower their maintenance costs
<Ian> ...Bonobos for example supports a lot more payment methods than walmart.com
<Ian> Dee: I have a similar take to Trent (for Best Buy)
<Ian> ...I would say that we have a willingness to fail. We are testing new experiences all the time.
<Ian> ...there are absolutely some use cases where PR API could fit, and could increase conversions
<Ian> lte: beyond customer experience, there are other considerations such as "flexibility for choice" and "competitive alternatives"
<Ian> ...we support W3C because it's an open standards organization.
<Ian> Trent: What I like about the W3C work is that it's not limited to just cards.
<Ian> ...what we see in the US —especially in the Bay Area— is there's a lot of innovation
<Ian> ...but many of these solutions rely on card payments...that's a gap; if there were something more standardized, that could foster innovation
<Ian> ...so the we are not just innovating on the front end
<Ian> lte: A recurring theme for us around the API is to have flexibility
<Ian> Dee: That dovetails into our earlier flexibility conversation. If something is construed to be a Best Buy experience, it has to fit within a brand-consistent experience for our customers.
<Ian> Justin: I think I am hearing that you can use the API as a checkout in a box. But another role is as an identity broker.
<Ian> ...where more payment stuff happens in merchant-specific flow.
<Ian> ...so two ways to use the API (1) do everything or (2) gather data.
<Ian> Trent: I think we'd like the standard to serve both roles; there are merchants who may wish to use the API in different ways.
<Ian> ...some large merchants may just want the data back, or want the data back at different points of time
<Ian> ...we may also want to keep the integrity of our checkout experience, across different use cases.
<Ian> ...something that happens 1 in a million times, happens 20 times a day for Walmart.
<Ian> ....we need to make the experience consistent, and we need flexibility in the technology to do so.
<Ian> Dee: We think about commerce more than payments specifically
<Ian> lte: Kristy Cook (Target) said, if there's not the ability to brand it as a Target experience it will never fly
<Ian> Alaric: as we are here together to build a v1 spec, there is a tension between flexibility and something that is pilotable...
<Ian> ...how close do you think that the spec is to a state where merchants could do pilots today?
<Ian> Dee: I think there are some use cases today that could be tested.
<Ian> ...we can start that conversation. But right now it's a teeny use case.
<Ian> ...the use case of buying a thing with a card and shipping to our house; with guest checkout
<Ian> Trent: We also are in the basket-building business rather than just buy one thing
<Ian> ...the moment I ask for resources I will be asked for ROI.
<Ian> ...how many users for chrome, safari?
<Ian> ...if you tell me that 60% of my new customers that we don't know today would have the ability to use this service, that's one thing.
<Ian> ...but if it's only 5% that's a different conversation.
<Ian> Dee: I want to reiterate that there is interest from the merchant community that this be successful.
<Ian> Itai: To the question of "how close are we"....we also want to know which payment handlers are available. Is there a checklist available of what you can do today and what you can do in the future.
<Ian> Trent: We are here because we are supportive of the initiative; we need more information and clarity to share it.
<Ian> [IJ hearing strong request for communication materials to answer questions]
<Ian> Trent: You could help us with elevator speech creation
<Ian> PuneetS: Regarding flexibility, I will pick on something in the standard in the interest of sparking opportunities.
<Ian> ...one point mentioned was: are merchants are looking to the API to be a payment facilitator, or the flexibility of getting information.
<Ian> ...rigidity about getting information may be reducing value for merchants.
<Ian> ...having more modularity might offer additional benefits,.
<Ian> [Trent does a demo]
<Ian> Trent: In this demo, I have something in my basket that, due to state restrictions, can't be shipped to my location.
<Ian> ...if I have to throw an error to users that we cannot ship to an address, that will create friction
<Ian> ...so we need shipping address validation independently (and before payment)
<Ian> NickTR: Good use case description; we immediately of course get into privacy issues.
<Ian> Trent: The theme remains "flexibility" in how to use the API.
<Ian> SteveCole: Doesn't diversity of requirements drive demand for modularity?
<Ian> NickTR: How would the consumer know that their zip code has been shared with the merchant through the API? Is there a UI prompt?
<Ian> Itai: One of the things also to look at is, rather than just having one call, there needs to be different interactions to get some of the data before we do a full payment request.
<Ian> NickTR: Granularity
<Ian> Itai: When I load my information into a site or *PAy, you can also have terms and agreements.
<Ian> Tony: Dee, how critical is it for merchants to convert guest checkouts to on-file?
<Ian> Dee: There are major merchants that no longer have guest checkout. Or there are use cases where you can't have guest checkout. It is shifting in the direction of "no guest checkout"
<Ian> Trent: We had guest checkout, removed it, then recently added it back.
<Ian> ...so agree that this is an ongoing debate. We think we can deliver an exceptional user experience if we have information about the user.
<Ian> ...app can make recommendations over time based on user patterns
<Ian> ..the more we know the customer, the better experience we can provide.
<Ian> ...so we prefer registered guests
<Ian> ...our goal is for people to not have to think about payments
<Ian> Dee: Tokens break checkout experiences in some use cases
<Ian> estes: Regarding flexibility and guest checkout; there's a debate about whether the browser should provide addresses and in what cases. But it sounds like there are many use cases where you don't need address information.
<Ian> Trent: If you are not registered, we will recommend store locations and ask for shipping address.
<Ian> ...if you are known to us, we'd not show the payment sheet (except for a new payment method)
<Ian> krystosterone: Would you see PR API having value as an aggregator of payment methods?
<Ian> ...so that your workload is reduced to adding a new payment method identifier and whatever backend processing is necessary
<Ian> Trent: I agree it simplifies some aspects, but we still need backend integrations
<Ian> Dee: So it helps, but the backend is the hardest part
<Ian> Trent: I think that people wanting aggregation would look to a PSP to do that for them.
<Ian> AdrianHB: Assume you just care about the payment portion. Do you think that there's value in the user having a bunch of payment instruments pre-loaded?
<Ian> ...I have a card loaded in my browser.
<Ian> ...and you could get credentials at the end of your complex flow.
<Ian> Trent: Where it would be valuable is if the customer has a profile but wants to add a new payment instrument.
<Ian> lte: I think it's valuable to be able to quickly provide stored card information
<Ian> Trent: Anything that helps get customer through the experience general, all other things being equal, will be desirable
<Ian> ...customers do change their payment methods.
<Ian> ...facilitating that is helpful
<Ian> Lawrence: For that particular use case, do you prefer FPAN or token?
<Ian> Trent: We want FPAN for our market due to impact of debit routing and serving customer
<Ian> PuneetS: The functionality AdrianHB described seems valuable for guest checkout, and the impact depends on the proportion of your guest checkout
<Ian> ...what's interesting is the scenario where you have a relationship with the customer and you add a payment method
<Ian> ...is there an opportunity for PR API to be used to add payment instrument.
<Ian> NickTR: That's not a use case we considered in v1
<Ian> Rouslan: We have seen merchants do it.
<Ian> PuneetS: That might drive value
Editor's note: We also received these notes prior to the meeting regarding use cases; these were intended for discussion and we covered them to a certain extent:
[Adrian Hope-Bailie slides on Web Monetization]
AdrianHB: Web today is a barter
economy
... Fixed costs of payments make micropayments non-viable on
the Web today
... so on the Web we use Ads, bundling, etc.
[Adrian talks about different models, such as "dominance of marketplaces"]
AdrianHB: Interledger solves the micropayments problem. Use streaming payments to pay for something online.
[Demo where you pay a small amount while visiting a site]
[Demo of using a tool, where payment is streamed to a payment pointer]
AdrianHB: Coil business model is
to have monthly subscriptions, but to pay out whatever is
necessary.
... but our particular business model is not the subject of
standards; the standard is just the streaming payment
protocol
<Zakim> rouslan, you wanted to ask what significance does the keyword "twitter" have in the meta tag?
[Demo showing payment handler-type experience with streaming payment solution]
[AdrianHB explains how this fits in with Payment Handler and Payment Request]
Trent: Instead of streaming based, what about paying for N articles from an online newspaper?
AdrianHB: For fixed pieces of
content, the site would have to have something like a preview
and then payment to expand it. Our model is time-based; would
need to figure out how to handle static content.
... The goal is to make this a standard way for collecting
payments, and the user chooses how providers make the payments
for them.
... our expectation is that providers will compete on
servers
... concrete proposals:
- need to define a "stream" payment method
- some way to make clear via payment request API that you want a non-interactive way of handling the request
- in the payment response, new event
[Video demo using ILP in regular checkout]
[Vincent Kuntz slides cross-border tracked payment initiation]
vkuntz: Proof of concept related
to cross-border payments
... traditionally cross-border payments were slow
... SWIFT has introduced a new Global Payment Innovation (GPI)
service
... enables tracking and same-day use of funds
vkuntz: 120 banks live. 50% of
payments on our network are GPI
... $300 trillion sent daily via GPI
... How does it work? there is a unique identifier for each
payment, end-to-end
... GPI has three elements - tracker, observer, directory
rouslan: How does this relate to ACH?
vkuntz: For GPI, banks are creating payment instructions; SWIFT is doing the transfer
[Discussion of settlement]
Giulio: I have a question on the use case. User has a US dollar account in a German bank sending money to USD account in Germany?
vkuntz: Yes
nickTR: What's new here in the payment method response is the id for tracking
vkuntz: Advantage to users is the
ability to do cross-border payments
... merchant has money in account 15-minutes later
... (in most cases)
<Zakim> rouslan, you wanted to ask whether the cross-border part of this can be abstracted away, so the existing credit transfer spec possibly can be reused
[Vincent maps to PR API]
Rouslan: Could credit transfer spec work?
Vkuntz: That could be a
foundation, yes.
... but you need a bit more data
AdrianHB: How does merchant determine that debit confirmation is something they can trust; it's not their bank.
NIckTR: The unique reference can be used for tracking
srini: Similar features between ILP and GPI re: async
NickTR: WebAuthn went to
Recommendation a couple of weeks ago. The Web Authentication WG
has begun discussions of next features
... one topic that came to our attention was to establish
the importance in payments flows of doing WebAuthn from within an
iframe
... e.g., Stripe had indicated this as a priority feature.
Ij: Jeff Hodges (Google and a WebAuthn representative) is here; can tell us about what's coming up and we can opine about the priority
Jeff: You can do webauthn in an
iframe when the origin is the same "all the way to the
top."
... otherwise, if the parent origin is different, then it won't
work.
... we understand there's a demand for this; Mastercard
(Jonathan) confirmed
... are there more complex use cases?
... for WebAuthn Level 2, we are looking to relax the
restriction.
... the restriction is there because doing "powerful things" on
the Web in an iframe without additional protections is risky
due to click-jacking, script injection, and other attacks
... there has been work recently to mitigate those threats, but
the relying party that wants to do powerful things needs to do
extra stuff to protect themselves.
... our current outlook is that we need to scrape together the
stuff that the instantiator of the iframe ought to do, and
modify the spec so that it won't create an error when there's a
cross-origin stacking
... iframe should use intersection observer v2
... the framer and the framee need to have some sort of trust
relationship (between them)...and how is that
established.
... adjunct to that is careful deployment of feature policy and
permissions.
IJ: Can vendors speak more to iframe use case?
Puneet: Today the landscape looks
like consumer brands that are authenticating their users
independent of the payment flow (e.g., for regulatory
reasons)
... or merchant can authenticate credential being used through
open banking APIs or 3DS
... however, I think the idea of delegating the authentication
authority to the consumer service is a new concept that's being
floated by some
... I don't think it's been sorted out yet, but I think
WebAuthn could play a role in what that works like. But I've
not seen a go-to-market solution
Justin: So for step-up for 3DS, WebAuthn would not be considered a sufficient approach?
Lanny: That is correct.
Jalpesh: If you are purely
talking about authentication, it's either done during
provisioning of credentials, ...but during transaction it's
3DS
... it's an issuer decision what authentication can be
used.
... I think it's important to delineate credential
authentication and user authentication
... for regulatory requirement, you can use user authentication
as a proxy for credential authentication
Rouslan: How do they differ?
Jalepsh: In general, the notion
of what happens today when I use *Pay is similar to delegated
authority
... the issuer has delegated authority to the *Pay upon
enrollment
Tony: I would debate that we have delegated
Jalpesh: Credential authentication is when the issue authenticates the credential
Tony: If I'm on a mobile phone and it triggers 3DS, authenticating with my thumb does not say it's me. As a bank we will be authenticating the credential.
Puneet: I would say that when you
are doing payment credential authentication, you are verifying
that the cardholder is the agent that is accessing these
credentials or authorized their use
... whereas user authentication is "this is who this user is
[independent of credentials]"
... In theory it's the issuer relying on a 3rd party identity
provider...and the risk is that the user does not have the
right to use the credentials.
AdrianHB: But if I enroll in a bank and link to my google account?
Puneet: One could argue that only the financial institution or issuer can do the definitive check on authenticating the user has the right to use the credentials
Tony: There is some
device-binding
... when I move to a new device, the cloud-based token has to
be bound to that device. And as an issuer we should have the
opportunity to step-up to what we know is a trusted location
and as kid the user trusts the device.
... we are not, as an issuer, in a position to know whether the
biometric that was used is good
AdrianHB: As the bank, if you are the payment handler provider, or the payment handler inserts an iframe from you the bank and you do WebAuthn, would that be interesting?
Tony: Yes, I think that would get more interest
Puneet: And that's close to 3DS.
estes: Payment request allows
framer to permit PR API in iframe. But we don't have the
inverse, where the iframe can say "I allow the framer to use me
for PR API."
... threat landscape is bad actor top-level domain;
click-jacking
... so I wonder whether the one approach here is to ask PR API
to increase security
JeffH: Web payments is not the only place where people are thinking about this issue
[Discussion of Apple Pay with Stripe integration, and post message]
ian: That sounds like feature policy in the other direction? I don't know where that gets specified?
estes: I think it's content policy?
Marcos: Web App Security Working Group
<Zakim> rouslan, you wanted to express preference for iframe to specify whether it can be included by a parent iframe for payments
rouslan: We haven't really
measured the proportion of PR API users that fall into the use
case of different iframe origins doing the payment
request
... without having measured that, I would nonetheless
hypothesize that we would break some sites if we enforce same
origin policy.
... I would support some escape hatch where the iframe states
that it can be used but by default it would be prohibited
... I think that feature policy work would be interesting to
see whether it applies here.
... could feature policy work be applied down-to-up?
AdrianHB: When we talk about WebAuthn being in an iframe, are we mostly talking about it in a payment handler context?
IJ: Not just for payment handlers.
I think I've also heard a use case
where the merchant gets back some data, then does an
authentication as input to a 3DS risk analysis; that could be
done from an iframe within the merchant site.
... but I would confirm that use case with brands
PuneetS: I think that in an EMV
approach to 3DS on the Web that leverages an iframe for
authentication by the bank, that introduces a lot of changes
from a merchant perspective around user experience and
security
... I think WebAuthn adopting a similar approach in the payment
handler might have the same adoption friction.
[NickTR represents some comments from Adam Solove]
scribe: iframes often used to fingerprint devices, but an unfortunate side-effect is to reduce fraud reduction tools efficacy
[JeffH talks about Digital Asset Links in Chrome]
JeffH: It keeps bubbling up IETF:
if I have domain A does that represent the same controlling
policy authority as B, with whom I am interacting.
... currently, the nominal internet-based answer is if they
both chain up to the same Effective TLD (ETLD)
... there are more and more use cases where if they are in
disjoint parts of the tree, we would like to be able to state
"yes, these are part of the same policy authority."
... digital asset links is one approach to answering
that.
... I think we need a standard way of doing that, and it should
be done through DNS.
... see also DBOUND: DNS Administrative Boundaries Problem Statement.
Yuri: We started working on this
in January; we have an alpha preview. Long term vision is to
build a new browser on mobile.
... the two pillars are privacy and new payment models.
... the first step is Coil and then other Interledger
... we want to be mindful of open standards and existing
players
... want to be a playground for new standards for a UX
perspective
nickTR: Can you say more about
other crypto?
... what might that look like ?
Yuri: We'll partner with wallet providers, and user can load currency into the browser.
TPAC 2019 takes place 16-20 September in Fukuoka, Japan
PROPOSED: the WPWG will meet 16-17 September during TPAC. (No objections to the proposal.)
NickTR: TPAC is a great
week
... Weds is an unconference + plenary so you can meet with
people and see what else is going on
AdrianHB: Also, the rugby world cup starts on 21 September!
Ian: Next WPWG teleconference is 18 April
... when we will recap the meeting and priorities, etc.
<JeffG__Discover_> Thanks everyone
NickTR: Thanks to all for traveling and to our host Visa [applause]
[ADJOURNED]