See also: IRC log
<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?
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
(Milestones)
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
[Break]
<Zakim> m4nu, you wanted to note that we may want to modify flows based on PISP stuff
<ShaneM> scribenick: ShaneM
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
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”
Observations:
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
(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
(Diagram)
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)
(Deliverables)
* 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)
(Evan presenting)
test
<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
benefits:
* 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
[Demo]
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
https://lists.w3.org/Archives/Public/public-payments-wg/2016Feb/0039.html
Registration for ILP Workshop is OPEN
http://www.eventbrite.com/e/interledger-protocol-workshop-tickets-21070974853
Thursday, February 25, 2016 from 9:00 AM to 1:00 PM (PST)
at ripple
jq?
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
-> 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
<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
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
PROPOSED:
* Task force will draft a narrow charter
* Determine which audiences are interested that will help determine where it next is developed?
(Significant support)
