Meeting minutes
Roll call
[Franck hands off Shopify relationship to Rahil Virani]
[Intros from Rahil and Benedek]
WPWG Charter update
Ian: Our revised charter has been approved through 31 July 2025; see the call for participation. Note that because we have no new deliverables, there's no need to rejoin the group.
Ian: I'm glad the approval has happened before TPAC. Regarding registration numbers, I am expecting around 35 people in person for the WPWG agenda, still in development with the co-Chairs. Please register!
Shared autofill proposal
[Presentation by Stephen McGruer]
smcgruer_[EST]: Autofill is typically a browser-specific feature.
… very useful for users in form-based checkout flows, which remain the majority of checkout flows. Especially valuable on mobile.
… our studies show that autofill helps users complete transactions
… I'm presenting today, but lots of work on this done by Chris Schwering who could not join us today.
[Stephen shows a form where some of the data fields are hosted by cross-origin frames: card number, expiry and cvv]
… reasons have to do with PCI-DSS
smcgruer_[EST]: Why is the name on the card field still in the merchant's domain? (Honest question; looking for answers)
(Stephen shows autofill only happens on the name field, even though the browser has more information about saved cards)
smcgruer_[EST]: Autofill historically only operates on a single frame.
Gerhard: Regarding the cardholder name in the merchant domain likely relates to merchant lookup
Steve: I also believe that the name field is on the merchant site is that the merchant wants to retain the relationship
… with the customer (even if guest checkout)
Franck: Yes, that's the reason. On Shopify the 4 fields are in a single iframe. Name on card is not part of PCI.
smcgruer_[EST]: This has been a problem for a long time on the Web.
… some approaches developers have taken to share autofill data include postMessage
… this is complicated and requires invisible fields
… you have to make sure not to override data
… we are also not thrilled with invisible fields
… so the JavaScript approach doesn't really work well
… we've been working on this for the past year or so on Chrome
… other browsers not yet on board but we hope they will do this as well
There are several pieces of the proposal:
1) Fill across same-origin frames. For example, if three card fields are in the same origin, the browser can automatically fill. If you fill a field with an origin "foo" the browser will fill all frames in "foo"
… this feature has shipped in Chrome M116
… we're trying to specify this in a WhatWG's HTML specification.
2) As people noticed in the demo, we filled 3 iframes of embedded PSP origin but not the parent origin (e.g., card name)
… we are assuming that (independent of PCI topics) if a user has visited a parent origin AND the parent origin has embedded frames (and thus trusts them), we think it's ok to fill the parent form.
This is ALSO already shipping in M116.
… this is harder to ship because we are "declaring" some data is less sensitive
3) What if you start from the parent origin (e.g., card name). We can't arbitrarily fill iframes in other origins...that would be a huge security problem.
… we can't automatically fill them. So we are proposing to add to HTML a "shared-autofill" permission policy that a parent can set on frames
… this is secure from our perspective as a browser because the merchant could have just put these fields itself on its page. So as long as the parent says it trusts the iframe, then we think the data can be shared downwards
… this feature has not shipped. It's available behind a flag in Chrome M116
smcgruer_[EST]: So I have some questions for you:
1) In the real-world page I showed earlier, why is the merchant name part of parent frame? (People answered above.)
2) If you are supportive of these three features, please let us know. The TAG has asked for input from the WPWG.
Gerhard: These are named fields in PCI.
… that leads me to the question/suggestion .. does it make sense to elevate PCI fields to another level?
… you can form fill my name / address but please do not fill PCI fields. Some rules are different between PCI and things like GDPR. PCI is much more specific.
… you can treat PCI differently due to regulatory requirements
smcgruer_[EST]: Already in autofill you can tell us types of fields. I would be open to a conversation about HOW to treat these fields differently.
Gerhard: Ability to pass "up"...would make sense to have a separate permission for PCI data
smcgruer_[EST]: I'm hearing that there might be a subclass of "shared-autofill"; something like "shared-autofill-nopci"
David: Expiry is not part of sensitive data. Name and expiry are appreciated by merchants for customer service.
… they like to get back from PSPs the last4 as well as name/expiry so they can do customer service without having sensitive data.
… data sent back up to merchant domain puts them back into PCI scope
… would break agreements they have signed
Andrew: The scope of the expiry depends slightly...e.g., if it's not transmitted with the PAN it's not sensitive, but if it's transmitted with PAN it must be protected.
… cardholder name typically skirts around this
… I think autofill permission makes sense but sounds dangerous without finer-grain protections
… e.g., "these fields have more information / more sensitivity and are controlled in different ways"
… at the moment I don't see any particular concerns....the general concerns are protecting data.
… these types of implementations are currently topics of discussion within PCI WGs
… I'd like to provide more guidance to merchants on this
Gustavo: +1 to proposals that help solve this usability issues.
… name on card is not needed to process a payment. So I think it's not sensitive in the same way. It doesn't even need to be sent for the payment.
… I like the ability of the merchant being able to "opt-in" by trusting fields
… but can an attacker tag iframes?
smcgruer_[EST]: I've heard from a few people that it may be better if we can scope trust: e.g., I trust this iframe to take payment fields but not address fields or vice versa
… on the topic of what can an attacker do - the attacker has to compromise the main/parent frame in order to take over an iframe. But if the attacker has taken over a main frame, you're in much bigger trouble anyway.
… permissions policies have this threat model: as long as the main frame has not been compromised you are safe
Benedek: You mentioned that Chrome guesses the types of some fields whose semantics are not explicitly tagged. What happens if guesses are wrong?
smcgruer_[EST]: Yes, we use heuristics to tell what types of fields are. We usually don't get credit card fields wrong.
… we are more likely to get addresses wrong than payment fields.
… addresses are complex (e.g., some addresses involve references to physical landmarks); we are working on being more inclusive in addresses.
Benedek: Would it be possible to not fill autofill data if the fields are not explicitly tagged?
smcgruer_[EST]: There are so many untagged fields are are likely to to have to use heuristics
<smcgruer_[EST]> To capture a point that was missed; scoping the trust is hard because autofill isn't very well spec'd today - it's viewed as a browser feature. So we split it into addresses/payments/passwords , but thats just how Chrome views it
rouslan: Regarding accidentally accidentally up filling: I think the algorithm that stephen describes only talks about the name and not payment card fields.
smcgruer_[EST]: The problem is if we misidentify a field.
smcgruer_[EST]: For people who know PCI: I assume users sometypes type card numbers into the wrong fields. How is that handled?
Andrew: That does happen. There are PCI requirements for how merchants handle data they get through incorrect channels.
Ian: Steve, should MAG discuss this autofill proposal?
Steve: Let me talk with some people internally.
Ian: How should we respond to TAG request? As a group? As individuals on the TAG's GitHub repo (see w3ctag/
smcgruer_[EST]: My intention is to go back to TAG and give my interpretation of discussion, namely:
a) Proposal is valuable
b) People are interested in further scoping of permissions
Fahad: When you normally autofill an iframe, would you know the URL of the iframe?
smcgruer_[EST]: We do know the origin
smcgruer_[EST]: I would like to bring more autofill conversations into W3C
… would be interested in a group discussion on this.
ACTION: Ian to discuss autofill group within W3C strategy function
Quick description of Payment Request publication plan
Ian: Chrome and Webkit teams have indicated a desire to evolve PR API, and in particular to add back some features we removed before advancing to Recommendation. We have had some discussions about how to do this, especially since the W3C process has recently changed. The current plan, at a high level is:
- Publish the Recommendation text as-is as a Candidate Recommendation Snapshot. (The existing Recommendation will remain available at the URL it was published under.
- Begin to add back features we removed and possibly some minor changes, making this a new "Candidate Recommendation Draft."
- Before advancing back to Recommendation, we would fulfill the usual process requirements of getting consensus over the changes and wide review.
Ian: Now that Apple has rejoined the group, and Marcos is the lead editor of Payment Request, I hope we can make progress on this, and in particular have the new bits folded in by TPAC. This would allow us to more easily have conversations with privacy and internationalization groups during TPAC.
Next meeting
Next meeting: 17 August
No meeting on 31 August