More restrictive hasEnrolledInstrument() for autofill data

[rsolomakhin]

こんにちはTAG!

I'm requesting a TAG review of:

• Name: More restrictive hasEnrolledInstrument() for autofill data
• Explainer: https://gist.github.com/rsolomakhin/d6d242cbb9306864ada5a29de7ab271e
• Primary contacts: @rsolomakhin - implementer.

Further details:

• Relevant time constraints or deadlines: Please review before September.
• Self-Review Questionnaire on Security and Privacy is not applicable, since this is a behavior change to a part of an existing API.
• I have reviewed the TAG's API Design Principles, although it does not seem to be applicable here either.
• The group where the work on this specification is: Web Payments Working Group.

We'd prefer the TAG provide feedback as (please select one):

• Leave review feedback as a comment in this issue and @-notify @rsolomakhin

[dbaron]

The TAG is unsure about whether TAG review is needed for an implementation change that doesn't require spec changes. If it's an issue that isn't important enough for the spec to specify clearly, then it's not clear why the TAG should be reviewing it.

That said, this does bring up the question of perhaps whether this should be specified in more detail in the spec. Given the expectations that Chrome is setting, are other implementations of this API going to have to do the same thing in order to be compatible with the expectations of the API's users? If so, then it might actually need to be in the spec.

[rsolomakhin]

Good point, @dbaron. I will bring this up at the next working group meeting to see whether this should be specced.

@ianbjacobs: Could you add this topic to the agenda, please?

[rsolomakhin]

Sorry, I meant to CC @ianbjacobs.

[rsolomakhin]

@dbaron : In today's WPWG meeting, the consensus appeared to lean toward adding non-normative notes about behavior of hasEnrolledInstrument() to the three specs:

• Payment Request
• Payment Handler
• Basic Card

But the discussion is ongoing. We hope to come to a conclusion at the 2019 TPAC.

[hober]

@rsolomakhin wrote:

the consensus appeared to lean toward adding non-normative notes about behavior[…] but the discussion is ongoing. We hope to come to a conclusion at the 2019 TPAC.

Did you come to a conclusion? What did you conclude?

[ianbjacobs]

@rsolomakhin, should we fold this discussion into other payment handler discussions we are having right now, and in particular:
https://docs.google.com/document/d/1C_xH-6sJb9UedrvifsvqS_2k_We0IlPSfWFo8Kg54ps/edit

[rsolomakhin]

SGTM @ianbjacobs

[hober]

@dbaron and I looked at this again in our F2F this week, and since this is still not likely to result in normative changes to the spec, we're going to close the issue. Please let us know if it turns out this will result in normative spec changes, so we can take another look!