<scribe> Scribe: Ian
https://lists.w3.org/Archives/Public/public-payments-wg/2017Nov/0040.html
Ian: I observe support and no
objections.
... therefore assume that this proposal carries.
... I will confirm with the chairs and announce the
decision
Ian: Working with Shane on that
Please respond by 14 December call.
IJ: Any questions about that?
Ian: My expectation from discussion with Manash is:
a) we are going to work on a draft mission statement for the task force
b) we will launch it in January
14 December
scribe: after that is 4
January
... we'll review charter comments (if any) on 14 December
https://github.com/w3c/payment-handler/pull/229
Ian: Capital One ok with PH API
remaining silent on the question.
... they are ok with the pull request
IJ: Thoughts from Ken?
Ken: I think we are in support of a recommendation from Manu
Capital One ok with PH API remaining silent on the question.
https://github.com/w3c/payment-handler/pull/229#issuecomment-349977527
^^^
Ken: Our goal is to ensure that
the specs are free from commercial bias and focus on technical
functionality.
... there's been important dialog on the topic and it's
important to capture it for implementers to be put on notice
about the concerns and considerations
IJ: What is your articulation of the consensus view?
Ken: User preference should override other preferences
<manu> Adrian also articulated consensus view here:
<manu> Say as little as possible without leaving the door open to manipulation of the market
<manu> Ensure the PR and PH APIs are consistent in their treatment of the issue
<manu> In other words, the group has discussed this multiple times, and it would be good to summarize that conversation in a non-normative manner in the spec so readers of the spec know that we had the conversation and came to a set of conclusions.
<manu> I'm happy to draft a PR, if necessary.
https://github.com/w3c/payment-handler/pull/229#issuecomment-349893524
https://github.com/w3c/payment-request-info
IJ: Would browser implementers find it useful to capture as good practice (but not in the spec)?
<manu> -1 - this is not just about good practice
IJ: What is an effective way, Rouslan, to capture good practice?
<manu> +1 for mentioning it in best practices documents... but pointing to the spec as it is something that we discussed as a WG.
Rouslan: Some of this happens
through side channels
... e.g., on GitHub
... e.g,. how to do full screen payment sheet without being
spoofable.
... I think side channels are somewhat effective, but it could
be good to document best practices (or just recommendations)
for implementers...not necessarily in the spec
<Zakim> manu, you wanted to ask why not in the spec for now - it's more than just good practice
Manu: While I understand the
point about good practices, those are typically for web
developers
... often info for implementers in the spec makes it easier to
find
IJ: How do we address consistency with PR API?
Ken: I am fine to propose a
similar note to the PR API
... for consistency between the two
... I am puzzled by the concern over non-normative language,
which was not expressed previously
<manu> IJ: Expectation is that the editors will do work to advance the spec, they will work to reflect consensus of the group, where there is uncertainty - Editor's will bring discussion to group. You are justified wrt. questioning rationale.
<manu> IJ: The expectation was not to push forward a proposal where there was push back...
<Zakim> manu, you wanted to note it in PR API and have PH point to PR API? That would address consistency issue, and is "editorial"/non-normative, would there be objections from the
Manu: Regarding consistency,
let's not prioritize that. I think the primary concern is to be
silent in the spec. THat's a concern to Digital bazaar and
Amex
... one idea is to add a statement to PR API and link to it
from PH API.
<manu> IJ: Is consistency sensible here? The original request to remain silent had to do with language regarding merchants... the current request regards language for user agent implementers. It's not clear to me that those two have to be aligned. Audience being addressed is different, maybe there is a reasonable way to address them differently. I think it's great to be consistent, but wanted to see if that's more primordial here. I think rather than open PR API opened,
<manu> I'd rather see an alternative PR on PH API, if we can.
<manu> IJ: Perhaps in Security/Privacy considerations might be a good place to do it? Maybe "Security, Privacy, and User Considerations"?
IJ: One idea is to update Security/Privacy and User Experience
<manu> IJ: So delete all of 4, and reinstate a piece of that in this new section - among things to reinstate, the one that reflects the best consensus "User agent favors user-side order preferences over others".
<manu> Manu: I'll avoid RFC keywords.
<manu> IJ: Ok, try to do that on a new branch... cc Marcos... we'll come back on another call to this issue.
<Ken> 1+ Thank you, Manu
<scribe> ACTION: Manu to draft proposal for this issue to delete 4 and modify 8 to include an expectation about user preference preference
<trackbot> Created ACTION-71 - Draft proposal for this issue to delete 4 and modify 8 to include an expectation about user preference preference [on Manu Sporny - due 2017-12-14].
https://github.com/w3c/webpayments/wiki/http_api_note_status
<ShaneM> I have made a branch for the note. ready to go modulo picking a publication date
IJ: When we have a new TR draft, we can update the note to point to it.