W3C

Regulatory Landscape

16 Jan 2017

Agenda

See also: IRC log

Attendees

Present
WilliamVanobberghen, Ian, BertrandJeannet, dezell, jyrossi, Evgeny
Regrets
Kris, Jurgen
Chair
jyrossi
Scribe
Ian

Contents


Expectations and deliverable prioritization

<jyrossi> https://www.w3.org/Payments/IG/wiki/RegulatoryLandscape

"The goal of this task force is to explore how Regulatory Issues could impact upon an effective and efficient global deployment of the Web Payment Solutions supported by WebPayment Working Group's Public Drafts toward the future recommendations."

<jyrossi> https://www.w3.org/Payments/IG/wiki/Common_approach_and_logic_for_mapping_the_regulatory_landscape_of_payment_services

IJ: What will the deliverables be? How will they used by working groups?

https://www.w3.org/Payments/IG/wiki/File:Regulatory_issues_TF_a_Roadmap.jpg

jyrossi: The idea is to create a list (documents and contacts)
... for each jurisdiction we can gather documentation, see Jurgen's email for example
... so the first step is to gather some documents
... when we are developing an API we will face regulatory quesitons
... and the documentation can be used to help analyze what is permitted/forbidden

IJ: Please describe who will use the deliverables, and at what time in the process?

jyrossi: One answer could be "volunteers" will do the analysis.
... if we don't deal efficiently with regulatory issues, we jeopardize work in progress.
... I recognize the fact that it is not customary for Working Groups to do this
... which means it could be difficult. But I think there are risks to not doing this analysis.
... I also think that if we establish contacts within regulatory or supervisory authorities, that will also help

IJ: Will we be creating materials to help do analysis, or merely point at resources that will help people do analysis?

jyrossi: I think we'll want to do something that looks at precise documentation (the authoritative regulatory materials) and captures good practices
... I think this will involve both IG and WG participants

<jyrossi> https://www.w3.org/Payments/IG/wiki/High_level_mapping_of_main_jurisdictions

<jyrossi> https://www.w3.org/Payments/IG/wiki/Main_regulatory_topics_about_payment_services#Draft_inventory_of_main_regulatory_topics

IJ: I would suggest we focus on a small number of jurisdictions (2 or 3) and get a shared understanding through that experience before trying to do too many

jyrossi: I think the cross-examination of issues will add value.
... +1 to starting with 3 jurisdictions and, say, 2 topics

<Zakim> dezell, you wanted to speak about levels of control

dezell: In my experience, we generally have a team in a target jurisdiction so they know the details that may impact them

Ian notes for the record: I think that the regulatory environment is important; I am not sure yet what deliverable will be useful for W3C working groups. I hope to get a better understanding as we start this work.

Jurgen's landscape => https://lists.w3.org/Archives/Public/public-webpayments-ig/2017Jan/att-0029/W3C_Regulatory_Landscape_Europe__input.docx

dezell: Jurgen did not quite follow the template; you may wish to send him suggestions for doing so

jyrossi: Do you think we could ask the WG for questions they have related to regulatory issues?

IJ: I don't think they have questions. Typically when a question arises they answer it among engineers looking at deployment and existing standards.

jyrossi: The risk is producing something that works technically but is not allowed to be used based on regulatory constraints
... For instance, the choice of payment instrument will be a sensitive one. Without a common vocabulary to discuss this sort of topic (with supervisory authorities as well), it will be difficult to enable implementations.

dezell: I think creating an FAQ is a good goal.
... there could be people like AHB or Max to review a FAQ
... one question for example: must a data field be encrypted ?
... that may change between jurisdictions.

<jyrossi> +1 to the idea of having a strategy to start a "FAQ" as a bridge between RI TF and the work in progress in the WPWG

dezell: so a given implementation may have to do things two different ways...this is not part of the API
... in some jurisdictions the UI may require prompting, in others not.
... so these are things that will have an impact on implementation

IJ: Working abstractly will not help.
... I suggest instead the approach of reviewing our API in development and writing down thoughts
... those could be directly relevant to implementers of the spec.

jyrossi: In order to gather people to review work in progress and for them to give useful pieces of advice (say, in US, EU, China, Russia), we need some people who can bring that point of view from those jurisdictions.
... we need to build a group of reviewers

IJ: I think we need to get people to read the spec, write their thoughts down, and we look for common patterns.

jyrossi: I think we need to do more to frame requirements we have for the reviewers.
... and we also need to have people in the WG willing to enter into the discusiosn

dezell: The FAQ is one way to meter success. Ian's suggest is perhaps more direct.
... I think jyrossi's outline is good
... I think we should get as many contributions as necessary, but then we should put into action something like Ian's plan
... would be good to have some sort of framework by 22 March FTF meeting
... I think the most important thing we should do is to come up with a schedule leading up to the FTF

<Zakim> Ian, you wanted to comment that this feels over-engineered and we have the channels already to get what we need

<dezell> Ian: I'm concerned that we must address current work in the WG.

<dezell> Ian: If we don't, we'll miss our opportunity.

<dezell> Ian: suggest an excercise where we give opportunity to experts in specific regions to review the WG spec.

<dezell> Ian: prefer the approach of letting the questions grow organically.

IJ: I think we need to start by reviewing actual work and gaining experience, otherwise we are merely working in the abstract with no guarantee that the result will be useful.
... We don't know what will be useful or not. We've not done anything yet. We will learn utility after some experience.

IJ: I don't want to sound critical. I think doing these analyses could prove useful for the Working Group. And the good news is that I don't think we have to do a lot in order to get there. I think we should not abstract (or create FAQs) until we have tried this out several times. And, as I said, if we spend a lot of time theorizing, we will miss the window of opportunity.

jyrossi: We need to pave the way for regulators to help
... We need to think about what we can do to get the volunteers.
... to create a network of contacts could be useful output

IJ: I think that a practical analysis is the most important deliverable we could do. It's a very valid question to ask "How can we get people to do this analysis?" This task force could usefully find those people, figure out how to approach them, prepare them to do the analysis, help them write up the results, etc.

next call

PROPOSED: 23 Jan at 9am ET

<jyrossi> +1

Ian: +1

jyrossi: I will send agenda today or tomorrow.

Summary of Action Items

Summary of Resolutions

[End of minutes]

Minutes formatted by David Booth's scribe.perl version 1.148 (CVS log)
$Date: 2017/01/16 15:17:25 $