Web Payments IG F2F
22 Feb 2016


See also: IRC log


DougSchepers, JeanYves_Rossi, Manu, Joerg_Heuer, Kris_Ketels, Vincent_Kuntz, Matt_Saxon, Shane_McCarron, Laurent_Castillo, Pat_Adler, Rouslan, IanJ, Erik_Anderson, Magda, Adrian_Hope-Bailie, Cyril_Vignet, Gregory_Estrade, Paddy_Ramanathan, Jeff_Burdges, Andrew_McCormack, Linda_Toth, Katie_Haritos_Shea, Evert_Fekkes, Brian_Sullivan, Mountie_Lee, nicktr, Leandro, Wendy_Seltzer, Zach_Koch, Lin_Li, Stephen_Miller, Yaso, VincentK, zkoch, padler, magda, Christopher_Allen
David_Ezell, Erik_Anderson
Manu, Ian


<inserted> scribenick: m4nu

<scribe> scribe: Manu

dezell: We're here to ensure that IG participants are happy w/ direction and to see if there are other areas we should dive more deeply into.

linda: Linda from NACS

andrew: Andrew from Canadian Payments Association.

gregory: Gregory Estrade for payment service provider in france

Vincent: Vincent Kuntz, representing ISO20022 Registration Authority

Jeffrey: Jeffrey Burges work for Taler and INRIA from France

Paddy: Paddy Ramanathan, run a startup incubator called Live Alley

LinLi: Lin Li from China - product service environment

Steven Miller: Hi Steve Miller, representing Japanese DDS.

david: I'm David Ezell, representing Connexxus/NACS

dezell: I'm Chair along w/ Erik, w/ staff contact Ian Jacobs - etc.
... We're going to hear from a variety of you - first up Pat Adler at US Fed.
... Then we're going to get an update on PSD2 from Evert
... After break, we'll hear from Verifiable Claims Task Force - figuring out what next steps there are.
... then lunch
... Then Blockchain and the Web, then a break, then ISO20022 harmonization, Interledger, Visa Developer Toolkit, IG Check-in and other topics, then dinner.
... The Check-in is basically a "how are we doing" by looking at charter. Everyone should be thinking about this as we go through entire agenda. We have a long time until we meet in Portugal at TPAC - hope to make lots of progress there.
... No details on dinner yet

Ian: Thanks everyone for traveling here - especially from across the ocean, thanks Google/Zach for hosting us.
... one question - dinner - group dinner?
... 27 people... we're going to try our best.
... The IG's theme is to look at potential sources for requirements for web standards.
... We may not end the meeting on a firm proposal - what does this mean for the web, what are the opportunities for W3C standardization?

US Fed Faster Payments evaluation criteria and what they mean for Web standards

Faster Payments Task Force Update

Ian: We have a number of people calling in during the day.

Pat: Good morning everyone - Chief Architect of FedLine, Federal Bank of Chicago.
... I'm going to share what's going on there - we're about bringing awareness.
... Like other countries, we're working w/ industry stakeholders - work on US payment system - giving folks a broad update.
... This should give you a bit of details - we're going to specifically look at 37 effectiveness criteria - spend some time at end - how does work affect W3C.

<Ian> Pat's slides on US Fed criteria

Pat: We set US payments into 5 strategies for improvement.
... First strategy - stakeholder engagement - collaboration is a goal. We have 320 members for faster payments, 160 for secure payments.
... Work around education and input opportunities.
... Second strategy - faster payments - identify/evaluate solutions that might come forward.
... This is supposed to represent everyone's views - many different interests.
... We wanted to make sure representatives were broad and encompassing of the entire payment system.

Shows diversity of participation slide.

Pat: We have a high-level work plan - plan the work, do the work, document the work.
... phase I went through 5 iterations - those will be public for industry showcase.
... we want industry driving the solutions, not the US Fed.
... year one accomplishments - we have effectiveness criteria, a decision-making framework, and a glossary of terms. Glossary may be interesting to the IG in particular.
... two purposes for effectiveness criteria - as industry proposals come in, we can evaluate consistently solutions coming forward. Not just technical requirements, legal and operational as well. As much about market structures as they are about technology.
... When we talk about Verifiable Claims, we'll see how there are linkages there.

<Ian> Materials for Faster Payments

Pat: We've done industry outreach, community polls - we have 37 effectiveness criteria now - we want to deal w/ things like ubiquity, speed, efficiency, governance.

<Ian> Criteria

Pat: overview of effectiveness criteria - document is public.
... This covers what we think is important for US payments system.
... One key goal w/ faster and secure is helping to support open standards. Standardization is a key enabler to making those things happen.

Katie: The link is wrong in the slide deck, make sure to fix that.

Pat: We have a decision making framework - industry showcase - as solutions come forward to present - make recommendations on proposal - no one size fits all solution, probably, but we can see which effectiveness criteria they're hitting and what needs to have a partnerships.
... We do have a glossary - what's next - strategy 2?
... We're going to do capability showcase and solution proposal and assessment phase.
... Getting away from Faster Payments and moving on to Strategy 3.
... Strategy 3 - payment security, we want to reduce fraud risk
... secure payments is around coordinating security industry - lots of different participants there as well. Requirements coming out is useful to this group - we've gotten input from broad set of stakeholders.
... In first year of secure - they focused on two things - future focus areas for security and then collaborating w/ faster payments folks.
... What came out of there are areas of focus - payment identity management - secure identities / trust - issues around law and regulation, information sharing for payment risk and fraud - FSISEC, how do you share problems w/ one part in the payments system w/ others.
... as far as timeline for task force - they had a task force meeting where they identified 12 payment problem statements. They launched 1-2 new groups to deal w/ that.
... This group provided safety and security sections for effectiveness criteria - Erik Anderson is on security

<Ian> Next: Payment identity management

Pat: What's next - payment identity management spinning up on payment identity - so verifiable claims is important there.
... There is Web Authentication WG - that's important to this work.
... Strategy 4 - payments efficiency - B2B payments, check based - promoting small business toolkit - B2B directory, exchange payment information securely - finally, looking at business model/governance issues. Business payments association - we have directory proof of concept - trust/governance/security - how do we make sure there are strong operating rules for folks participating in the system
... Fed is in leader-catalyst role - collaborative approach.
... So year one accomplishments - ISO20022 - we've done education/outreach on ISo20022
... Repository for research in that space - high level plans for ISO20022 for wire transfer in US and how to work w/ ACH same-day payments.
... Implementation for ISo20022 for wire transfer
... Strategy 5 - Enhanced Federal Reserve Services - we're doing work internally to enhance services for new payment solutions - but inside the US Fed - national settlement service, work to support NACHA same day - collaborating w/ FSISEC w/ information sharing.
... What's next? Implementing enhancements to FedACH SameDay service and global remittances.
... discussion topics effectiveness criteria, progress report.
... This US Fed group is a very open group - broad stakeholder engagement, on twitter, youtube, etc.
... Lots of information out there - questions?

dezell: I know they've been asking for submissions, lots of hype that these things are happening, how far along are those submissions?
... I know there are a couple of organizations approaching fed w/ ideas - we needed a standard framework for evaluating - if we wanted to submit something, I could talk w/ them about it.

<Ian> m4nu: I am aware of people who are going to submit; they are prepping their submissions

Pat: There is a long window for submissions - not many submitted yet, but there's lot of stuff to go through.

Doug: Feedback from W3C - US Fed is US centric - feedback from outside US is welcome, right?

Pat: Yes, absolutely - interoperability internationally is a big thing for us.

<Zakim> m4nu, you wanted to propose mappings from effectiveness to work we're doing (scorecard).

Pat: The legal requirements in Europe are different than in the US - we're looking for ways to make that faster/more efficient but respect those other jurisdictions

<Ian> scribenick: Ian

m4nu: Three or four months ago I started mapping effectiveness criteria to our work.
... now that this is public we can publish this document.
... the IG could publish a doc and write up what it is, can, or should address.

<Zakim> Ian, you wanted to ask about notes on criteria

<dezell> scribenick: m4nu

Ian: I read the criteria and took notes on flight over - high-level observation - criteria seem to be distinguishable in two categories.
... There is an infrastructure category and a product category.
... There are things like documentation of the product that aren't relevant for us.
... I will send notes to the group. There are some here that could prompt some discussion.
... The first one on ubiquity - largely about infrastructure - Web meets that... call out to multicurrency payments - what does that mean?
... I need to be able to pay in any currency? Or be able to pay w/ multiple currencies at the same time.
... I don't know if that's infrastructure or API - do we need to support multicurrency in our API or is that out of scope?

Pat: if you're dealing w/ payment across borders - solution dealing w/ Europeans being able to pay in US.

Ian: Under E5 - compliance - to what extent do we need to transmit data to ensure compliance.
... E.5.2 - compliance controls - don't know if there is an impact at the API level.

Pat: if you have regulatory compliance to view details of payment for specific party, not one party to the transaction.

Ian: There may be signature requirements, for example.

Pat: Maybe not the payment part itself, but alternate service APi to do that.

Ian: E.7.1 - notice - push API work - use web to do notification - API being relevant.
... 5.2 - to what extent does pushing on a button active user consent?
... I don't know if task force gets into user consent.
... If it's legally binding, what constitutes user consent?
... Section 5.6 on fraud mitigation - extending API into some future version - fraud mitigation - interested in doing that in a way that's privacy protecting.

<wseltzer> ["consent" is hard (see DNT); user interaction will arise in webauthn]

Pat: As we think about frameworks for standardization, it's easy when you're dealing w/ just one country - where it gets harder, international payments, multicurrency payments - framework/scaffolding - so core of that scaffolding is a smaller footprint. Allowance for specific regions - china vs. US, what can the nation's regulators see?

Ian: I suspect there is more work to do on crypto work and web authentication work. This is the prompt for people to say they're interested.

Kris: you mentioned some sort of a repository - ISo20022 repository -

Pat: US Market only - help w/ outreach so people here can understand ISO20022 - with US, if we were to change systems over to ISO20022 - transition to new one is difficult undertaking, especially for very small banks.
... Technical options for smoothing migration - we're not duplicating content.

Kris: ISO20022 Architecture WG is looking into that as well

dezell: Is anyone having trouble accessing IRC?

Ian: I'll help set those people up.

dezell: I want to echo a few things Ian was saying - the ubiquity section is a way we can contribute - we can probably do better than anyone else on the ubiquity front.
... This can be a way that we market to the bigger payment community. This is an effective communication tool if we do it right.

Erik: I'm going to look at some of this during the blockchain discussion.

paddy: Around settlement and clearing function that the US Fed has - around distributed ledgers - how might that potentially evolve w/ faster payments.

Pat: Take this with a grain of salt - we're looking at a big range of solutions - there are some interesting things happening in Australia w/ faster RTGS - we're looking at national settlement, market infrastructures as well - looking at faster, but careful that system that supports backbone - we have to be careful w/ that.
... So, we are looking at blockchain, but we're also looking at a lot of other stuff - we have a lot of forces at work to balance here.

Katie: "Accessibility" doesn't mean what it does at W3C - there is a smaller section that has to do w/ disabled persons.

pat: We want to avoid a system where 1-2 providers become over entrenched.
... To your point, end user access to this system will not come from Fed, probably more from banks and money transmitters - make sure core is accessible and available.

Katie: When you point to laws, please point to ADA.

<Ian> Katie: Add Rehab act / ADA

jyrossi: Looking at relevant interoperability considerations - mostly about currencies, entitlements - some legal consideration connected with how the payment is dealt - irrevocability.
... The timeline it's not possible to revoke the payment - this is not listed here - it's a point listed in S.3
... There is a link toward legal framework - but afraid that link doesn't work - this is the kind of stuff we have to be cautious about - to keep in mind, PSD in the EU - we have strong protective rules toward payer - payment could be revocable up to 13 months after payment. this kind of difference could be hindering.
... Talk about the jurisdictional requirements.

Pat: This is my personal opinion - wrt. cross border payments US and EU - framework that might be put together is super set of requirements on both sides of equation - there may be conflicts on legal/reg

<Ian> Pat: Revocability as an option

Pat: Nucleus of standards - tightly defined, European regulations should be able to be plugged in - or other requirements. We shouldn't specify what criteria is there - we should enable plug-ability. International payments are complex, as you know.

Ian: helpful overview, thank you.
... If we were going to try to publish IG perspective - work w/ people on technology questions - one level down on criteria - not doing it in a vacuum.

Pat: I haven't thought how to apply what we do here back to US FPTF. Communicate those to Task Force participants. We're trying to be broad in participation. Discussion about technology standards around payments - we'd ask W3C, ISO, X9, etc. broad discussion. Maybe there is a standards forum that we could establish - there is more of course.

Ian: I think a standards forum would be interesting - not for what belongs where, necessarily - but collectively tease out what pieces are needed at different levels.

<Ian> +1 to a "standards task force" idea (with W3C and others)

Pat: Just thinking out loud now - we'd have to bring that back to FPTF to see what they think.

<Zakim> m4nu, you wanted to note how we might use these capabilities w/ deeper technical WPWG work.

Pat: This all came from participants in FPTF.

<Ian> m4nu: I think what we may need to do before taking back to the FPTF is to get "our house in order"

<Ian> ...e.g., how do the criteria affect the IG discussion and also the WG scope

<Ian> ...then we could report back to the FPTF

<Ian> (I like the idea of the "standards" track)

<Ian> m4nu: So we should do an internal report first.

<Ian> ...also, Connie would be very helpful in getting our stuff before the financial community

<Ian> m4nu: The other thing is to look at how the other criteria map to the specs we are working on today.

<Ian> ...this has a lot to do with payment systems, and less to do with e-Commerce/checkout

<Ryladog> To Pat for "Faster Payments Effectiveness Criteria" document -- Please add to L.1.4: Rehabilitation Act Section 508 (for govs) and Americans with Disabilities (ADA) to the set of laws to comply with.

<Ian> ...I don't recall much around e-Commerce discussion in the FPTF

<Ian> ...so I think there's an item for the IG, which is a "score card"

<Ian> ...and there's an action item for the WPWG that points out technologically how we achieve some of these items

Pat: One of the things we could do is go back to FPTF - payments systems - collaboration between standards bodies - propose Fed spearhead something to bring standards folks together on payment standards.
... Again, my personal perspective - because of all the focus on improving payment systems - lots of standards bodies setting standards, but they're not coordinating w/ each other - something more formal may be helpful.
... I'm here until Thursday, if folks have questions.

dezell: I'm hearing sentiment that having a Task Force that would clarify what our position is on US FPTF criteria may be helpful.
... Could you offer your perspective on how our capabilities document relate to effectiveness criteria.

Pat: Personal opinion - w/ capabilities - we had to take a more technical approach - identity/credentials, settlement, e-Commerce, we focused on that to do core scaffolding - web checkout, other use cases are part of payment ecosystem - common capabilities - where we could take capabilities framework - are we on right track?

AdrianHB: The work that's being done here is establishing criteria for national payment system for US - it's not participating guidance for payment participants?

<kris> it's gonna be a very short comment

Pat: I used "ecosystem" term deliberately - aggregate term - work on task force - industry providers can come forward and say "we think we have a way to make X better" - this is a way for them to consistently evaluate them against one another - other mechanics at work here - market design, etc. Set of criteria to help industry participants evaluate - personal opinion, I hope there is an ecosystem

that comes out of this rather than one or two super providers.

AdrianHB: Payment systems have multiple layers - national payment system - local payment system.
... There are two ways this could happen - there are technical criteria you should evaluate - are there requirements from national payments that apply to what we're doing? Or do we need to figure those implicit requirements out for ourselves.
... Bear in mind, that's only US-centric view of the world.

Pat: These are not RFP requirements - we're just saying these are general criteria - broadly, will provide a better system.
... As you go from today's system, to tomorrows system to beyond.

Kris: Typically, multicurrency is provided by payment instrument... maybe digital wallets could support this in the future?
... Support these things as well - just a note.

<inserted> scribenick: Ian

<scribe> scribe: Ian


-> http://www.w3.org/2016/02/psd2-evert.pptx Evert slides

evert: We are facing a dramatic landscape change with PSD2

<scribe> ...new roles, new flexibility in the market

<AdrianHB> Concrete example of an implicit requirement for the WG from the Faster Payments Criteria would be if there was a decision that all payments initiated from the US must carry some kind of national id then the WG needs to decide do we add a national id field in our payment request schema or do we ensure that implementers in the US can do this themselves

evert: New roles PISP, AISP
... also strong authentication requirements
... can be executed through PISP or AISP

-> https://www.w3.org/Payments/IG/wiki/PSD2 Cyril's notes

(Slide: Impact on W3C Use Cases)

* Terminology

scribe: add PSD2 roles - PSU, ASPSP, AISP, PISP

* Augment payment phases

* Strong authentication requirements

scribe: no more support for password authentication

evert: regarding payment phases:

<AdrianHB> Account info services in US market have evolved on the back of "secure" screen scraping services (i.e. not APIs)

(Taken from use cases document http://www.w3.org/TR/web-payments-use-cases/)

<AdrianHB> EU move to mandate an API kills the market for screen scraping services which in the end is more secure for users

For Negotiation of payment terms, we need to take into account the services offered by the PISP (an intermediary that has its own offering)

Negotiation of payment instruments: Add selection of PISP

scribe: PISP could be chosen by the MERCHANT
... merchant says "here is who I work with"
... but the consumer could also use a PISP (wallet-like)
... so we need to look carefully into how this changes the dynamics of our use cases

scribe: when a PISP, that entity will initiate processing on either payer or payee behalf
... verification of funds could be done through PISP
... completion of transfer is interesting....that's a signal that it's binding, and also the impact of instant payments will be interesting...instant clarity on the status of the payment
... (that's outside PSD2 and more in instant payments land)

PSD2 article 97 requires strong authentication

-> http://www.w3.org/2016/02/eba-psd2.ppsx Geoffroy Goffinet slides

(Role of the EBA)

scribe: W3C responded to the discussion paper

-> https://www.w3.org/blog/2016/02/feedback-on-eba-discussion-paper/ Feedback on European Banking Authority Discussion Paper

(The role of the EBA slide)

scribe: scope of EBA includes consumer protection, monitoring of innovation, and payments
... accountable to EU Parliament and council

[We lose Mr. Goffinet]

(Article 97 on strong authentication)

nicktr: There are exemptions, and we are discussing actively now when strong authentication is appropriate, and when it's not
... I'm not sure we're talking about the end of passwords yet
... the really interesting question is that there are new players in the ecosystem (PISP, AISP) and where the risk lies is not yet clear

<m4nu> Web Payments Interest Group participants (picture): https://drive.google.com/file/d/0B1qnjblvbeDwUDk0OHlFYjZRNkk/view?usp=sharing

evert: I think liability may still be with Account service provider

AdrianHB: Yes, liability is likely to affect the authentication requirements. If you are willing to accept liability, you can soften the authentication requirements.

nicktr: Correct, and that's leading to discussions about insurance policies

evert: There is discussion of a "recup" process

nicktr: PISP don't have money in hands but cause payments to happen

evert: there are instructions for insurance

CyrilV: I think that the authentication issues, is quite a generic text....because for authentication we have a user experience issue
... for example, you can imagine doing strong authentication when you enroll, but not each time you have a transaction
... PISP and AISP are different between the two of them
... or, you may soften authentication for low-value transactions
... so you might see risk-based determination of authentication requirements

<wseltzer> W3C Web Authentication WG charter

wseltzer: Check out the new web authentication WG
... newly chartered
... there we are talking about "strong authentication" more narrowly than how it is used in PSD2
... this work is based on work from the FIDO alliance
... it's about strong authentication between a user and web site. It explicitly does not address identity / enrollment.
... it is explicitly about post-enrollment
... give users a crypto mechanism to re-authentication
... it will be a component of stronger identity requirements and user verification that groups like PSD2 seek
...QUESTION: Are there requirements for the Web Authentication WG?
... or ways that we should be using the strong re-auth module to build the aspects needed for web payments

[Geoffroy Goffinet returns]

[Pick up on slide 4]

scribe: mandate to develop strong auth in cooperation with ECB
... including discussion of exemptions
... when PSPs can decide not to use strong auth
... and mandate to protect user credentials
... requirements for communication as well
... especially between the third-party providers and traditional banks


scribe: PSD2 took effect 13 Jan 2016....
... next steps (Q2 2016) is development of requirements
... then publication of draft consultation paper on the draft RTS (3 months)
... then PSP have 18 months to implement
... at a minimum, September 2018
... We received 121 responses to discussion paper
... from now to summer we will develop the requirements
... we will issue a discussion paper in this case
... in this case we want feedback from market before we develop the requirements

evert: One of the questions that came up was on exemptions

geoffroy: We are learning from responses to the discussion paper

geoffoy: Some things may resemble what we've had in the past...eg. low value payments
... we are listening to what the market is expecting us to define
... one of the most complicated areas is about risk analysis performed by PSPs

[12:33] <Ian> ...next steps (Q2 2016) is development of requirements

geoffrey: Need to hear views of market on topics like risk analysis

<Zakim> m4nu, you wanted to suggest scheduling work to map PSD2 technical requirements to WPWG work.

m4nu: It looks like technical requirements are coming mid 2016

evert: These will be regulatory requirements...not deep technical requirements

m4nu: What will the IG do with that output?
... Will we map those requirements to that specs.

geoffroy: When we talk about technology standards...we don't mean industry standards. To give you a concrete example, we have technical standards on capital requirements
... that's just how the legal instrument is worded
... what is clear that we must do is "requirements that standards must comply with"
... we are not going to overwrite standards, just list the requirements to comply with our regulation

jheuer: Does the wording 'consumer' or 'customer' imply the person being known and unanimously being identified or is e.g. anonymous payment still possible?

geoffroy: We have a definition in PSD2 for strong authentication
... but I think there is a distinction to make between defining a customer and authenticating a customer
... we are more focused on the latter
... we want to be sure that those that already have payment instruments are the people actually using them

<Paddy> +q

(Strong auth)

scribe: challenges like tough security v. ease of innovation
... or tough security v. usability

or ...interop between ASPSPs and all PISPs/AISPs v. flexibility for market participants

scribe: e.g., if we want ISO20022 messages...the question is how far to go
... tradeoff in how far to go with standards requirements
... discussion paper will look for market input
... on strong auth, exemptions, privacy , standards requirements, and other work like electronic identification

Erik: My understanding is PSD2 is to allow third parties to act on user's behalf ... so need access to account information for example.
... I think we have the same concepts in financial services ...debt and collateralization

geoffroy: PSD2 says clearly that the third party provider has the right to use the tool that banks use to identify the customer
... the third party provider can redirect to the bank for authentication
... but there is another business model ... not yet clear
... how it will be explored...parties could develop their own security mechanism and issue their own credentials
... this is not yet clear yet for us

Paddy: The scope of PSD2 seems to be more about payment initiation
... is it getting into clearing and settlement as well?
... is the EBA or anyone specifying those regulations?

geoffroy: What we are covering is retail payments
... the part of the interaction between user and bank
... what is going on in clearing and settlement; PSD2 does not touch on that
... We don't yet know whether we will go beyond third-party communication with banks or broader

evert: We will look at what this means for our use cases
... it seems that impact of PSD2 is probably closer to IG work


<Zakim> m4nu, you wanted to note that we may want to modify flows based on PISP stuff

<ShaneM> scribenick: ShaneM

Verifiable Claims Task Force

Manu introduced himself...

The VCTF was given 3 things to do: 1) draft a problem statement and clarify if it was an accurate and unsolved problem by doing interviews etc.

scribe: gather data to determine if there is a desire on the web for an ecosystem.
... talked to a number of experts suggested by W3M, and some others.
... one is here: Christopher Allen - author of SSL and TLS.

<Ian> Final report of VCTF

scribe: Drummond Reed, etc. people who have worked on a number of the existing technologies in this space.
... problem statement presented.

Problem statement asserts that there is no user centric standard for exchanging verifiable claims (credentials, attestations).

It is really hard on the web to say my loyalty card number is X, I am a citizen of Y, whatever.

These are all self claims today. It is not verifiable.

You trust it because you trust it.

Surveyed 43 organizations (just before TF started) and asked what their problems were.

scribe: asked what they are doing today? Asked if they would help if there was work at the W3C.

Interviewed 14 security, identity, and credentialing experts.

77 people in the community group / task force.

<m4nu> Slide deck for this topic: https://docs.google.com/presentation/d/1K6VHQ38XCoGfadNmE1OVCkS7hq32XiBfq-iMCVN8o68/edit

(draft final report - will update based upon what we hear in this room)

(presents findings - see slide deck)

Lots of work has already been done. look at it.

Make sure there is a compelling business model. What are the financial incentives? Why would anyone go to the trouble of doing this?

scribe: we asked ETS and others if there is a business model. They said yes (with qualifications)
... work to do to determine what would need to be done to establish a viable ecosystem for each industry.

Three things people seem to want done. Format, Messaging, and Protocol. But pushback on the protocol.

scribe: So let's not do the protocol. But then there is an issue with the vision of the whole thing. Protocol is important so we need to communicate everything well.

Is it scalable?

scribe: if this takes hold, there are thousands or tens of thousands of entities that might do it. We know we can do 300 today. We don't know if we can handle all of them.
... the counter point is that not everyone has to trust all of the issuers. There will be islands of trust by industry.
... so we think that there ways for it to scale, but in the worst case we can fall back to the 300 CAs we have today.

What is the business model around the basic infrastructure?

scribe: need to make sure the basics are in place.

It can be hard to get to an Agent-centric design.

scribe: today we are browser-centric.
... agent centric is hard to update quickly.

Long lived identifiers can be a concern

scribe: it is possible to track people with a long lived identifier. People are bad at retaining their private keys. How can credentials be revoked? What are the liabilities if credentials are stolen?
... Fraud and abuse is a serious problem. But we already have it.

There are lots of areas of concern with Verifiable Claims.

There are SOME areas of consensus:

scribe: The problem statement is a real problem. The people we talked to wish there was something like a user-centric ecosystem.
... Reuse widely deployed tech if you can. If that fails, come up with something new.
... Where should we do it? People think W3C and IETF seem to be the logical places. A few said "we don't feel IETF is necessarily right - it might be nice to have a fresh set of eyes."
... some others said "maybe protocol at IETF. but if that isn't in the first phase, then don't start at IETF."

Clear Use Cases exist. And they apply to payments.

scribe: people responded to surveys about what the most important thing was to them in the space of claims.

VCTF asserts that there is a minimum first step.

scribe: some people looked at the record and said "I don't know if this is true." VCTF examined this and said "no - we believe there is consensus on the input thus far."

dezell: Since the answer was "W3C / IETF seem like the best places"? Was it self selecting? Did we talk to people at OASIS?

Christopher: I am in the relevant OASIS group as is Drummond Reed.

<Zakim> dezell, you wanted to ask about the survey saying "W3C+IETF"

manu: was it self selecting? Somewhat, but OASIS didn't reply to the survey request. We talked to Kantara initiative, OASIS, W3C, IETF representatives from companies.
... OASIS people said "probably not".
... IETF responses said "It is hard to get things not protocol related done there."

magda: no one really wants to handle key management? Would the task force handle it?

manu: no. well. look at it, but the solution can't be "just let the users manage their keys". There needs to be at least some options.

mountie: What is the difference between Web Authentication, strong auth in PSD2, and credentials in VCTF?

manu: Web Authentication is not dealing with cross origin / multi-origin claims or credentials.
... example. Your drivers license is issued by the DMV to you. You then show it to a police officer. That is an example of a cross origin credential.
... as far as PSD2 is concerned, the VC stuff is inline with some of the stuff that they want to do.
... web application has clear relationship to PSD2. if you want to authenticate with your bank, you might use web auth.
... if you were doing an international transfer and wanted to reduce risk, you might use a cross origin claim.

mountie: origin is normally server-side. Do you also think that a mobile app can verify the credential and be the source of the origin.

manu: there is overlap between claims and payments in terms of user interaction.
... in payments, you might be shown a list of payment sources. In claims you might be asked for proof of age. you are shown a list of available claims you have and selection the one you want to use.
... one of those could be an application that is sitting on a smart card that authenticates you.

<Ian> [Wendy Seltzer leaves for a call]

dezell: point of order: let's ensure we have Wendy in the room when we are talking about overlap.

burdges: When you are talking about using a claim, assuming you wanted to prove yourself to a site and you don't want to show DL, then you might use a third party.

<Ian> Jeff: Third parties raise issues of data leakage. If you don't want that you need blind signatures

burdges: this could leak a lot of traffic that is analyzable.

manu: There are lots of standards that are not very privacy respecting. We are very concerned about this.

dezell: did you say "this is a hard problem. people cant keep up with keys. and we don't want to do it either." Is that what you said?

manu: we didn't punt it. There are lots of proposals. The WG needs to come up with a solution that is workable. That solution cannot be "let the users handle it".

<Ian> e-idas

<CyrilV> link to e-IDAS information https://ec.europa.eu/dgs/connect/en/content/electronic-identification-and-trust-services-eidas-regulatory-environment-and-beyond

CyrilV: you said about PSD2 there is a link to VCTF. I think there is a link to eIDAS more than there is to PSD2
... when you want to access things like tax information or school data, you can do something centralized instead of disclosing all of your information. But this is probably within e-IDAS.
... maybe the TF could analyze this.

manu: there are a number of initiatives within the EU about this. Estonia, etc.

<Zakim> padler, you wanted to ask for clarification on origin...

padler: feel free to punt, do we see this tacking self-issued claims as well?

manu: the hope is that there is a unified way to express that will cover all the combinations of inter-entity credential issuing.

Use Case review:

Shopping cards / digital coupons. customer loyalty.

scribe: people don't like to type it in.
... small stores would like this capability to ensure they can compete with large organizations.
... huge issues for small and medium stores.

Verified shipping address / billing address.

scribe: different take. reduce mis-shipped goods. Nearly 5% of goods are mis-shipped. Very expensive to fix.
... it is just people mistyping? Not really. There are many addresses in the US that you can put against a verifier, but there isn't really anything there.
... in West Virginia >30% or goods are mis-shipped because the addresses are weird.
... The third worst place in the US for deliver is San Bernadino, CA. It isn't just rural areas.

Proof of Account - you can reduce risk of international payments if KYC and AML has already been done.

Age restrictive goods and services - proof of age is a good thing from a regulatory perspective.

<Ian> +1 to coupons

Identity proofing can help with money laundering issues, large value transactions, KYC issues, etc.

Next Step: NCTF believes next step is to draft a charter

<Ian> draft charter

scribe: do that draft, get the use cases together, then circulate it around to the interviewees etc. and get their buy in.

Work on data model and syntax.

Clear vision of being able to circulate credentials down the road.

(manu shows very drafty charter)

Conservative charter. Very narrow. Specifically excludes protocols,

Ask is if we can go ahead and get this tightened up, then circulate around Interviewees.

CyrilV: Use Cases - customer loyalty. How can user-centric apply to loyalty cards?

manu: when we say user-centric, we don't mean what you think it means. This is definitely merchant centric.

<CyrilV> http://www.2d-doc.com/

CyrilV: in france we have developed some normalization for data encoding bank information and verification via protocols. This is an example of something that we could use.

<Ian> ("At last a solution to the problem of falsified printed documents")

CyrilV: this information includes data that would make an exchange easier.
... no one is doing it yet. because there is no business model for the issuing bank. It is beneficial for the OTHER bank.
... the business model is "you invest, and the other gain". If everybody around the table and everyone invests it would be better. But in a virtuous circle, the first investor sees little benefit.
... some government etc. are using it. I tried to get my bank to do it, but they were not convinced.

manu: yes - this goes to the concern about "what is the business model?"

Ian: Thanks, especially for slide 10. I remain skeptical about a broad aspiration. This list has a promising point (coupons).
... I have been wondering whether coupons is the next layer for the web payments API or not. That feels like it is a good fit for Web Payments.
... existing organizations are missing the connection to the user so far.
... digital coupons are redeemed 10x more often than paper coupons. But that is a HUGE undertaking alone.
... if we could get those people in the room and solve that problem, that would be big. Solving all the problems is a hard sell.
... solving a single problem might be an easier sell.

manu: the proposed plan is that we have a ton of use cases but it would be too hard to read. Create a draft charter, then whittle use cases down to something manageable.

<Ian> ShaneM: We really want to solve "a lot of use cases"

<Zakim> dezell, you wanted to ask about flows, asking for billing addr, etc.

dezell: the complexity that belies all of this... which w3c working groups would be involved in solving all of this. The simplified charter might have legs.
... something that does not show up on the list is billing address entry - it wasn't explicit enough to be compelling.

<Zakim> AdrianHB, you wanted to mention lessons learned in drafting payments WG charter

AdrianHB: had a lot of discussion about the WG charter. We were pushed by the AC to come in with incubated specs. The CG had some. But when the group started the impression was that the AC didn't think those were adequate.
... maybe because of the few people who were involved in the authoring.
... in the payments group, the browser vendors were key and they had not been involved in the CG work.
... a charter that is accepted needs to be right, and that the people who are backing it have contributed to the technical proposals.

jheuer: I have been working with the people and even tried to contribute. What did we learn? After 15 years what have we learn?
... the protocols we did not keep.
... what about cards? that is clearly agent-centric.
... users don't want to hear anything about this and that wallet. There might be wallets like that, but mostly users are excited to see one agent that deals with the interaction.
... W3C is a good place to take on the agent-oriented work and an API to manage the flow of transaction. Identity, payment.

<Ian> jheuer: There are 100s of protocols (regional, national, industry)...is value add significant?

jheuer: protocol? not sure. Will there be enough of a value add? There are already hundreds of protocols out there. Some might be good enough.
... we need to be open for the existing industry solutions.
... we can't just go in and solve a problem that is already solved.

<Ian> jheuer: I don't see EID protocols being integrated into w3c in 50 years

jheuer: It is okay to use a proprietary protocol if there is a frame around it.

<Ian> ...w3c can add value to use cases

<Zakim> Ryladog, you wanted to ask if anyone from X9 was an interviewee

Ryladog: I sort of agree with jheuer
... if we focus on coupons and loyalty, it might bring more merchants to the conversation.
... Were any interviewees from X9?

manu: No.
... I would like a clear direction...

Erik: let's go to lunch!

<evert> scribenick evert

<wseltzer> scribenick: evert

<Ian> Joseph Lubin

<Ian> Mark D'Agostino (Deloitte)

<Ian> Sloan (IBM)

Ian Jacobs introduces people in the room to people dialing in

Erik Anderson presents

Overview of blockchain by Erik

<Ian> [Erik holds up a diary "as ledger")

Cryptographic ledger, a place to write information. Using math to ensure and seal the contents in the ledger

Blockchain is a series of blocks linked

<Ian> (Quickee backgrounder on blockchain)

Bottom blocks are immutable based on the stack-based signing

Consensus: make sure that blocks have integrity

<Ian> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Feb2016/Blockchain_and_the_Web

Forks in the blockchain eventually disappear, by tsensushe longest chain winning consensus

<Ian> graphic is here => https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_Feb2016/Blockchain_and_the_Web

<zkoch> For people that are external, you can actually join the Hangout and see the presentation here: https://plus.google.com/hangouts/_/google.com/zkoch

Erik discusses the diagram (see link)

<Ian> Goals for today's presentation:

<Ian> Understand how blockchain might address use cases that are addressed today using web technology. In particular, use cases that are close in scope to what the IG/WG are discussing.

<Ian> Begin to identify what would we need from the Web in order to support blockchain solutions to those use cases (e.g., we need API to access secure element)?

<Ian> Non-goal is to have an introduction to Blockchain or bitcoin; we hope to provide pointers to useful intro material before the meeting.

Payments: mainly peer to peer cases. Also some micro payments cases

<Ian> (Topics for blockchain that relate to the Web)

Secure elements can be a secure channel

E-commerce, receipts, coupons

Coupons can be distributed electronically and bound to one user

coupling with payment instrument and the coupon itself

Licensing Ledger: e.g. in music industry.

Sheet music licenses with different fee structures. Linked data between payment details, licensing ledger and licensed devices

Time-based licensing, such as for concerts

Empower more self-servicing licensing models

Embed the license in the media itself

Ian: from W3C look at how web protocols may be influences by blockchain applications

Gregory: does not see the point of putting blockchain in licensing of music, as clearly identified point of distribution is available.

Blockchain was created to get rid of centralized timestamp server

Erik indicates that the use case is about licensing of the content, not distribution infrastructure

<ChristopherA> +q

Ian: blockchain involves secrets, keys. Bringing the capabilities to web applications may require access to secure hardware.

A charter is prepared for a Hardware Security Working Group

<Ian> https://w3c.github.io/websec/hasec-charter.html

Get access to keys which is interoperable

Ian asks whether there are any other key management primitives necessary

<Ian> (Christopher has been working on blockchain at OASIS)

Christopher Allen: these technologies have a huge impact and cannot proceed without knowing what their effect op standards may be.

Quick observations: blockchain is a whole bunch of technologies and innovation

Pieces can be extremely useful.

<Ian> "Proof of publication"

Proof of publication, e.g.

In the wallet space: loss of identity, loss of wallet

<Ian> "hierarchical keys"

Hierarchical keys, keeping a root key in safe storage to derive other keys

Blockchain never re-uses a key (which is totally different from IETF)

Be careful of the hype

<Zakim> m4nu, you wanted to note a couple of thoughts on what the W3C could do for blockchain.

Manu: lot of solutions package a lot of technologies together.

<AdrianHB> +1 on "Be careful of the hype"

Split these up, is there a universal format for data structures, what a block looks like

bitcoin, ethereum, ripple - what are standards what goes in each block?

How to handle n in m signatures

Try to figure out from looking in the field of technologies, are there ways to generalize things?

Enabling new blockchains, where you can launch a new blockchain with a new set of rules as easy as doing “a new recipe”

Mountie: more add-ons, no standard to express small numbers (rather than thousand separators in large number representations)

Adrian: two specs out of interledger work: a standardized ledger api

not a blockchain per se, just a ledger

<Ian> (IJ: What is relation between "ledger API" and "what PSD2 requires"?)

The other is cryptographic conditions (more specific to interledger)

Assign a condition and proof of fulfillment of a condition

<Ian> AdrianHB: PSD2 account similar to ILP notion of ledger

Erik: potential other interests to W3C

Content protection (content licensing and brokerage), linking to crypto biometric identifiers (FIDO)

Better persistence of indication of rights

Identity: not only “what you know” but also “when you knew it”

Identity is not only about data structures, but also about interaction with the environment

W3C is starting initiatives for self-service options to address privacy friendly identity management on the web

Using hardware: in the possession of the user used for access controls (such as age, financial identifiers)

Geolocation being important for identity as well

Blockchain is certainly NOT the solution to Identity as its too far from the point of origin of the user. However Blockchain uniquely solves 1 problem that has been eluding Financial Services for many decades, non-repudiation. If you use the above W3C specs as a tunnel/entry-point to the Blockchain you can put user assertions & claims on a public ledger yet keep the access controls to that information “In the users pocket”.

<Zakim> m4nu, you wanted to notes verifiable claims + public ledgers.

Manu: on Identity, non-repudiation using blockchain is an important use-case for payments.

Gregory: on biometry - used more and more as a security feature.

Always used in an already secure environment, such as an airport.

Warns to be careful to use biometry alone or identity management

<Zakim> Gregory, you wanted to discuss about biometry

Erik responds that biometry is used to unlock a secure device

Christopher: all the things you can possibly do with blockchain.

Two concrete for web payments group

<Ian> "bit improvement protocol"

Bit improvement protocol (BIP)

<Ian> https://github.com/bitcoin/bips/blob/master/bip-0070.mediawiki

<Ian> "This BIP describes a protocol for communication between a merchant and their customer, enabling both a better customer experience and better security against man-in-the-middle attacks on the payment process. "

BIP 70 being used by bitcoin, based on old netscape protocol

Candidate for web payments

Similarly, interesting innovations in BIP 47

<Ian> BIP 47

Anonymize how the payment was made

<Ian> "This BIP defines a technique for creating a payment code which can be publicly advertised and associated with a real-life identity without creating the loss of security or privacy inherent to P2PKH address reuse.

<Ian> "

You can know that something was received wo you can make the payment for it

<AdrianHB> http://www.plantuml.com/plantuml/proxy?fmt=svg&src=https://raw.githubusercontent.com/w3c/webpayments/gh-pages/PaymentFlows/Bitcoin/Bitcoin-Payment-Protocol-%28BIP70%29.pml

Trivial to add that kind of option in your own protocols

Also for privacy and non repudiation in the future

Adrian: documented BIP 70 as one of the flows in the WPWG
... linux foundation blockchain work is interesting

They are doing similar things, understanding standards across different blockchains

Releasing software components which can be re-used to build blockchain applications

Opportunity for standardized data models and protocols

Manu: BIP 70 - overlap with WPWG specs

Seems to be an 80% overlap

<Zakim> m4nu, you wanted to note that BIP70 looks very close to the Web Payments WG specs.

<Zakim> AdrianHB, you wanted to mention Linux Foundation

Joerg: we should not design specific protocols, but something to hold different protocols together

Christopher: different communities such as IETF and W3C. Takes a lot of time to create a shared language

Bitcoin community, blockchain community is very young and extremely concerned about timeliness

Frustrated about the length of time standardization takes, but it is beginning to fail them

They do need to slow down pace

Erik: voting

Prevent double voting

Security: not one encryption algorithm for “all the masses”

At least 5 different versions of elliptic curve in use

Regulatory oversight and insight. Analytics before and after data is written to the ledger

Wallet: current trend to use physical wallet in the form of hardware

Financial services more broadly: 235 bn in fines to large banks for failure in track of “verified assets”


Web API to the secure element

Write specific content blobs to the ledger

Erik points to the work of the Web Services Choreography Working Group

CHOR may not have found a lot of uptake but its cutting edge research and development haven’t stopped. Some of those folks stayed focused on solving the pragmatic needs of complex information systems.

If you combine the 2 W3C hardware specs + Blockchain + CHOR you can create the mathematical enforcement of a design-by-contract framework to address dynamic business behaviors.

A Language for conversations not data semantics

<Zakim> wseltzer, you wanted to comment on "API access to secure element"

Wendy: API secure element charter is under development. How to make that secure in the web context?

Erik: Apple uses biometric touch id to access the secure element, preventing it from unintended use

So each use of the api requires touch id, indicating to the user that something sensitive is happening

Adrian: a question for the floor: distributed technology related

How far do you feel we are from incorporating distributed protocols in everything we do?

<Ian> Q: URIs that can point into a ledger?

E.g. IPFS being used as distributed data in web page usage

Incorporating that in the web architecture, a stack on DNS, …

Erik: CHOR has done a lot of work in this space

Manu: Credential Community Group works on a decentralized hash table for identifiers

Could be fully decentralized network

Adrian: is there an appetite in the W3C to adapt the stack for distributed applications?

<Ian> (Gregory: https://bitseed.org/namecoin-dns-server/)

Doug: there is interest in W3C in blockchain technology.

What small pieces can we put in the web stack to enable blockchain characteristics or something similar to that

Pieces which are reusable in the stack

Verifiable attributes in blockchain is interesting.

Will be discussed in the Advisory Committee meeting

Wendy: what we see on architectural principles of the web is a distributed nature

Happy to put that discussion forward, we’re at w3c.org : )

dezell: break

<Ian> scribe: Ian

ISO 20022 Harmonization TF

(Kris Ketels and Vincent Kuntz)

-> http://www.w3.org/2016/02/iso-harmonization.pptx Slides for ISO20022

Mission: align flows with ISO20022 components, and collaborate on any required changes or additions to ISO20022

Kris: ISO20022 is ubiquitous in bank-to-bank
... ultimately in many cases, whatever happens between a merchant and bank, has to be processed within a bank and has to go to other financial institutions
... so we have a stake in helping out in this (ecommerce) domain

(List of task force members)

Kris: Please join us!
... Two deliverables

- a doc specifying the differences between what the WG is providing and what is in the ISO20022 repository

- work to incorporate web payment flows into the repository

scribe: W3C would be the submitter

Kris: On the first deliverable:

- in iso20022, we start wit the business processes

scribe: these are the portions we put into the repository, and they are reusable
... they are semantics-based and not any particular implementation
... use cases, terminology, etc. are being developed in the task force
... for us the web payments business process(es) defines "the scope" of the ISO20022 work
... and then we determine whether these business processes already exist in the repository or need to be added
... the second step is to work on the flows
... and the question again is how do these flows differ from what's already in the repository
... lots of discussions have already happened around the vocabulary
...question: what is the correct level of detail for the flows?
... what is the common denominator between for example JS API and HTTP API?
... what are the common components?

(Vincent takes over)

From the iso 20022 perspective, the first question is "what are the business processes"?

scribe: e.g., we have card business processes
... we know that there are some new roles that come from PSD2 (PISP, PSP, AISP)...those are not yet defined in ISO20022
... ISO20022 is extensible so this should be fine
... regarding terminology alignment, ...we plan to map our terms to ISO20022
... and then in the detailed flows we can define synonyms in ISO20022
... so you can use the terminology that is used today, but it will be linked to ISO20022

Vincent: Here are some existing business processes in the repository that could be reused in our work


Web payment work is mostly into "customer to bank" ... but we may have to rename

scribe: within "customer to bank" we have various details like:

* Order

* Accept

* Clear

* Settle

(Slide: example of card payment initiation)

Vincent: Now onto business transactions
... how to align web payments flows with ISO20022 business transactions

* define extensions to existing flows

* define new flows

* align or identify gaps in terms and definitions

(Diagram of ISO20022 payment initiation flows)

scribe: showing Creditor/Debitor/Debtor Agent/Creditor Agent

Vincent: next is the "logical model
... align the detailed web payments flows with ISO 20022 message definitions
... we might extend existing ones or define new ones
... and then define common, reusable ISO20022 components
... and again align terms

(Slide: ISO 20022 logical model)


* Need to define the ISO20022 business case

scribe: who are the users/sponsors (this is part of the submission)
... explain why new messages should be registered, etc.
... submission also includes estimated usage patterns for messages
... how will they be reused in the market?
... things that cannot be easily reused more likely to be rejected
... also needs to provide a timeline for development

Vincent: will need to submit new business processes, roles, transactions
... as well as any changes to existing components

<Zakim> dezell, you wanted to ask if Order customer-to-bank payment is at too high a level, or can we just start there?

dezell: You have "order customer to bank" . Is that where you see us attaching to the model, or are we going to add a new process?

VincentK: We'll need to do more analysis to determine that

vincent: There are more layers below the ones I depicted

dezell: Will this work (of the task force) work in parallel with the WG?

kris: We depend on the WPWG

Vincent: We've made progress in the flows task force but don't yet know what needs to be added to ISO20022

<Zakim> m4nu, you wanted to ask what the timeline is for this? and to ask about ISO20022 terminology harmonization (and our failing to do that so far) and to say that there are certain

<AdrianHB> manu: question around timelines

m4nu: There are some bits in here to try out the process
... I would like to experiment to understand how to use the process
... we've talked about terminology harmonization...we did make a decision in the WG to ask the IG about aliases
... e.g., merchant v. payee
... we never moved on that.

(IJ thinks that the WG needs to do that first)

Interledger Protocol

(Evan presenting)


<Erik> Ryladog, here is a document with images for you that I documented long ago. https://www.w3.org/Payments/IG/wiki/Payments_Initiation

adrianHB: This is an update on ILP work.
... ILP work is happening in the inter ledger CG
... that CG meets Thursday morning...we have about 130 people attending

<zkoch> Link for anyone who wants to follow along live: https://plus.google.com/hangouts/_/google.com/zkoch?authuser=0

adrianHB: the purpose of the day is "what's happened since October"
... we're not ready yet to come back to the IG and talk about chartering

<Ryladog> Thanks Erik!

adrianHB: that will come probably following the workshop this Thursday

evan: Payments work great today until you want to cross from payment system to the next
... payments are easy within a single ledger
... the world will never agree to one ledger....we need inter ledger protocol

<Paddy> +q


* open protocol gives (small) wallet providers with global reach

* neutrality

scribe: it does not advantage any payment processor or currency
... web standards need to be really neutral

* universal payments....between any people, currencies, and processors

Top use cases:

* consumer web payments

* alternative to paywalls and ads

* creative content license

* physical web

* open services

Evan: you don't want to build a specific cryptocurrency into the web...
... for people to be able to pay someone you need strong interop
... "open services"...you have open source "software" but not "open source services"
... more on that later


poem used for song used in movie

scribe: everyone happy with reuse but wants to be paid fairly
... use case: pay all three of them at the same time!
... as end user I want to pay the entire value chain
... if payments could go through instantaneously to anyone,

you could define a license that includes other licenses

scribe: so you can pay any number of people in the chain

What makes this possible:

* Push based payments

scribe: (pull would not make it easy to embed payment information licenses)
... open protocol
... neutral enough to embed in standards
... universal payments
... today there is no payment method in the world that is sufficiently universal

paddy: Great presentation. Have you taken into account ledgers that are not just currency

evanschwartz: Yes, that's a big topic in the ILP CG
... it's easy to talk about currency, but the inter ledger protocol is generic enough to let you move non-fungible assets

CyrilV: In the CG do you think about relationships that are underlying these topics?
... e.g., contractual relationships

evanschwartz: ILP point is to not require exponential contracts...you chain them together
... like the internet, things are forward along
... same idea of network of networks
... open question on contractual frameworks that should be necessary; in many ways it's like correspondent banking today
... you do need relationships between processors, but everyone does not need to have a relationship with everyone else

CyrilV: Structure of the contractual relationship is complex....

AdrianHB: Contractual relationship is between connector and the 2 ledgers
... depending on what the ledgers allow the connector to do (e.g., guarantees, size of escrow) the relationships will be different
... e.g., in an ecommerce relationship with low values, will be different from, say, interbank payments

<Zakim> m4nu, you wanted to ask what are the minimum number of specs required to get interledger off of the ground. Who will commit to the WG? and to ask about location/time for workshop

AdrianHB: large banks will largely fulfill multiple roles (ledgers + connectors)

m4nu: You mentioned a number of specs or technologies.

AdrianHB: There are reference implementations
... we have not turned that into specs

evanschwartz: We have some idea of what kinds of specs are necessary to make this work. The very basis of it is that you need some way to express a cryptographic condition that's understood in a uniform fashion in all the different systems.
... if I want to set up escrow across them need that kind of interop
... to make the system "nice to use" it would be good to have a standard ledger implementation
... and the third is a connector API

m4nu: Who is committing to do work in a WG? Who has said "We'll join"?

adrianHB: We don't have WG commitments yet. But lots of interest (at various degrees0
... I would love it if we had money moving in this fashion in 2016


Registration for ILP Workshop is OPEN


Thursday, February 25, 2016 from 9:00 AM to 1:00 PM (PST)

at ripple


Erik: Use cases to consider
... you might be able to use a ledger to do instantaneous transactions...but some things don't arrive until the future
... you need to sequence events to keep collateral held until collateral moves in the future

adrianHB: The crypto spec deals with a variety of constraints (including "something arrives physically")
... so the crypto condition can have complex fulfillment conditions (time-based, smart-contract-based, etc.)

brian: "inter ledger ledger" was used.....presumably this is a ledger that is part of this system
... does the framework guarantee that payments happen?

evanschwartz: Today you _could_ have a setup where I'm on paypal and want to send money to mesa....
... ILP solves the problem of "what if the other party facilitating the connection is not trustworthy?"
... ILP ties the two transfers on two different systems together using the common crypto primitive
... in theory you could have disconnected networks (where it's not possible to pay A to B)
... goal is to make it technically possible (even if social reasons to gap)

paddy: Are you also addressing the identity part across the ledgers?

AdrianHB: No

evanschwartz: The ILP protocol is low-level. Depending on your use case you may have different identity requirements
... we want to nail down the interesting use cases then figure out the requirements
... e.g., bank-to-bank requirements are very different from micropayment requirements
... as long as you have some way of referencing the accounts.

AdrianHB: My assumption is that there will be groups that define a standard among themselves built on inter ledger...where they say "We will use ILP and identity will be done through technology X"

<Zakim> nicktr, you wanted to ask if pull payments can exist in an interledger world?

evanschwartz: that's a place where verifiable claims work would be useful

nicktr: Does ILP not work with pull?

evanschwartz: Good question. I am not a card expert.
... you could build a pull payment system on top of a push based system where the payee has a way to get authorization to initiate the push
... if I were thinking about everything in terms of wire transfers (typically PUSH)
... if there were a way for me to give you permission to initiate a transfer, then we'd have a pull system

AdrianHB: Nothing prevents you from doing pull on ILP but it's designed for push

<Zakim> dezell, you wanted to ask what's new if there's time.

dezell: How are you feeling about CG progress?

AdrianHB: All the work is open source...community is well-engaged
... we hope that Thursday's meeting will kick start the process and people will raise hands to get involved in making some use cases a reality
... no ask for the IG yet

evanschwartz: One reason we wanted to present today is that we want to keep you all who are not directly involved apprised of the progress and think about some of the possibilities
... and to inspire people to think about "what you could do with ILP in place/"
... that's for the IG...and for the WG we don't want the API to preclude how this could be used as a payment method

IG Checkin

-> https://www.w3.org/2016/02/ig-checkin-201602.pdf David E slides

<wseltzer> scribenick: wseltzer

dezell: trajectory of how we came out from Sapporo

[slide 2]

dezell: we need to know what the IG thinks

[slide 3: high-level scorecard]

dezell: IG participation is still good
... we know there are some segments of fintech we'd like to see better represented

<Ian> (Currently 129 participants in the IG)

dezell: participation in other W3C groups: fair

<Ian> https://www.w3.org/2000/09/dbwg/details?group=73816&public=1

dezell: lots of our momentum has gone to WG
... that's good
... it may be time to turn back to the IG
... industry engagement: ok
... roadmap, capabilities, slid backwards
... wallet and wallet API, not prioritized because it's moved to WG

[slide 4: participation in the IG]

Ian: Agenda drives interest
... keep hunting for topics of interest that represent business needs

<Ian> Ryladog: Coupons! That will bring merchants and consumer groups to the table

Ryladog: If we take on couponing, I believe that will bring lots more merchants, consumer groups to the table

<Paddy> +q

dezell: Connexus has mobile, couponing. I volunteer Linda

<Zakim> AdrianHB, you wanted to ask about PSD2

AdrianHB: PSD2, 2 possible areas of interaction
... driver of requirements for us, opportunity to promote existing W3C work as response to their needs.
... looking at what's happening in Europe in those 2 ways

Ian: I talked with Geoffroy about liaison opportunities, but they don't do that

evert: they talk to Central Banks

AdrianHB: Secure Authentication. If W3C produces a spec, and EBA produces something different, that sounds bad.

evert: EBA will formulate requirements and exemptions, not the technology

AdrianHB: so we should distill the requirements to other W3C groups

Ian: correct

Magda: Participation in other W3C groups; I recommend we spend more time focusing on that
... to get clarity and cohesion across the groups, to help get to a successful standard
... spend more time talking to other W3C groups

Paddy: re coupons and rewards. Card-linked-offers consortium is growing
... there may be synergies. I introduced them to Ian

<Ian> https://www.coupons.com/card-linked-offers/

<Ian> http://cardlinx.org/

Paddy: Card Linx

<Zakim> padler, you wanted to mention comment about core providers (ex. FiServ, Jack Henry, etc) as well

padler: comment about adding core provider participants
... to help get the smaller banks in
... providers who run the back-office of many smaller institutions

jheuer: I'd like to see big picture across W3C groups
... identity is a topic for everyone
... working on it only for payments is less useful
... agent work, something users will appreciate
... several connections to hardware security

dezell: I hear you asking for a matrix, so we know who's doing what
... re wallet, we've put that into the hands of the WG

jheuer: the IG, in addition, should look at functionality of the user agent

<Zakim> m4nu, you wanted to ask which groups?

m4nu: I'm hearing "coordinate with other WGs".
... but many of those groups are new

<Magda> -1 new- is a good time to engage

dezell: [slide 5]

Magda: at the time of a new charter is a great time to engage with groups
... webauth, crypto

[slide 7: industry engagement]

<Ian> BIAN => Banking Industry Architecture Network https://bian.org/

<Erik> -1

[slide 8]

<Zakim> padler, you wanted to ask about BIAN?

padler: a heads-up on BIAN
... possibly for a future call

<Ian> Magda: +1 to having a summer FTF meeting and focus on roadmap

Magda: I suggest we have a summer session, focusing on Roadmap

[slide 9: deliverables in detail]

<AdrianHB> +1 to summer FTF and a tight agenda and goals for that

<AdrianHB> goals = deliverables for the FTF

<Erik> https://imgs.xkcd.com/comics/standards.png

Erik: it's hard to share the work-load of reviewing closed-access specs
... hard even to identify what's still relevant

<padler> +1 to summer session

Ian: we've started some conversations around ecommerce

<Paddy> +q

Ian: after digital marketing workshop

Paddy: MCX might be a group to reach out to, merchant consortium

[slide 12]

[slide 13]

dezell: tokens and identity remain important, difficult to define
... my suggestion, start to include proximity payments

<Magda> +1 on proximity payments

Ian: in various conversations, topic of tokenization coming up frequently
... might want to explore what that means for security, various stakeholders

[slide 14]

nicktr: proximity payments, for the most part through native apps, out of scope?

Ian: NFC and Bluetooth CG might be moving work back to WGs

<Ryladog> ach Ryladog

[slide 16]

dezell: let's start serious discussion on ecommerce
... flows has gone to WG

<Zakim> padler, you wanted to mention independent use cases of identity and commerce..

padler: specific to ecommerce, use cases that don't involve payment, but kyc+perks
... capabilities

<Erik> +1 to Pat.

padler: commerce is broader than payments

Ryladog: we keep running out of time for additional topics
... I'd like to see 2 days for IG meeting
... and specific dedicated brainstorm time

<Ian> (Ryladog makes a fair point)

<padler> +1 to time for interaction..

<Magda> +1 to not enough time, and brainstorming time set aside

<jheuer> +1 to have time for more discussion

AdrianHB: couponing and loyalty interesting, but I'm not convinced W3C should be standardizing a coupon format
... or how a merchant should recognize a customer
... I'm not convinced there's a problem that needs to be solved

Ian: the connection is people through their browser
... not internal identifiers, but interop

Visa Developer API

<Ian> (Vish Shastry)

<Ian> scribe: Ian

<scribe> scribenick: Ian

Visa Developer API -> https://developer.visa.com/

scribe: Visa started off with punch cards and mainframes and has moved (with challenges) into the mobile world
... we've had modalities for getting card data

(Some more Visa history)

scribe: can't reach Visa network over the open internet
... fraud an issue for all of us
... to deal with new cases, we are updating our developer platform
... opening our APIs and the network as a whole...making available to developers
... let's look at APIs
... including tokenization thoughts

(CyberSource Payments API)

scribe: our approach is to keep things primitive
... there are basic functions like authorize and capture
... refunds, voids, search
... there's information about request and response headers
... have a look to see how it might inspire W3C's work
... we expose Visa Checkout
... it's a sort of "wallet container"...allow users to contain a list of credit / debit cards
... people take to a site, authenticate, and reuse data

Another API: Visa Direct

scribe: spare case, Facebook messenger, many others using today

Vish: risk and fraud topics as well

* mobile location confirmation

scribe: with consumer consent

Visa Token Service

scribe: prevent the risk of fraud with tokens
... bind a token to a mobile device
... we can provide crypto credentials
... can provide dynamic data on every transaction
... again, trying to keep the APIs primitive

<Paddy> +q

CyrilV: Seems the APIs are defined not just for Visa...
... is the API just for Visa cards, or also able to connect to other networks?

Vish: Depends on the API...e.g., cybersource API can process payments for multiple brands

Vish: We as payment networks...our entire way of doing business is to insulate entities from banks.
... almost everyone that deals with visa has a relationship with some financial institution
... cyrbersource API is close to what Stripe has
... Stripe has an existing relationship with an acquiring bank
... we could in some cases do that but choose not to

IJ: Welcome. Want Visa input on our API and see where we fit in with your work

AdrianHB: Visa fits in in several ways:

* Payment App issuer

* Potentially publish instructions on how to do cybersource payments using the API

scribe: or it would be as simple as someone saying "it's a card payment" and someone gets a standard API response and turns into a submission to their API
... it would be a great exercise for use to test our API against the VISA APIs

Vish: But be careful.
... we found when abstracting away (to provide base level functionality)
... if you keep in mind that banks are in the ecosystem, banks like to add unique, value-add services
... they often look at APIs as commoditization and may not always be friendly to that
... they may want to offer APIs that give greater functionality

padler: Thanks for the presentation
... do you see Visa APIs as a "baseline for industry standardization" to be used across all card networks/
... braintree, paypal, etc. are simplifying things for merchants
... what's your take on that?

Visa: When we approach standards work we want to drive down cost
... one of the other things we realized over the past 5-10 years is that we have to provide platforms for innovation
... standards will help drive down costs and increase utility
... but at the same time they may be perceived as stifling innovation
... standards that don't accommodate new use cases easily

Padler: I'd like to see if we can move toward open industry APIs

<Zakim> nicktr, you wanted to ask about token requestor ID

nicktr: Question about tokenization API
... does anybody enroll get a token requester ID?

Vish: Today there are a small number but we'd like to see as much innovation as possible
... also thinking about certification program
... there will be a registry of token requestors

paddy: Are the APIs self-sufficient for on boarding a merchant?

Second idea: bi-directional API (take something in from merchant, then expose as Value-added-service) through another API.

Vish: No, the APIs are not self-sufficient for onboarding a merchant
... We have not been looking at the value-added-service use cases
... we have a small number of things we do...micro-transaction

erik: Tokenization!
... there's been a lot of talk in the industry using tokenization (format-preserving encryption)
... there's been talk of using similar approaches for names, addresses, etc.
... I jumped on X9 work about this
... is there any discussion in industry about using tokenization more broadly for passing around information?

Vish: There's not quite exactly what you are talking about.
... you are asking about tokenization broader than something like EMVCo

Erik: Yes, format-preserving encryption

Vish: there is not today, but something is coming that could be useful that way...eg., why can't I cryptographically hash that I can broadcast?
... one of the things we have been putting in place
... a lot of entities were not comfortable with EMV token..they wanted an abstraction above that...we announced recently a "payment amount reference"
... imagine you have a single account but you get give a different number depending on whether it's plastic, or phone, or watch
... so we are looking at giving a new number that represents "my account" whatever device or modality I use
... it can't be used for authorization
... I think it's the sort of thing you are talking about ... but it's a baby step

kriske: On standards "slowly evolving"
... it's something we call in ISO "controlled flexibility"
... when someone adds something to a standard it implies that thing is commoditized
... ISO is evolving to allow flexibility
... core support + extensions
... then extensions move to core

<Paddy> +q

CyrilV: Earlier today we had a chat about PSD2
... APIs for PISPs
... visa checkout mostly a checkout button on the merchant side
... do you intend to open up the API for the issuer side?

Vish: We have
... the documentation is not yet available but we have a number of issuer-facing APIs

jheuer: Tokenization approach from EMVCo seems fit for use for online usage
... do you have any implementations for secure elements, sim cards, etc/
... for offline replayable transactions

Vish: that's a thorny problem
... one of the things we are are trying to do with tokenization is that it is more secure with PAN
... part of the evolution is inclusion of dynamic data
... it's expensive for them to do that...we are trying to improve the tokenization standards to provide more flexibility

VCTF resumed

1) Write a narrow charter

2) Take back to the interviewees

<padler> +1 to proposing a charter..

Shane: Clarify - does this IG want the VCTF to do this

EriK: I would like to ensure that use cases I've mentioned are addressed

Manu: we can add use cases to our document and then the vctf will prioritize

wseltzer: Sorry I could not participate in the discussion earlier due to a conflict. One question I have: Is there payments interest in the VCTF work.
... can we hear from members of the payments IG "Should the VCTF continue to report back to the IG? Or continue the work elsewhere and report back to other venues?"
... the IG is not the only group where this should happen....due to wide range of use cases, I want to hear clearly that there are people interested in participating from a payments perspective

padler: In capabilities work, we broke out identity (including verifiable claims) because there are ways to share it among different use cases
... so it's not specific to payments
... though it contributes core capabilities to payments
... I want to see the work go forward and it has to be deliberately broad
... has to work cross-domain

<wseltzer> ac de

dezell: I have a specific use case that I care about
... I don't want work in this IG to shortchange credentials

wseltzer: My concern about broad scope is that "to satisfy credentials for everyone we would need everyone to participate"

<padler> +1 to clarify..

wseltzer: we can't claim to be doing work across industries if those industries are not participating
... the more people we try to satisfy, the more complex it will be to get their consensus, participation, and implementation
... my personal instinct is to start small with something that satisfies the needs of those who are most interested in doing the work.
... then build up to abstractions after that
... start small and grow rather than trying to satisfy everyone

padler: I agree with you.
... when I say "scope of work has to be broad" I don't mean "all at the beginning"
... I like the idea of starting with practical use cases
... we could deliberately charter an effort so that there are subsequent phases planned where we reach out to other verticals
... we don't have to define all the use cases for other industries, but knowing they are coming up can help us create a standard that will work more broadly

<Paddy> +q

Manu: One way to approach could be to have a broader charter, get feedback, and then narrow based on what people say.

<Zakim> ShaneM, you wanted to discuss the use cases and how they support payments specifically and to point out that the world series only has teams from the US.

ShaneM: You correctly point out that not everyone is in the room.
... the way to get people in the room is to have a room..people will show up (or they won't)

<Zakim> Ryladog, you wanted to provide train track and station example for the payment use cases, and Education use cases, and healthcare use cases

Ryladog: We need to write the expectations into the charter

jheuer: Identity is needed all over
... orgs drop it often because they perceive it as too complex. I think W3C could do something to that end
... If we come up with a payment set of tools, we will need to address authorization issues. If we feel we don' yet have what we need, we will need to develop it

Erik: I reviewed the VCTF (also internally at my org)
... feedback is that the work is targeting the wrong problem
... needs related to secure sequencing and choreography

<Zakim> dezell, you wanted to suggest a way forward

dezell: I have an idea for a way forward.
... +1 to manu's proposal
... think about possible new home for work if not right for this IG

<padler> +1 to keeping the work moving..

Jeffrey: To have a standard that targets the ethical side of things ("what we should do")
... you may have to be willing to accept something weaker

<ShaneM> +1 to doing the ethical thing.

Jeffrey: there's probably an opportunity here if crypto is done right
... push a lot of things to "being more ethical"

<Erik> Identity as a protocol, not a data structure

AdrianHB: It's not clear how syntax + model for verifiable claims aligns with what Manu proposed
... it's very narrowly scope, that I fail to see how we could charter that group for a specific vertical
... how would we charter a group that would create claims for a specific vertical....OTHER THAN by looking at specific use cases
... I am failing to see how we charter a group that is so narrow that is useful to a vertical
... I think we should let the WG do its work

<Zakim> AdrianHB, you wanted to ask what the charter will be for if it's limited to a vertical and to

AdrianHB: +1 to a draft

<ShaneM> +1 to letting the task force do their work.

wseltzer: From W3C perspective, the process works like this:

* Team works with proponents to write a charter

scribe: we look for a well-defined and achievable scope
... so for example for web payments you may recall that when we sent the charter back to the AC,
... there were formal objections that the scope was too broad, not well-defined
... we had to work with proponents to address those objections
... it's important to determine whether we have at the table the people necessary to do the things that the charter expects
... those are the next steps for a charter whether the charter is drafted in a CG or within an IG


* Task force will draft a narrow charter

* Determine which audiences are interested that will help determine where it next is developed?

(Significant support)

Minutes formatted by David Booth's scribe.perl version 1.144 (CVS log)
$Date: 2016/02/26 04:22:24 $