Hi - can you clarify where this work is currently happening? Is this slated to be done in WICG? Has there been any engagement on this topic with other engines / browsers?

Thanks for bringing this to our attention. We looked at this during our F2F, and overall we are happy with this. It solves an immediate user need, which is being able to autofill cross origin forms, which as far as the user is concerned should work like any other form.

We have a couple points we'd like to discuss here, both of which are likely out of your immediate control but would like to see some progress on.

1. Interest from other implementors. This seems like a useful, safe feature which would be more powerful if at least one other implementor is interested in implementing this (setting aside the depedency on permission policy, which is a dependency).
2. We do see the immediate reason why multi-frame forms is a thing, but we would like form domain experts to think about a future direction where we move away from this somewhat convoluted architecture. We understand the proposal is working around layers of limitations, but we feel like it shouldn't be this way.
3. In an ideal world, the solution to (2) might be web payments.

As @annevk said elsewhere, autofill "is a user interface feature and as such the call as to whether or not to make it work in a particular case is with the user agent and not the HTML Standard." If some browsers' autofill doesn't work with fields in Shadow DOM, for instance, that seems like a bug in such browsers, and not with the spec.

Thank you all for the feedback and comments!

Re @torgo

We intend to pursue this in the WHATWG as part of the HTML spec, and are looking to drive consensus on the autofill definitions within that group.

Re @cynthia

1. The final positions on the proposal from Mozilla and Apple are pending and discussions are ongoing.
2. We agree. We suppose this would need cooperation of the implementors, payment industry, and payment service providers.
3. Acknowledged.

Re @hober

Thanks Tess (and Anne!); we do appreciate and agree that autofill is a user interface feature. However, we think there is value in giving web developers some structure around what they can roughly expect, and in particular we think specing shared-autofill as a clear (though non-binding) signal to the browser is valuable. Much like how autocomplete="cc-number" is a valuable signal for web developers to know about.

We're happy to work with Anne to find the right middle-ground of what to spec – see our latest reply in the WebKit request for positions where we changed the text, and we can keep iterating on that!

Hi folks – We discussed this in today's TAG breakout.

We remain concerned with the level of information available to the user about what they have agreed to share with whom via auto-fill. Is it possible to advise UA providers to surface this information to the user in some way "are you OK with sharing your cc number with ecommerce site who uses payment provider as a payment provider?"

We also remain concerned about the multi-stakeholder buy in. If this is going to be adopted by the industry then we'd like to make sure it's widely adopted across browsers.

Apart from that can you let us know any other status or updates?

Hi Daniel,

We remain concerned with the level of information available to the user about what they have agreed to share with whom via auto-fill. Is it possible to advise UA providers to surface this information to the user in some way "are you OK with sharing your cc number with ecommerce site who uses payment provider as a payment provider?"

We've considered this, but in the use-cases we see so far, we believe this wouldn't help the user in the frame-transcending (payment) forms we see today. There's a large number of payment service providers (900+ according to Wikipedia). And the PSP origins are often hard to recognise because they tend to be quite bulky (some examples: assets.braintreegateway.com, secure-magenta1.be2bill.com, checkoutshopper-live.adyen.com, request.eprotect.vantivcnp.com, epgjs-rendercashier.easypaymentgateway.com).

We also remain concerned about the multi-stakeholder buy in. If this is going to be adopted by the industry then we'd like to make sure it's widely adopted across browsers.

We don't have explicit statements from WebKit or Mozilla.

However, payment service providers have voiced their interest. Happy to ask them to chime in here if you feel this is relevant.

Apart from that can you let us know any other status or updates?

I think the HTML PR is close to getting approval. We've extended the example and note to elaborate when and why a browser many decide to fill across iframes.

Hi @schwering

However, payment service providers have voiced their interest. Happy to ask them to chime in here if you feel this is relevant.

I think it would be good to understand the feedback and "pull" from relevant stakeholders (i.e. service providers). We'd also suggest requesting feedback from the Web Payments working group if that's not something you've done already since this is so squarely in the payments space? Looping in @ianbjacobs on this.

We'd also suggest requesting feedback from the Web Payments working group if that's not something you've done already since this is so squarely in the payments space?

Putting on my Web Payments WG hat for a moment (whilst acknowledging I also work for Chrome/Google, and alongside @schwering on this proposal):

A desire for autofill to work better for payment forms is definitely common feedback I have heard from payment service providers (PSPs). I would say they have two main needs:

1. Adhere to security best-practices and regulations on processing credit card information (particularly PCI DSS). This results in a need/desire to isolate the merchant from card data (credit card number and CVC being the most sensitive), which is why it is common for PSPs to offer credit card input fields isolated inside of iframes (such as Stripe Elements or Adyen Components*).

2. Meet their merchants' needs for customization of the provided checkout flow primitives, such that a merchant can build an experience that matches their own brand. This leads to a few sub-needs, including:

   • Separate iframes for each field (cardholder name, credit card number, expiry, CVC), so that the merchant can arrange and style them as needed.
   • Some less-sensitive fields to be owned by the merchant (most often cardholder name), since the merchant may need this data directly for e.g. aligning with shipping info.

From a Web Payments WG perspective (but not speaking officially on their behalf), we certainly believe that this status quo is not desirable, and we have long tried to build APIs in what we think is a better direction such as Payment Request (and the now-deprecated basic-card payment method) and Payment Handler. However we also should recognize that so far we have not strongly succeeded in our efforts, and in my opinion we should also meet the industry where it is at (and provide better services to users on the web!) where needed. As such, I personally would hope that the Web Payments WG would support this effort.

* These are intended as examples only and do not imply specific endorsement of this idea from Stripe or Adyen. As @schwering noted, we can ask for official statements of support from PSPs be provided if desired by the TAG.

(Chrome hat back on)

I'm interested to understand the TAG's concerns a little deeper. I can see three main scenarios where data-sharing may be a concern:

1. User initiates a fill on https://main-frame.example, and due to the shared-autofill permission policy proposed here, the browser fills some info down into fields in https://iframe.example (which the main-frame has given shared-autofill to)

• To me this shouldn't be a concern, because nothing today stops https://main-frame.example from just hosting all the fields itself and then postMessaging the supplied data to https://iframe.example

2. User initiates a fill on a frame https://frame.example, and due to the same-origin autofill model proposed here, the browser fills across to fields in other https://frame.example frames (could be iframes, could be main frame).
   • To me this shouldn't be a concern, because these same-origin frames could just postMessage to each other anyway.
3. User initiates a fill on https://iframe.example, and for some less-sensitive info, the browser fills some data 'up' into fields on the main frame https://main-frame.example
   • I can see this being a concern, as that the user is technically sharing info with site A and the browser is silently sharing the data to site B
   • However, this seems like more of an 'iframes are generally scary' concern, in that as a user you basically never know if particular content (or a text input!) you see on a page is from the main site or an iframe it has embedded. The web roughly requires that you transitively trust the main-frame to not embed things that might try to trick you!
   • Put another way, we don't warn users when they type information into an input field that is inside an iframe, or just hit a keyboard key when an element inside an iframe has focus. This doesn't seem fundamentally different.

As a side-note, to me there is also the practical consideration that autofill already exists today as a browser feature on multiple browsers, some of which are doing behavior like this. Autofill is also mostly un-specified and non-interoperable across browsers, which makes it opaque/difficult for website developers. Whilst it looks like fully standardizing it will be unlikely to happen (Apple have stated that they consider it a browser feature), I think it would be positive for website builders and the web if we could standardize at least some sub-part of the behavior for them to rely on!

@schwering and @stephenmcgruer, although you have likely already received input from some stakeholders, would you be interested in a presentation of this work at an upcoming WPWG call for additional feedback or expressions of support? (We could make a special effort to get PSPs to attend that call.)

@schwering and @stephenmcgruer, although you have likely already received input from some stakeholders, would you be interested in a presentation of this work at an upcoming WPWG call for additional feedback or expressions of support? (We could make a special effort to get PSPs to attend that call.)

@ianbjacobs - I'm happy to, or to support @schwering in doing so. We do already have input from multiple PSP stakeholders, but always happy to hear from the WPWG too :). I'll follow up with you via email.

Hi @stephenmcgruer - thanks for your comprehensive and thoughtful responses. Indeed, it's scenario 3 that we're concerned about. Granted, this is a behaviour already associated with iframes, however we're talking about users' credit card details being auto-filled into these iframes so I think this deserves some additional scrutiny. From a "leave the web better than you found it" point of view, how his this feature making payment autofill more secure and more transparent to the end user?

The Web Payments WG will discuss at their 3 August call: https://github.com/w3c/webpayments/wiki/Agenda-20230803

Hey folks; sorry for the delay here in replying. Starting with my WPWG hat (will reply with my Chrome one following :D):

The WPWG discussed this issue at our August 3rd call (minutes). Overall, we heard the following main points (my own summary):

• It is necessary for merchants to be able to iframe in PSPs to handle credit card data, to avoid merchants being subject to PCI DSS requirements.
• It is also necessary for Cardholder Name to remain on the merchant origin - two reasons we heard were that merchants need that relationship with their customer directly to provide customer service, and also that they may be themselves able to pre-populate that piece of information in certain cases (e.g., a pre-existing customer relationship). Having this field on the merchant origin is allowed because cardholder name is not covered by PCI DSS.
• The inability for autofill to fill checkout flows with iframes across a merchant/PSP is known pain-point and there was general support for fixing it, including the three scenarios I covered above (filling 'across', filling less-sensitive data 'up', and filling 'down' - the latter requiring a permission policy).
• There was a suggestion made that one should be able to constrain the shared-autofill permission policy to certain 'types' of data, e.g. "only fill address autofill down into this iframe", or "only fill payments autofill down in to this iframe".

Attendants of the meeting included representatives from a few merchants and the Merchant Advisory Group, some credit card networks, some PSPs, and the PCI Security Standards Council. This list does not mean any particular entity approved of the proposal outside of what is captured in the minutes, but just to give an idea of what the audience was.

Now putting on my Chrome hat :)

We believe that the WPWG discussion shows significant need and interest, which aligns with what we have previously heard from other specific payment industry members. In the WPWG discussion (although not captured by the minutes, so of course treat with distrust ;)) we also covered that whilst the WPWG believes in finding 'better' (smoother, more private, more trustworthy) solutions for payments on the web, the group also acknowledges that payment forms are a huge part of payments that is going nowhere soon - and addressing pain points there has value for both web users and the businesses.

I think there are two points we need to speak to - firstly, one suggestion from the WPWG comment, and secondly the outstanding TAG comment re sharing 'upwards'.

WPWG suggestion to constrain shared-autofill

In the WPWG discussion, there was a suggestion to constrain shared-autofill if possible, e.g. to be able to say "I trust this iframe, but only for payments, don't give them addresses".

Although we support the idea of trying to constrain in this way, we don't think it is currently feasible:

1. There are no broad categories of autofill types specified today, and the path to specifying them seems unclear given autofill's historical status as a browser feature. It happens that Chrome generally defines our supported autofill types as 'addresses', 'payments', or 'passwords' today - but that's a purely internal splitting and is subject to change (and there are fuzzy boundaries too, e.g. your name could be both payments or address data!).

2. The autocomplete attribute does give some very specific types (e.g., cc-number), but those are incomplete today - that is, browsers recognize more types of data than are expressable via the autocomplete attribute. In Chrome we're working to correct that (e.g., we have ongoing work for specifying more address-related attributes, and also are looking at specifying things like IBANs), but there will almost definitely always be a race where new types are heuristics first, then formally specified later.

3. More technical (rather than ideological), this isn't (I think?) currently possible with the permission prompt syntax - there isn't a way to specify sub-tokens of a permission prompt type. We might be able to introduce a very long list of permission prompts as a hack, e.g. shared-autofill-cc-number, shared-autofill-house-name, etc, but this would get very unwieldy for developers.

As such, Chrome's current position is that we are sympathetic to this idea, but do not believe it feasible/practical. We are open to hearing ideas if anyone has them!

TAG's recent comment on the 'fill upwards' angle

This comment, where @torgo relayed the concern on sharing less-sensitive data upwards from a fill initiated on an iframe to the main frame.

We appreciate the input and do acknowledge the responsibility to leave the web better. We think that this proposal is still an improvement over the status quo, as the only tool for developers to achieve this today (without browser support) is to postMessage from the iframe to the main frame. When developers do that, the sharing is invisible to the user, whereas with this proposal the browser is able to show an autofill preview that helps the user understand what data is being filled. (We acknowledge that preview will not make it clear to the user that this sharing is across frames, because generally iframe boundaries are invisible to them already).

We also note that the proposed spec text already allows for a user agent to not fill a given field, and also that nothing prevents a user agent from choosing to display a warning to the user if it desires. If the TAG thinks it would help, we could add some note to the spec advising user agents to consider this angle, but we think it should be at most advisory and not a formal should requirement.

We look forward to a reply from the TAG, and thanks again for your patience and input!

Hi Stephen - thank you for this really clearly written summary and response to our feedback - it's greatly appreciated! We discussed again in today's TAG breakout. We're still concerned that this is a stop gap in anticipation of WPWG coming up with a better long-term solution? Do you have an idea for how we can stop the stop gap from becoming the de facto permanent solution?

Thanks Daniel. Speaking not on behalf of the WPWG here (I'll let @ianbjacobs answer from that perspective, if he wants), I see a few angles on this myself:

1. Firstly, market forces. In general, credit card forms are declining as a percentage of payments on the web (though they're still a large chunk, which is why this is worth doing!!), especially in non-US markets. They're being replaced by payment wallet apps (e.g., PayPal, MomoPay, ApplePay - varies wildly by geography), by Buy Now Pay Later apps (which are basically a form of payment app), and by government-backed schemes such as PIX, UPI, or PayNow.

   1. For the payment apps, we on Chrome have long invested in trying to make this market work better for both users and developers, with our continued investment in Payment Handler to support an open ecosystem of wallet apps. This strategy is still struggling to be frank, but we're committed to it and would love to see it develop further.
   2. For the new government-backed schemes, I personally would love to see the WPWG involve itself further in how the web might better support these schemes - where commonly today they are heavily QR-code and app-based. In Chrome, we have some ideas percolating on how to support better integration with the open web, and will share those with the WPWG as they solidify.

2. For credit card forms themselves, I personally still believe that Payment Request and the 'basic-card' payment method was the right idea, just perhaps executed wrong. I would like to see a future where we give websites an API to access the users billing and payment details (with the users express permission and clear UX, of course!), but where we address the concerns that merchants had with basic-card. I'm honestly not sure how to advance that future in the WPWG at this time; but from our side we'll keep sharing ideas :).

I hope that is a reasonable answer - I know point (1) is sort of a 'side step' but I truly believe the market forces matter a lot here! :)

Hey @torgo, if I understand the concern the TAG has here, it's not restricted just to any cross-document filling cases, right? In the simple case of a 3P iframe with a <input type=cc-number> field that the user clicks directly on, your concern would also apply there too. Is that right?

I suspect that's where the gap is here. @schwering is focused on the scenario of cross-document autofill (taking the established behavior of same-document autofill as fixed) but I think TAG is raising a good point that we should take a step back and think about articulating and possibly improving the security model for autofill in 3p iframes generally (even the simple single-document case). Is that right?

Hey folks. We've been discussing this situation among a few experts in the Chrome team and we think the fundamental big-picture challenge here is that an <iframe> implicitly indicates a 3P is trusted to both present information (draw pixels) and collect information (input), potentially even highly sensitive information, with no ability to separate these concepts. This is particularly problematic given that 3p iframes are used extensively for use cases that absolutely should not be trusted to collect PII (ads) and for those that should (payment forms).

Ultimately users can really only reason about a trust relationship with the top-level origin (what's displayed in a URL bar) and that origin needs the ability to delegate trust appropriately to it's 3P dependencies. This is pretty obvious with behavior like accessing the microphone, going fullscreen, etc. But autofill is fuzzy - not really a platform feature on it's own, but a UA feature for helping to automate the platform feature of accepting input from the user (as @annevk has pointed out).

So we're thinking perhaps the right long-term model to be aiming towards here is having sites indicate which of their 3P dependencies have a legitimate reason to accept PII from the user at all (credit card numbers, phone numbers, e-mail addresses, etc.?). So perhaps instead of a shared-autofill permission policy, we'd introduce a more generic pii-input permission policy. It would mostly be up to UA implementations to decide what additional protections to offer users when they seem to be entering PII into a 3P iframe that hasn't been marked as trusted to accept PII, but we could spec such a policy as a signal to the browser to treat the 3P as it would the 1P for any such purpose (with the normal permissions policy argument that an embedding site could always implement it via a postmessage channel anyway - so better to just let them state the trust declaratively). We wouldn't be proposing any particular breaking change here, but such a policy would open the door for UAs to reasonably start warning about questionable PII disclosure practices (perhaps even manually typing a credit card number into a sandboxed iframe) with the help of an explicit API for embedders to indicate the trust they have in their 3Ps for disabling such warnings.

In Chrome we already support an identity-credentials-get permissions policy for indicating when a frame should be trusted to use the FedCM API to collect identity information. We now think that was probably overly specific, and we could migrate that to pii-input as well. After all, the threat is all about accessing the user's identity under the guise of top-level origin and so whether the user is typing their e-mail address or logging into their e-mail provider, the principle is the same (though of course UA impl details may differ given the practicality of web compat).

For the extent to which folks decide it makes sense to specify aspects of autofill (eg. @annevk seems OK with having an "eligibility for autofill" section in HTML), we could include this pii-input policy in the definition. In the long run we'd love to be able to say that autofill is never enabled on frames that lack pii-input, but taking steps in that direction would need a careful breaking change plan and so is something we'd aim to work towards over an undefined timeframe.

Any thoughts on this high-level design framework? @schwering has been trying to address this payments use case for upwards of a year now so I don't really want to slow him down further, but he's agreed to reframe his proposal in this direction if y'all agree with me that it's a better long-term vision to be taking a step towards here.

Just a note: we can make time on Monday or Tuesday at TPAC at the WPWG meeting to discuss this if people would find that useful. (Tuesday afternoon is particularly good.)

Thanks Ian. I'll be there and happy to present for such a discussion if there's interest.

A few of us met at TPAC to discuss this: @torgo, @stephenmcgruer, Gerhard Oosthuizen, @cynthia and myself. Here's my summary of the conversation, please let me know if I missed or mis-recalled anything.

First Dan said the TAG wanted to understand how we could help web payments shift towards something better than forms long-term. We all agree that entering strings into text fields is a sub-optimal user experience for completing a payment. @stephenmcgruer described the many years of efforts from WPWG and others, and how the industry is continuing to shift towards payment apps - whether via PaymentRequest or some other mechanism on top of web platform primitives. We talked a bit about things we may (or may not) be able to do to further accelerate a reduction on reliance of input fields, but I think there was agreement that input fields weren't going to just go away anytime soon. Certainly @stephenmcgruer and I intend to continue investing in approaches in Chrome to help meet the needs of the payments industry outside of input fields, but feel we need to address this tactical and pragmatic issue with payment forms in parallel with that.

Secondly we discussed my proposal above to shift the policy away from a nuanced implementation detail of autofill (shared-autofill) to more of a trust model for the embedder/embedee relationship around collecting user data. We heard that pii-input was a bad name because "PII" has a very specific legal meaning we wouldn't want to confuse things with. Otherwise Dan said he'd like to discuss this more with the TAG and get back to us ASAP.

On Chrome, we'd like to proceed with some urgency in this direction. Our current thinking is that we'll update our proposal to use the permission name input but defined in a way that gives the user agent latitude in deciding which forms of "input" are risky enough to disallow in frames lacking this permission. Frames with the input permission would be expected to accept all forms of input exactly as if they were operating in the top frame. In Chrome we'd start by only gating new automated input scenarios like shared-autofill on the input permission, but over time we'd explore whether there are existing classes of input we could begin to warn about or restrict when this permission is lacking. We welcome feedback on this approach, and I'll post pointers here as we proceed down the path of trying to ship this.

Hi @rbyers - Discussed briefly today and there is rough consensus that this is the right approach. We'd like to see it written up in a revised proposal – is that in the works?

Great, glad to hear it @torgo! I'm personally excited about taking steps towards making the web's model for user data acquisition more explicit...

Yes @schwering is working on an updated proposal but it may be delayed a bit now as something more urgent came up for him. We'll ping this review whenever the explainer and spec PR have been updated. But also this is really just a change of positioning / long-term goal (and policy name) with the immediate next step otherwise unchanged.

Hi @RByers! Just to clarify, after a quick conversation at our plenary meeting today — we would appreciate it if you could explore some abuse scenarios in your updated proposal. We had some concerns, and would really value your thoughts on how to mitigate any potential problems. Huge thanks!

Hi @hadleybeeman, do you mean improving on the existing attack vectors section of the explainer which focuses on how the narrow case of autofill split across frames could potentially be abused? Or do you mean broaden the abuse discussion to autofill in 3p iframes generally (i.e. status quo in multiple browsers) and how the new proposal gives a path to potentially reduce that risk over time? Or maybe both?

Hi @rbyers - we just discussed in TAG plenary today and I think what we're asking for is more the first thing - expansion on the existing attack vectors discussion - although in my view "attack vectors" may be too narrow a framing. What we're concerned about is general abuse scenarios of this new proposal: given that this new proposal is in place, what are the abuse scenarios, including by actors who may be "legitimate actors", and what are the mitigations against those? In other words, how may this be mis-used by players in the web ecosystem?

Hi @rbyers - we were just briefly reviewing status on this. First of all, has there been any update that we should be aware of? Should we be re-reviewing at this point?

Hi Daniel! I'm currently revising the proposal, broadening its scope from autofill to (keyboard) input in iframes. I'll update the thread here when I have something to share.