triaged and assigned issue to us and labeled it

Sangwhan: I think this is very useful. Multi-frame forms seem very complicated. Dan.com can say "sangwhan.com is my trusted payment provider so sangwhan.com forms can be autofilled if they are embedded in dan.com"... The pattern itself we need a long-term solution for .. because this is too convoluted.

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 two concerns 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.

Dan: +1

Dan: They responded to feedback that we left. Comments adddressed. Question raised by Tess about suitability for standardisation. They make a compelling argument that it is appropriate.

Sangwhan: user expectations.. could argue that the behaviour of autofill should be consistent between implementation. Or it could be entirely implementation dependent. Currently lots of heuristics and magic logic. Even in standard forms. In payments there is a thing called PCI -- payment processor has to be the recipient of the card information. You can't take care info into an input field on your site and post it over. If e-commerce site wants to customise the style... you can't really style an iframe. So, each of these input boxes are small little iframes: credit card number, name, etc. And the iframes are sitting on the payment provider, and the style is on the e-commerce site.

Dan: how does this overlap with eligibilty for autofil?

Sangwhan: You want to double-key autofill, for this payment provider WITH this e-commerce site. E-commerce site delegates to payment provider to let this through.

Dan: sounds reasonable. Shouldn't they be using web payment, etc.

Sangwhan: I'm sure they've had numerous discussions with the payment providers about what is possible.

Look at the example code... It's [difficult.]

Hadley: as a user how do I know that the cc number goes to payment provider as opposed to e-commerc provider.

Sangwhan: as a user you're sabving it on e-commerce site but it's double keyed.

Hadley: but e-commerce site doesn't see the data.

Sangwhan: as a user you don't see that?

Dan: it's covered by the e-commeerce site saying this is PCI compliant.

Hadley: still the user doens't know who they're giving this information to...

Sangwhan: they want it to auto-fill all fields at once...

Hadley: I am concerned we're breaking some rules of the web to satisfy this one use case.

Sangwhan: it already happens... but just for one iframe not for individual iframes.

Hadley: what if an ecommerce site uses a payment provider that I don't want to use... I've lost my ability to make an informed decisiom...

Sangwhan: if ecommerc site is in a country that requires it to be compliant then...

Hadley: what if the field is for something else...

Sangwhan: you wouldn't use it for something else...

Hadley: I think what you're saying makes sense...

Dan: could the browser prompt the user with both the ecommerc site identity and the payment provider site identity?

Hadley: I think that would help with my concerns, of users not knowing who they are giving their info to...

Sangwhan: defining UI in spec...

Hadley: could be non-normative rather than designing specific UI...

discussion of if it's a UA UI thing

Sangwhan: underlying complexity - but at the end of the day user's just want autofill to work.

Dan: users want to pay for stuff in an easy seamless way.

Dan: if other UAs think this is a UI issue and not to be specified then it's up to the proposers to convince them.

Dan: I still think it's worth saying "let's take some of this energy and push people to web payment"

Sangwhan: we said that already.

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.

Dan: leaves comment

no feedback since last week

Dan: response from requestor 4 days ago... HTML PR "close to approval". Support "from payment providers."

Hadley: I think it's weird... that it's coming from WhatWG and google... saying that payment providers are enthusiastic about it... is it not something that the payments wg / cg should be interested in?

Dan: ask for some feedback form payment providers?

Hadley: if there is signifigant pull-through - next step would be to connect with other payment activities rather than doing it in isolation.

Dan: ask them to run this by the Web Payment CG ?

Dan: leaves comment

Dan: they fed back on my comment from 2 weeks ago. Number 3 is the thing we're concerned about.

Dan: leaves comment

Dan: Ian has said web payments wg will be discussing in their 3-august call. Maybe we bump this to next week.

bumped

Sangwhan: we have responses..

Dan: this is good well written information. They argue it's better than the current situation, but I'm left with the feeling this is a stop gap. I'm concerned it can become the permanent solution. How do we stop that from happening?

Hadley: that's something we talk about regularly. We dont' have a design principle about that do we?

Sangwhan: Nothing can really stop that from happening.

Hadley: We could design more permanent solutions..

Sangwhan: they're designing around pci restrictions. It's either do this or don't do anything.

Amy: in general we could ask for deprectation paths as part of the design

Dan: we could ask if they have that

Sangwhan: whether they can do it..

Hadley: at some point pci is going to change

Sangwhan: I think that's the hope. if we have evidence we can provide a secure transaction experience while also being able to provide customisability, keeping security guarantees intact. PCI is a fundamental distrust in transactions on the internet overall.

Dan: We're gonna talk about at TPAC.

Dan: there was some discussion about this at TPAC - reflected by Rick Byers's comment from 3 weeks ago.

Sangwhan: I am mroe of a pragmatist...

Dan: they want to switch to a trust model for embedding user data... they talked about PII Input as a name.. but it's a loaded term... but that's bikeshedding, the idea behind it sounded really good. Decouples the isue from autofill and makes it more about

Sangwhan:

Yves: question - is auto-fill only available on form inputs that re visible? Or can it be done for hidden fields?

Sagnwhan: i believe it can be done for hidden but in a "hackey" way... there are some hacks ... not standard behavior.

Yves: auto-fill credit card info in a hidden field feels quite unsafe...

Sangwhan: agreed. I'm okay with what they're doing here

Dan: I think the nuance expressed in Rick's comment addresses the issue we've raised. You could imagine how .. it's a semantic issue? It makes more sense to me

Hadley: my comment was referencing a discussion on plenary ... rick had called them attack vectors... I was looking at the attack vectors that rick had linked to in their explainer... In the context of this feature and the documents rather than users and user activities... If I remember correctly we particularly wanted them to think through how this could be used on malicious ways... Maybe we should just say "thanks".

Dan: I think it's the first thing and I think we need to ask them to frame it as Abuse Scenarios rather than attack vectors.

Dan: reviewing status looks like nothing has happened....

Martin: giving sites ability to deny 3rd party content access to your info and equally denying people access to autofill when it would be desirable.

Martin: i think the assertion that the cardholder name is "necessary" to remain on the merchant origin is questionable at best.

Dan: the payment flows I like are where you go a website and say I want that rake, and it says pay with apple pay or web payment, and then it doesn't ask for any information, it just displays a payment dialog and the information flows through that. You could say in that case my name and address is being provided through the payment api to the merchant. it's happening at that point in the flow

Martin: to the merchant or the payment provider?

Dan: to the merchant as they need to know where to send the rake. Unless it's digital goods in which case they don't need to know.

Martin: this is my fundamental concern. There is an expectation on the part of some actors that they have access to certain information without concretely establishing they have that right. Thye just have an expectation. When words like 'legitimate' and 'necessary' are used, that's not true.

Dan: one of the things we were takling about is that it wasn't well documented the abuse scenarios, the ways in which this could be used to trick the user - information about what the user has agreed to share with whom via autofill. Still a question of do you want to autofill your information being asked at some point? Maybe your mobile browser asks you this - do you want to autofill? Yes, okay for rakes.com. But actually that's being autofilled not to rakes.com but to evilpaymentprovider.com which is being used by rakes.com. Rick's point is that's how ecommerce works. There are payment providers and are ubiquitous on the web so that's less useful feedback.

Martin: more sympathetic to Rick's argument in this case. You're interacting with rakes.com and if rakes.com wants to use a third party service payment provider to accomplish what it wants to accomplish then rakes.com is still ultimately responsible for what happens in that context - compliance with data protection and security and other consequences. Ultimately from the user perspective you're giving this information to rakes.com. How rakes.com wants to manage all of that is then their business. I don't see there's much business in having minute control over the number of the card going to the third party, and the name is going to the merchant and the third party... I don't think is really something that people...

Dan: that's fine, agree. The worry we expressed was in the context of autofill this could be used to trick the user if there was malicious content being embedded. If there was a malicious ad could it be used to trick the user? Autofill could just spew your name and phone number into a random form, when maybe that wasn't the intention of the first party site. What are the controls that mitigate against that? That was missing from the proposal.

Martin: would this be something for permissions policy? As a top level site the default is that autofill doesn't happen in frames. BUt you can set a permission policy that says this site gets autofill that' would be a fine solution. Is that not what they're saying?

Dan: they could have updated it.. last updated 10 months ago

Martin: it says it's a policy control feature which is consistent with my interpretation

Dan: might have been prompted by our feedback, we had a good conversation at tpac last year but no update in our issue

Martin: if they are using permision policy.. I think it's a good thing in total. What I thought this work would run into was the potential for a website to deny access to autofill in certain circumstances where they thought it was not appropriate. if I wanted to build a website (like many do, despite it being bad) that blocked use of a password manager for password entry, I'd accept it from an iframe but deny the cross origin iframe access to autofill capabilities. I suspect they already have addressed that in the whole thing by there being a direct user override for any form field. If they don't that's a problem.

still awaiting feedback

Found these threads (both remain opoen) from other engines:

• WebKit standards position on eligibility for autofill

• Mozilla standards position on eligibility for autofill

no change