Remove 'Origin and Instrument Display for Selection' sections

[marcoscaceres]

---

Preview | Diff

[marcoscaceres]

As per yesterdays call.

[romandev]

lgtm

[marcoscaceres]

Will leave for @ianbjacobs to approve and merge.

[adrianhopebailie]

Discussed on WG call today (30 November).
Some members have requested some time to reflect on this and comment.

Please don't merge yet.

[marcoscaceres]

@adrianhopebailie, do you have a summary of questions? Should we set a deadline for comments?

[ianbjacobs]

Hi @marcoscaceres,

There's some relevant background in:
#116

We'll discuss on 7 December and then I'll summarize on this thread.

Ian

[marcoscaceres]

Ok, but please remind members that implementers don't feel language around UI requirements is suitable in a API specification (as we expressed at the F2F): implementers compete on UI, and we have teams of world-class UX/UI designers who understand the challenges of the payment experience. We trust our designers to create delightfully functional experiences for users.

Of course, I'm sure any implementer would be happy to receive feedback on creating the best experience possible - but trying to dictate it in a W3C spec is not appropriate, and will likely just get ignored.

[adrianhopebailie]

I think the concerns from the WG members are more related to regulation and what should and shouldn't be mandated ito user choice.

I believe the preference is:

1. Say as little as possible without leaving the door open to manipulation of the market
2. Ensure the PR and PH APIs are consistent in their treatment of the issue

[msporny]

@marcoscaceres wrote:

please remind members that implementers don't feel language around UI requirements is suitable in a API specification (as we expressed at the F2F)

Normative language around UI requirements in an API specification is not suitable, that's true.

Non-normative language to clearly articulate that the WG did discuss the topic and did come to some sort of consensus (as alluded to by @adrianhopebailie above) is perfectly fine.

So, -1 for completely removing the language. +1 for a PR that restates Section 4 in a non-normative manner so that Web developers know that we did have this discussion and did come to a set of conclusions about it. It goes beyond best practices as there is a regulatory consideration to the language, so it's worth stating in the spec.

[kmealey]

+1 in favor of handling as per Manu Sporny's suggestion...i.e. for a PR that restates Section 4 in a non-normative manner so that Web developers know that we did have this discussion and did come to a set of conclusions about it. It goes beyond best practices as there is a regulatory [KJM insert adding 'and commercial' consideration(s) to the language, so it's worth stating in the spec.

[ianbjacobs]

@marcoscaceres, @adrianhopebailie

We discussed on the call today:
https://www.w3.org/2017/12/07-wpwg-minutes.html#item08

@msporny took an action to write a counter-proposal that:

1. Deletes section 4 (as proposed) but
2. Reinstates in section 8 the expectation that user preferences will prevail.

We'll re-discuss in a week.

[marcoscaceres]

I’m worried that moving things to section 8 just devalues the privacy and security section. I’d be ok with a single sentence, but really this is of limited value (specially if there is regulations around this, which is more important). An alternative might be to publish a separate Note if people want and we could link to it.

[msporny]

Can we close this PR to concentrate discussion in #242?

[ianbjacobs]

Closed in favor of #242

[ianbjacobs]

Sorry, I realize @marcoscaceres should be the closer