Payment Handler issue triage [Was: [Agenda] 4 April Payment Apps Task Force teleconference]

> On Mar 31, 2017, at 10:45 AM, Ian Jacobs <ij@w3.org> wrote:
> 
> Participants in the payments app task force,
> 
> We meet 4 April at 10am ET. I expect by then to have a proposal for how to 
> triage issues preparing for FPWD. I’d like to review that proposal at the meeting.
> (I won’t have it until end of day for me on 3 April.)
> 
> I am likely to organize the issues something like this:

[Snip]
See proposal below.

Ian

> WebEx: 
>  http://www.w3.org/2017/01/paymentapps-2017.ics


======
Here's an initial categorization of issues with First Public Working
Draft in mind:

 - Substantive to address before FPWD
 - Substantive to address after FPWD (and mark in the spec)
 - Editorial to address before FPWD
 - Editorial to address after
 - Potentially close with no change

For reference, here's the issues list:
  https://github.com/w3c/webpayments-payment-apps-api/issues

Ian

==================================
Substantive to address before FPWD

120: Origin should include iframe(s)
    Rationale: Rouslan has a proposal; can we agree to it?

111: `appRequest` attribute should not be a dictionary
    Rationale: The original suggestion from Rouslan was incorporated;
    Marcos has an additional proposal; it seems like we could work through
    this in time for FPWD
    https://github.com/w3c/webpayments-payment-apps-api/issues/111#issuecomment-287944141

==================================
Substantive to address after FPWD

124: Clarify what information user agents forget at various moments
    Rationale: If the specification evolves a lot (as is likely), the
    answer to this question will evolve as well. Suggest we add an
    issue marker in section 8.1 ("information about the user
    environment").

123: Share user data with Payment App
    Rationale: Include a marker in the spec in order to draw attention
    to this issue and gather data.

119: PaymentRequestEvent incompatible with DOM events
    Rationale: Marcos raised this. In light of the focus on PR API, I suggest
    we simply log this to address later.

116: Relation between merchant order of payment methods and payment app order of instruments
    Rationale: There is a related issue on Payment Request API, and that
    issue may be resolved after FPWD. Therefore, I suggest we leave this
    one open and in the spec. We should also review 6.1.
    

97, 115: Different approaches to opening windows
    Rationale: Marcos and Tommy working on this, and working to align
    with the SW Open Window Algorithm

94: Add explicit permission call to allow payment app to handle payments
    Rationale: We know we want this, and there is already a note and
    example of one way to do this that can help review.

23: Analyse security properties of payment app execution environment
    Rationale: Continue to ask this question ongoing

==================================
Editorial to address before FPWD

122: Clean up respec errors and "tidy" the markup

109: Renaming PaymentApp* classes
    Rationale: This may have been done via an Adam Roach edit. Tommy Thorsen
    has a few additional suggestions.
    https://github.com/w3c/webpayments-payment-apps-api/issues/109#issuecomment-287705543


==================================
Editorial to address after FPWD

50: Links to terms and common terminology
    Rationale: As the specification fills out, references will become
    more precise.

49: Pictures would help
    Rationale: Part of a larger merchant adoption strategy effort

==================================
Potentially close with no change

117: Support for Abort() being delegated to Payment Handler
    Rationale: This seems primarily to be an issue about PR API.

105: What is a Payment App?
   Rationale: The specification scope is narrowed to defining a feature
   of the Web platform. We answer the question in the specification.

84: Recommended payment apps
   Rationale: The specification no longer speaks about recommended payment
   apps.

69: What does "icon" mean?
   Rationale: This is addressed by the draft. 

5: Display may be subject to user and local policy.
   Rationale: Issue is underspecified

--
Ian Jacobs <ij@w3.org>
https://www.w3.org/People/Jacobs/
Tel: +1 718 260 9447

Received on Monday, 3 April 2017 22:25:23 UTC