<danyao> Hello! Danyao Wang from Google. I'm an engineer working on Payment Request.

<npdoty> scribenick: pes

<tara> Agenda start: We'll let Jason give a quick update on the questionnaire...

<tara> Since he has to dash early

tara: agenda is changed, Jason / privacy questionare first

jason: TAG lookged at questionare, w/ feedback
... 1) simplify the questionare, so we’ll reshuffle
... 2) line edits / framing / link updates
... 3) “tone”. Maybe too agro to ask for dropping features, similar
... in respoinse, lukaz and Jason will make edits, then back to PING, then TAG

sam: whos repo should questions go to? Why seperate the repos?

<npdoty> do you need anything from us (PING) at the moment? things you’re ready to move into separate documents?

jason: repos for edits or issues?
... issues -> TAG repo (except for PING edits, which, github requires living in repo PING controls)

tara: lets start discussing the payment API

ian: I’ll be presenting the payment API

<tara> (FYI Tara actually works at *Google* but her brain seems to have connected her to her old Apple affiliation today (?) )

<Ian> https://lists.w3.org/Archives/Public/public-payments-wg/2019Feb/0003

ian: candidate rec published in July
... features mostly locked down now
... still work to do on completing implementation reports in vendors
... hope to have it all wrapped up mid year 
... interested in PING’s feedback as moving to candidate recommendation

<Zakim> npdoty, you wanted to comment on document sections and on payment address disclosure

npdoty: why is there privacy seciton, and privacy + security section

ian: thats a bug, will address

npdoty: thanks, its confusing
... question 2: for the billing address change, can the site see that the user changes their address before confirmation

ian: yes, depending on what the user selects, it can affect calcuations

<Ian> https://www.w3.org/TR/payment-method-basic-card/

ian: the feedback is to allow for updating the taxes similar

<Ian> https://www.w3.org/TR/payment-method-basic-card/#steps-for-when-a-user-changes-payment-method

ian: (above links describe what happens when user changes payment method)

pes…there is a redact list somewhere

<weiler> https://www.w3.org/TR/payment-method-basic-card/#steps-to-respond-to-a-payment-request?

(should not say “pes” above, whoops)

npdoty: is the user interacting at this point

ian: yes, the site is presenting the total to the user

npdoty: that affects the communication model, site can get infromation before commit

ian: yes, site can get information before user action, throught getPaymentMethod

npdoty: that makes it tricky, how could UAs describe

ian: googlers?

danyao: no, we don’t communicate to the user that the website is learning about the user
... we’re discussing with our privacy team

<npdoty> the site can get information with canMakePayment (before dialog at all), and then some billing data when the user is in the UX but hasn’t confirmed payment

danyao: possibly UI notification
... we also rate limit how often the website can call the API

ian: I will go to the editors to get a single consideration section

<tara> pes: rate limiting -- ca I ask once for US card and once for EU, etc...?

<jnovak> https://blog.lukaszolejnik.com/privacy-of-web-request-api/

<tara> You can ask once per payment method. US card, etc -- all falls under basic card. Site cannot iterate over the wallet to tell which card they have.

<weiler> section number?

<npdoty> the spec notes that the UA can do this, but isn’t specific about it

<npdoty> right, canMakePayment and those heuristics had been discussed last time. the new change is what level of billing address location is also maybe shared during the buy UX process

mike: 1) did you consider logging?

<tomlowenthal> Is logging something we'd want in a spec?

mike: 2) does the UI have ACL text?

ian: to answer #2, the spec allows the “sheet” to be implemented many ways
... mozilla uses HTML, others dont
... vendors prefer the flexibility

<npdoty> but the site passes labels and amounts, not full HTML

mike: so browsers get to choose what happens when users type?

ian: yes, browser validates

<weiler> cite to the section re: cannot iterate?

mike: what about the logging?

<Ian> from https://w3c.github.io/payment-request/#show-method

<Ian> "For example, the user agent may limit the rate at which a page can call show(), as described in section § 20. Privacy Considerations. "

rouslan: the spec doesn’t say anything about logging. In Chrome, implementation its all minimized

<npdoty> is there a supported approach for using the payment request api without using canmakepayment? if a browser just returned true, or just returned NotAllowed, would that prevent sites in the long term from using the API at all with that UA?

rouslan: UI records user interaction with the sheet (for RAPPORT style reporting)

<Ian> npdoty, merchants want to know info in order to use the API

rouslan: user values are not recorded

<Ian> npdoty, so it might be technologically possible, but in practice people want to decide what checkout path to provide

mike: so, you store aggregated counts, but not timing / user related values?
... maybe an internal log would be useful to the suer

<jnovak> Sorry, I have to drop

<npdoty> Ian, yeah, I totally get that, and it’s especially important in early adoption times, but can we at least make it possible for it to work without that?

<jnovak> I will follow up over GitHub issues / the mailing list.

<tara> Thanks, Jason!

ian: point of order, that might be useful, but not part of v1

weiler: this seems very linked to the basic card spec. Didn’t expect that. Am I missing something?

<Ian> https://w3c.github.io/webpayments-methods-tokenization/index.html

ian: basic card is the spec we’ve made the most progress on. Low hanging fruit

<Ian> https://w3c.github.io/webpayments-methods-tokenization/index.html#interfacing

ian: we’ve made progress on follow up, tokenized card spec

<Ian> https://w3c.github.io/payment-method-credit-transfer/

<Ian> https://w3c.github.io/payment-method-pisp-credit/

ian: there are others, credit transfer etc

weiler: its confusing, “basic address” is used and defined in different places

ian: common definitions get owned by one standad, and referred to in other specs

<weiler> defined in a specific payment method doc (basic card) and then used here in an umbrella doc.

ian: payment handler API is similar
... they seem distinct but related

<Ian> https://w3c.github.io/payment-request/#show-method

weiler: re-iteration through cards mitigation: spec mentions limiting things displayed for user-confusion purposes, not privacy

<Ian> For example, the user agent may limit the rate at which a page can call show(), as described in section § 20. Privacy Considerations.

<Ian> https://w3c.github.io/payment-request/#privacy

ian: see sec 3.3, where good practice is defined

danyao: its also mentioned in section 19.2

<npdoty> I think repeating show() isn’t an information disclosure problem as in the canMakePayment() iteration

ian: as we merge sections, it’ll get easier

<npdoty> repeating show() is annoying the user with UI, and repeating canMakePayment() is gathering information on the user’s wallet without showing any UI

weiler: in call was said that there is a mechanism to prevent iterating through cards to prevent privacy loss; i dont see that in the spec

<npdoty> https://w3c.github.io/payment-request/#canmakepayment-method

ian: somewhere there is a canMakePayment algoritm that describes rate limiting

<Ian> "This allows user agents to apply heuristics to detect and prevent abuse of the canMakePayment() method for fingerprinting purposes, such as creating PaymentRequest objects with a variety of supported payment methods and calling canMakePayment() on them one after the other. For example, a user agent may restrict the number of successful calls that can be made based on the top-level browsing context or the time period in which those calls were made. "

danyao: there is a note saying UA can use heurisitcs to prevent abuse

weiler: why is the FP text not in privacy considerations?

<npdoty> it’s also in privacy considerations: https://w3c.github.io/payment-request/#canmakepayment-protections

ian: 3.3 used to point at a privacy consideration item
... i’d be happy to add forward mentions of privacy considerations
... does that address the concern?

weiler: this reads rough, like spaghetti (b/c of all the refs)

ian: okay, what are concerete things?

<npdoty> well, it is a large and complicated spec

ian: is the request to add the word "fingerprint"

weiler: not at the moment

<weiler> https://github.com/w3c/payment-request/issues/842

weiler: last: i filed an (the above) issue this AM
... whie there is a way for the UA to redact address info, but how to negotiate it?

ian: re: redaction
... there is an open issue (from WorldPay)
... the merchant should decide if they want the CVV, its a risk on their part
... it adds friction to the user experience
... there should be a way for the site to express a preference about what to collect
... browser implementations return all response data currently

weiler: you spec’ed w/o implementations?

ian: not the above part

weiler: “yuck”

ian: its the same data currently through a form

<tomlowenthal> Yeah, but in the form, you have to deliberately type things.

weiler: you’re requiring that merchants get access to more data than they do currently
... thats bad for privacy

ian: its just one piece of data

<npdoty> tomlowenthal, right, but in the case of choosing a payment card, the user would actually be able to see it before it’s transmitted, it’s not a background thing

ian: and we’re moving to tokenization
... but you (weiler) are correct, there is access to more data
... but its being considered for 1.1

<Zakim> rouslan, you wanted to mention that Safari and Chrome both have a setting to turn off canMakePayment.

<tomlowenthal> npdoty: If we're just talking about that three/four-digit code, not a huge deal, IMO.

rouslan: you can turn off in some implementations (Safari / Chrome)

npdoty: what happens on sites?

rouslan: some sites check to see if the user has turned it off
... some merchants don’t check and always call `show()`

<tara> scribe: tara

<npdoty> if sites just used show() and checked for NotSupported errors, it seems like that would minimize the privacy concerns of canMakePayment background checking, fwiw

For rate limiting: can I use a million subdomains? Can we get more guidance on this aspect?

<npdoty> right, lukasz also noted this potential attack of using different iframes in different domains to call canMakePayment with different parameters to gather more info

Rouslan: if you have a million subdomains, you can currently find out more about a user, b/c rate limiting is on per-doman vasis

You can also wait through time limit

<tomlowenthal> Why rate limit on FQDN than ETLD+1?

Happy to hear suggestions for mitigations

<npdoty> UAs could also limit based on top-level browsing context origin

(pes can you repeat your mitigation -- scribe did not hear whole sentence)

<tomlowenthal> Sounds like it's not really a rate-limit at all then.

<weiler> tom++

pes: A reasonable mitigation -- remove, or on single top-level frame - can limit to calling, say, once.

<npdoty> that was my suggestion, limit based on top-level browsing context origin

Rouslan: workaround is open new top-level context (window)

<scribe> scribe: pes

(the bird murdered tom :( )

<tara> toml: I can create as many subdomains as I want...<audio lost>

npdoty: can you address the issue of eTLD+1 vs FQDN

<tomlowenthal> Yep.

<tomlowenthal> I'm dialing back in.

<tomlowenthal> Can circle back to me.

ian: opening a window is more invasive

<npdoty> yeah, window.open would be extremely noticeable in comparison to background iframes with no user notification

<tomlowenthal> I'm back.

ian: we’d be happy to have take input from PING

<tara> ian: yes, this is indeed our spec so we need to do the work -- but if PING has heard something useful for us from their experience, we're happy to hear that!

(especially when Pete gets overly salty [pete apologies])

toml: its important to add considerations about good limits for vendors and websties to know what to expect
... why FQDN vs eTLD+1? eTLD+1 are easier

<npdoty> it sounds like the suggestion is having more detail on possible effective mitigations, even if not normatively specifying which mitigation

toml: if its FQDN, its not a real rate limit

ian: i’ve heard 3 things to bring back
... 1) merge security + privacy + sec
... 2) revist the mitigations (and forward ref)
... 3) add more details about can make payment mitigation strategies

<tomlowenthal> ++

ian: 4) revisit the mitigation approaches
... also over negotations of what can be returned
... those won’t happen in v1

weiler: did we say merge those sections?

npdoty: my suggestion was the not have both sections, and that it seems inconsistant. Have two secs as long as they’re not mutually exclusive

<Ian> Many thanks to the PING!

<npdoty> I actually think limiting by top-level browsing context origin actually has interoperability issues, so it might be worth specifying normatively

<weiler> i suggest keeping separate sections. it's a minor thing....

tara: thanks ya’ll

<Ian> github++

<npdoty> separate security and privacy sections might be good, I have no preference, but currently it’s two partially overlapping sections

Ian, would it be helpful to have a PING member attend one of your meetings?

<Ian> yes, our next FTF meeting is 2-3 April in Foster City, CA.

<Ian> WPWG agenda

<Ian> pes, let me know if interested

ian, yes, that’d be great. We’re in SF, so would not be a problem

<Ian> pes, please send me a mail to follow up with info and who would attend (and whether there are are dietary requirements)

This is scribe.perl Revision: 1.154  of Date: 2018/09/25 16:35:56  
Check for newer version at http://dev.w3.org/cvsweb/~checkout~/2002/scribe/

Guessing input format: Irssi_ISO8601_Log_Text_Format (score 1.00)

Succeeded: s/rella doc.//
Succeeded: s/utes//
Present: npdoty tara Ian danyao_wang jnovak mikeoneill rouslan_solomakhin pes pranjal tomlowenthal wseltzer weiler terri hannah
Found ScribeNick: pes
Found Scribe: tara
Inferring ScribeNick: tara
Found Scribe: pes
Inferring ScribeNick: pes
Scribes: tara, pes
ScribeNicks: pes, tara

WARNING: No "Topic:" lines found.


WARNING: No meeting chair found!
You should specify the meeting chair like this:
<dbooth> Chair: dbooth

Found Date: 28 Feb 2019
People with action items: 

WARNING: Input appears to use implicit continuation lines.
You may need the "-implicitContinuations" option.


WARNING: No "Topic: ..." lines found!  
Resulting HTML may have an empty (invalid) <ol>...</ol>.

Explanation: "Topic: ..." lines are used to indicate the start of 
new discussion topics or agenda items, such as:
<dbooth> Topic: Review of Amy's report


WARNING: IRC log location not specified!  (You can ignore this 
warning if you do not want the generated minutes to contain 
a link to the original IRC log.)