Web Payments Working Group recharter

[ianbjacobs]

Recharter proposal, reviewers please take note.

Charter Review

Charter:

What kind of charter is this? Check the relevant box / remove irrelevant branches.

• Existing
  • [x] Existing WG recharter
  • If this is a charter extension or revision, link a diff from previous charter, and any issue discussion:

Current charter (expires 31 December 2021): https://www.w3.org/Payments/WG/charter-201912.html

Note: The structure is sufficiently different from the previous charter that a diff would not be useful. Key changes beyond aligning with current charter template:

• New scope section
• Added Secure Payment Confirmation on the Rec Track
• Section 2.2 sets expectations about other deliverable maintenance

Horizontal Reviews: apply the Github label "Horizontal review requested" to request reviews for accessibility (a11y), internationalization (i18n), privacy, and security. Also add a "card" for this issue to the Strategy Funnel.

Communities suggested for outreach: Web Authentication Working Group, Web Payment Security IG

Where would charter proponents like to see issues raised? (this strategy funnel issue, a different github repo, email, ...) public-payments-wg@w3.org

[himorin]

Link to SPC spec in section 2.1 seems wrong.

[ianbjacobs]

Thanks, @himorin! Fixed.

[dontcallmedom]

I believe the preference is to keep scope section tight (since they're IPR impacting) - I'm not sure if this already something we're confident in emulating, but the recent updated WebAuthn charter has a "Goals" section where some of the motivation piece currently under Scope could move.

[dontcallmedom]

any reason you want to require rechartering to move foward with Payment Handler / manifest? Wouldn't it be simpler to keep them as Rec-track deliverables but with low expectations of reaching Rec in the charter timeframe?

[ianbjacobs]

@dontcallmedom you wrote "any reason you want to require rechartering to move foward with Payment Handler / manifest?"

Did you mean "any reason you DON'T want to require rechartering to move forward with Payment Handler / manifest?"

Two thoughts:

• There might be some situations where one implementation suffices (e.g., a technology is very widely used). We are not in that situation, so I personally do not think we should advance with only one implementation.* At this time we have signals of "not planned" from one browser and no signal at all from another. It feel to me more accurate to set an expectation "this is not going to advance" and if that changes we can recharter.

[dontcallmedom]

My question was to understand why you think the group should recharter to advance Payment Handler or Manifest to Rec - if I understand your answer correctly, this is a matter of setting expectation that they are unlikely to do progress beyond WD in this chartering period; I'm not sure this is the most effective way of setting that expectation (vs e.g. saying in the timeline that you don't expect these specs to reach CR).

More concretely, not listing these two documents as normative deliverables may imply they won't be covered by the Patent Policy for the duration of the charter - is that intended?

[ianbjacobs]

@dontcallmedom,

It was intentional to not list these as Rec-track deliverables. I think that it sets the wrong expectation that we anticipate currently that these specs will at some point advance to Recommendation (in this charter period or later).

Of course, the situation might change. If it does, personally I am ok to recharter to draw attention to this significant change.

I'm happy to discuss other ideas. But leaving the specs in as "on the Rec track" say more than I personally am comfortable saying today.

[ianbjacobs]

@dontcallmedom,

Regarding the Scope section, I chatted with the co-Chairs this morning. We have a proposal:

1) Create a "Discussion Topics" or "Topics of Interest" Section (rather than "Goals") 2) Shrink the Scope section to: a) SPC b) Ongoing maintenance of previous deliverables.

Would that address your concern?

Regarding PH / PMM on the Rec track, the Chairs are ok with the current charter not having them on the Rec track.

[himorin]

No comment/request from i18n.

[ianbjacobs]

@dontcallmedom,

I've made changes to the charter based on your review. Here's the diff (including @himorin's link fix). A diff is available with the usual diff tools (but I am not pasting the link here).

Summary of changes:

• Created a new Background and Topics of Interest section; moved some content there from previous Scope.
• Thus, shrunk the scope to what the group is focused on now.
• Added Payment Handler and Payment Method Manifest to normative deliverables with expectations about not completing them during this charter period.

In parallel I will ask the Chairs if they are ok with these changes. Thanks!

[dontcallmedom]

this fully addresses my feedback, thanks @ianbjacobs!

[samuelweiler]

I don't see the diff cited above at https://github.com/w3c/strategy/issues/287#issuecomment-924097118, so I'm not sure if I reviewed the most current version.

I wish all charters I reviewed were this clear in their scope. Nicely done. No security or privacy concerns.

I filed a clarity issue and a history issue by email, as requested: https://lists.w3.org/Archives/Public/public-payments-wg/2021Sep/0013.html https://lists.w3.org/Archives/Public/public-payments-wg/2021Sep/0012.html

[ianbjacobs]

@samuelweiler,

Thanks for doing the review; much appreciated. I did not paste the HTML diff link since I wasn't sure that it should be posted in a public form. In any case, I had not changed the charter since my reply to Dom. I'll follow up on the individual suggestions separately.

[ianbjacobs]

Having received and integrated suggestions from @samuelweiler, @dontcallmedom, and @himorin, I plan to ask W3M to approve the charter. Thanks!

[michael-n-cooper]

No comments from APA.

[ianbjacobs]

Update on this charter: now that Payment Request API and PMI have been published as Recommendations (in Sep 2022), I plan to return to next steps for this charter.

[plehegar]

announced: https://lists.w3.org/Archives/Member/w3c-ac-members/2022OctDec/0018.html