W3C

Web Payments Interest Group Face-to-Face Meeting
16 Jun 2015

Agenda

See also 16 June minutes, 17 June minutes, 18 June minutes, Summary

See also: IRC log

Attendees

Jeff Jaffe, Dave Raggett, Wendy Seltzer, Katie Haritos-Shea, David Ezell (Chair), Manu Sporny, Jörg Heuer, Evan Schwartz, Daniel Schutzer Patrick Adler, Adrian Hope-Bailie, Mountie Lee, Laurent Castillo, Yaso Córdova, Nick Shearer, Evert Fekkes, Dipan Anarkat, Magda Sypula, Leandro Minniti, David Jackson, Erik Anderson, Samuel Weinig, Yean-Yves Rossi, Adam Muntner, David Baron, Mark Tiggas, Stefan Thomas, Kristy Cook, Srikanth Garnepudi, Arjun Jayaram, Arie Levy Cohen, Nick Telford-Reed, Zach Koch, Jean-Yves Rossi, Vish Shastry

Eric Korb and Richard Varn joined us for discussion on credentials.

By phone part of the time: Ian Jacobs, Matt Howarter

Contents

  1. Introductions
  2. Capabilities for Payments
  3. Use case / capability prioritization (Manu Sporny)
  4. Browser perspective (Zach Koch)
  5. Card security and the Web model
  6. Identity/Credentials: What do we need for payments?
  7. Web Settlement: Exchanging real value on the Web
  8. Glossary

Introductions

The meeting began with brief introductions around the table.

dezell: ... our group is focused on the Web, interconnectivity, the open web platform, browser
... This week's agenda is front-loaded
... we'll have breathing space over the next 2 days to come back
... We're in good position to start new activities
... We have to grow the activity as we plan it.
... With the wider group, assure that those are still good goals.
... Standardization, we have a mental check-list of what we're thinking now.
... Our sessions are short, so please keep your comments brief.
... Pay attention to the time.

erik: We also have breakout rooms.

dezell: Hot topic sessions and secondary standards topics. We'll keep a running list
... If you see a session that deserves a "hot topics" session, let me know, and I'll add it to the list.
... scribing: we take minutes in IRC. Please volunteer.

dezell: Also, a Vision Statement is under a call for consensus
... we're looking for all members of the IG to review, either comment or say you're ok with it.

dezell: ... [reviews agenda for the day]
Capabilities [Pat]
... Use Cases [Manu]
... Browser [Zach]
... [Lunch]
... Security [Laurent]
... Identity/Credentials [Manu]
... Settlement [Adrian]
... Glossary [Evert]

Capabilities for Payments

<padler> Capabilities draft

padler: lots of good content in roadmap, architecture
... focused on breaking down the work, fitting it with other topics
... Wiki outlines organization, capabilities, payment interactions

-> Capabilities: Where are we now?

padler: 5 groups of capabilities

Core and Security - Includes: Key Creation and Management, Cryptographic Signatures, Encryption Identity and Credentials - Includes: Identity, Credentials, Rights, Authentication, Authorization, Privacy, Discovery, Registration, Enrollment, and Legal/Regulatory concerns Accounts and Settlement - Includes: Accounts, Ledgers, and Legal/Regulatory concerns related to accounting and recorded ownership.

Payments and Exchange - Includes: Payment, Messaging, Clearing, Markets, Foreign/Currency Exchange, and Legal/regulatory concerns specific to Payments and Exchange of Value. Commerce - Includes: Offers, Invoicing, Receipts, Loyalty, Rewards, Contracts, Lending, Insurance, Taxation, Legal/Regulatory concerns related to aspects of commercial and economic interactions

<sgarnepudi> https://www.w3.org/Payments/IG/wiki/Roadmap/PaymentArchitectureWG

padler: broken down that way because of interactions
... e.g. person walks into a store

@@: question of scope: why start with pre-payment?

padler: loyalty, stored value, identity -- things a payment needs to interact with
... difficult to describe a payment without also talking about those
... we're not trying to do all those things here, but to point to them where they're happening
... we want to plug into work elsewhere

weinig: that ends up being very hard
... assuming that some other group's work is going to solve a problem.

padler: other standards WG is looking into that

schutzer: you should accommodate those developments elsewhere

<Zakim> m4nu, you wanted to ask that wiki is displayed at front of the room. and to talk about where roadmap fits into capabilities.

m4nu: capabilities doc is trying to help us understand the ecosystem
... roadmap asks what is the highest priority, smallest scope that we can attack

Ryladog: where do regulatory requirements fit?

padler: we've put it into buckets

nick: describing things that seem far from payments

padler: looking at the big picture, to say some things are out of scope
... start to show the connections, eg. identity, in the web ecosystem
... we can't define it just for payments, or conflict with work of another group
... so we have other elements in to define the boundaries

dbaron: danger, e.g. from XForms, referencing other things in development,
... ended up with a piece of tech so large that no one wanted to implement
... they ref'd things they were the only ones referencing
... too big for the browsers to build
... when you're looking at what other work is going on, look at who's involved with it
... will it be an additional burden to implementers?

padler: true. just because there are other stndards doesn't mean they're being used
... or implemented
... that's the job of the external reviews TF
... to help examine whether the work is useful, implementable

AdrianHB: question, what should be in/out of scope?
... we tried to separate capability areas to set scope
... looking at standards that exist, not just in development
... are they applicable to what we're tryng to do
... do they fit in the open web platform?

dezell: heading toward prioritization
... we've cast a broad net
... work that needs to be done to tell the complete story
... not that we need to do it all, but it needs to be done someplace for our work to make sense
... we need to be crisper
... also respond to noise outside that wants us to focus on other things

CyrilV: credential is an attribute of payment
... so if we need it for payment, it should be in-scope
... payment credential distinct from ID, government credentials

<Zakim> m4nu, you wanted to move through the rest of the presentation - time check

padler: we're working on prioritization
... coordination with other work
... identifying interfaces
... when we describe process as series of steps, it can become harder to see some of the interactions
... e.g. bi-directional communications
... so with the wheel, try to show the participants, interactions

-> https://www.w3.org/Payments/IG/wiki/Main_Page/FTF_June2015/Capabilities#Payments_interactions wheel diagram

padler: wheel allows us to be granular about the interactions and parties
... focus on who's going to do the work, iterative development of the work

weinig: you said the payments space, the commerce space. How do you differentiate?

padler: commerce deals with things like loyalty, receipts, invoices
... as oppsed to payment, which is movement of currency

weinig: how do you see payments integrating with the web?

padler: customer returning to the store, you want to offer a loyalty bonus, that's commerce
... when they want to initiate the payment, that's "payment"
... so differentiate accounts, payments, commerce
... each of those has a different dynamic
... regulatory

mountie: are you describing web, user-agent, or user?

padler: interactions (examples) are taking place over the web
... user is a difficult word, because it might be a person, might be an autonomous agent, corporate actor

Ryladog: for accessibility purposes, note that the text in the lower sectors can't be seen

jheuer: group has different views of "user"
... patterns in common?

padler: goal in the diagram is to focus on the patterns of interaction
... whether it's individuals or institutions
... focus on relationships

CyrilV: Capabilities, suggest some change of terminology
... instead of "accounts and settlement", "accounts and Ownership
... "clearing and settlement"
... "transfer of funds" rather than "payments"

<Ryladog> +1 to Cyril

CyrilV: move "payments and exchange" to "clearing and settlement"

AdrianHB: we'll talk about settlement later
... settlement is when you finally move the money
... ownership, I think fits into "commerce"
... most of what we call payments today isn't settlement, it's clearinghouse

CyrilV: managing accounts

padler: do we have the right capability groups defined?
... the right break-down?

nick: q about difference between payments and exchange.
... payments can create legal and regulatory obligations, seems to blend with "commerce"

padler: look at the example
... 3 steps
... if you take "payments" out of the bucket with "exchange"

nick: Payment implies commercial obligation

<nick> (in many jurisdictions ;) )

Arjun: identity is a much-abused term
... the ID you want is a subset to complete the transaction

padler: you need a specific set of info to facilitate transaction
... if there's work to standardize around identity, we'd like to plug that in
... I shouldn't need a separate set of identity credentials for payments

<Laurent_> +1 to Arjun

[more to discuss in an identity breakout]

padler: do we need to do more with terminology here?
... proposal from cyril
... id and credentials, accounts and ownership, clearing and settlmeent

erik: we're talking well beyond payments

schutzer: account management needs different info from clearing and settlement
... e.g. number of items
... different granularity

Srikanth: what's the driving force behind having "commerce" here?

padler: we're trying to keep the aspects separate

AdrianHB: loyalty is a small piece of commerce; more invoices and receipts

padler: if you have additional suggestions, please share

adamm: effects of standardization on innovation?
... e.g. receipts could have very different formats, purposes
... transaction record, proof,
... we could end up over-defining and not being very useful
... Also re identity, our charter says "privacy" but I'm not sure what we mean

<nick> +1 on privacy

adamm: you can pay $5 cash with no identity; coupling payment and identity too tightly undermines privacy

<Ian> [Adam, we envision a spectrum of payment scenarios and identity needs. We also, re receipts, largely agree and are looking for a very small set of terms on which we can standardize.]

dezell: we'll come back over the minutes looking for these points to return later

<Zakim> AdrianHB, you wanted to suggest a change to capabilities group

AdrianHB: clearing and settlement; accounts and ownership as categories.
... in the retail payments space, settlement is mostly separate

<aylcw3c> Adrian: Privacy and "tightly coupled" infringes on privacy

AdrianHB: real-time settlement is a separate important topic

Arie: consider the ontology
... clearing and settlement happen at the retail level, at the institution level; definitions are different.
... paying for stock is different from paying for apples
... lexicon should be democratic
... international

dezell: glossary coming later

CyrilV: commerce is buyer-seller issues
... id/credentials are payer-payee
... which are not necssariliy the same
... payment/settlement is funds manager
... the bank, not the account-holder

Arjun: commerce feels like a catch-all
... isn't loyalty just another entry in a ledger

jheuer: behind each sector in the circle are verticals

<vishshastry> offline comment - in many cases a payment / funds guarantee (not necessarily true 'settlement' or movement of funds between account providers) is sufficient to conduct a transaction. clearing and settlement standards may want to take this into account.

jheuer: prioritization decision should depend on where we can bring value, number of users

Kristy: as we look for the core, keep in mind that there are lots of others working in this space

<Ian> [Ian asks Kristy: What do you think should be "in"?]

Kristy: so set reasonable expectations for them

<aylcw3c> Kristy: draw the line between whats in and out

Kristy: if we're delivering in 2-3 years, consumer isn't thinking "online v offline"
... but holistically.
... it's all converging

<m4nu> +1 to Kristy

<aylcw3c> Kristy: things will look very similar in 3 yeras

Kristy: talking about immediate transfer of funds, real-time settlement; whose view are we looking at.

dezell2: important next steps, Charters.
... some of the work, like loyalty, is not in a charter, but a place-holder for thought

<evert> Dave just volunteered for next session

[break until 10:30]

padler: you're asking same questions we've been asking ourselves

<vishshastry> +2 to kristy. ecom use cases often have merchants authorize a transaction and only settle / capture after they have shipped a good, which can occur after a significant legnth of time

padler: how do we build a model that helps us move forward in loosely coupled, coordinated manner.
... can we agree on a framework.
... I'll make updates to the presentaiton page. If people have comments we haven't captured, please share

Ryladog: if you have comments you didn't get to make, add to irc

Use case / capability prioritization (Manu Sporny)

Agenda for discussion of use cases

<dsr> scribenick: dsr

We need to map the goals listed at the start of the page into concrete deliverables.

Manu describes the minimal viable platform for version 1.0

We looked through the use cases to identity which ones we want to support in version 1 of the web payment standards — loyalty and coupons were deferred to later versions.

We need to clarify over this F2F the position on credentials, and security

From the wiki: digital signatures, encryption, multi-factor authentication

Manu says we should make it very clear that multi-factor is not necessary for success in v1

The section ”Review mapping of use cases to priorities” lists things that are at risk

Manu explains that credentials may be needed to establish that someone is legally entitled to purchase something, e.g. alcohol.

Invoices in v1 is intended to be very minimal, amount, currency, very brief line item

Ubiquitous schemes are things that are widely used today, e.g. credit cards

Discovery is about enabling a level playing field for payment service providers

We should enable good privacy for payers as a default

We are missing a use case around authentication based upon today’s user id and password

Multi-factor authentication is about biometrics, PIN entry, secret gestures etc.

Do we support both payer and payee initiated payments?

Payer initiated payments is at risk for v1

Also at risk are delivery of physical goods, and electronic receipts.

<Zakim> dezell, you wanted to +1 both push/pull as important to the architecture.

David: +1 to having both payer and payee initiated payments, as these are both realy important

<Ryladog> +1 to David

Nick: registrationless, I would very much like to see that, as it is very important to setting up an account

<AdrianHB> +1 to David

<aylcw3c> +1 on Push & Pull payments

I also want to see biometric support for authentication in v1 so that we can move beyond passwords

Adam: are we assuming that there will be an end to end flow or are we talking about standards for small primitives?

<nick> Nick: Not having biometric authentication as a Version 1 use case is surprising. Standard doesn’t need to define how biometric works, but it should be a use case. We should look to the future for authentication, not the past (passwords).

Manu: primitives

<Zakim> zkoch, you wanted to ask about subscriptions as non-essential use cases

Nick: very good

<nicktr> thinks re: Nick's comments that we need to have payer authentication but we don't necessarily need to make that authentication biometric

zkoch: I also support biometrics and subscription use cases for v1

<nick> +1 for subscriptions. Anecdotally, we have heard great demand for subscriptions from merchants who use Apple Pay in app.

Manu: we tried to be very agressive about cutting down the scope of v1

Joerg: there should be ways to avoid getting into details of authentication

<nick> +1 generic approach. as long as we’re not limiting use cases to solely passwords in version 1

<yaso> +1

<jyrossi> +1

<Laurent_> +1, generic approach with one biometric use case

<vishshastry> +1 on subscriptions. also transactions designated by a payer agent - for example, my Nest thermostat orders anx air filter on my behalf once winter arrives

Kristy: we should talk about biometrics, and wonder how the use cases involve it

The second piece is about privacy, this is more of an assumption than a use case

Manu: every single use case has a field for privacy

<Zakim> evert, you wanted to discuss payment elements

Evert: I want to get back to peeling the onion! I want to see payments in simple steps:

  1. identification of the parties
  2. authentication of the payer
  3. confirmation on the availability of funds
  4. and finally settlement

Manu: where should these be described, in the use cases doc?

<Zakim> dezell, you wanted to talk about the "small primitive" approach.

David: For NACS, the most important use cases were on payer initiated payments.

I am missing soft identity. Websites are used to dealing with soft identity for offering discounts etc.

This probably doesn’t belong in the identity bucket.

<Srikanth> isn't the soft identity part of loyalty?

Arjun: I want to get back to privacy. We’re seeing a lot more interest in scheduled and recurring payments

<vishshastry> +1 on scheduled payments

<adamm> +1 soft identity

<Ryladog> Per Davids point.....Is 'soft identity' a 'single identifier' semi-authentication user case?

<AdrianHB> Is recurring payments essential to v1?

Erik: Bloomberg has 15 years of experience with biometrics. These tend to shift over time so we use them to unlock capabilities

<AdrianHB> It's appealing but not essential

<vishshastry> +1 on Erik's biometric insights

<CyrilV> +1 on Erik's point.
... I want to come back on the funds available point, when it is payer initiated you may have more information available

It isn’t just about funds present, but about the risk management

Dan: biometrics can be related to liability, and I wouldn’t want us to drop them from v1

<nick> yes, there are other possibilties for biometrics, e.g EMVCo

Katie asks Erik about biometrics in the flow

We could move use cases into the V1 block with your help (volunteers needed)

<Zakim> padler, you wanted to talk about principle of least information in use cases related to identity

Pat: we would want to default to more private transactions

For low value transactions, biometrics aren’t justified

Manu: any modifications to the use cases?

Pat: not, it is more about clarifying the needs

<Ian> [Decomposing -> capabilities]

<evert> +1 to adamm

Adam: rather than consider the use cases as the starting point for standards, I would prefer us to use them as input to requirements discussion. We want to ensure that the various standard primitives are consistent

Ian interjects: the capabilities document is where we are addressing this

<Zakim> evert, you wanted to say that confirmation of a payment does not mean funds are present but that the PSP of the Payer takes up an obligation to the PSP of the Payee

Evert: We need to provide a hook for strong authentication as part of the capabilities and it is then up to the payment services provider as to what they need

Matt Howarter joins the meeting by phone

<jeff> Wendy: we will get to authentication when it is time in the agenda.

<Zakim> Ian, you wanted to ask about biometrics

Nick: we need to cover reversals and refunds and are lacking good use cases

<Ian> (Side note we have 6.4.3 Refunds in the doc -> http://www.w3.org/TR/2015/WD-web-payments-use-cases-20150416/)

<vishshastry> +1 on reversals / refunds / exception management

<Magda> +1 on chargebacks

Arie: we need to address the regulators’ requirements in the primitives and need use cases for that

I am happy to help with that

<Ian> +1 to a regulatory annotation on use cases

Manu: every use case has sections for privacy, security and maybe we should add a regulatory section too

<Ryladog> +1 to adding a Regulatory section to each use case

Manu asks Nick to list which uses cases to add/remove from v1

<Ian> please call on me before Nick confirms

<nick> +1 for hearing from Nick on what should be pulled out

Erik: can we ask for a show of hands around covering biometrics in v1?

<Zakim> Ian, you wanted to ask about process for pruning use cases v1

Ian: one thought was to give ourselves time to consider which use cases to prune

If people really want changes for v1 I encourage you to email Manu on the list.

Erik: Bloomberg regards chargeback etc as part of the business process and not really in scope for W3C to standardise

<jheuer> My proposal: put up a generic AuthN case opposed to addressing biometry and FIDO, and others...

<Magda> *good point Erik*

Manu: is everyone ready to okay the list of v1 use cases as currently shown on the wiki?

<nick> jheuer: I could get behind that

Nick wants to drop a couple of use cases, and others have proposed adding subscriptions

<nick> *throws chair* over privacy

Nick: you could take out invoices, payer privacy, and think we only need one multifactor authentication use case

<padler> 1?

Ian: do we need to change the name from invoice to something much narrower

Manu: yes, it wasn’t supposed to be anymore than the very minimum

<Ian> IJ: Please let's clarify the use cases doc so that we distinguish "invoice-as-a-small-blob-of-data" from "invoice with a bigger meaning like line-item of products purchased"

Manu: can we do a show of hands re use cases

<nick> +1 for one at a time

<adamm> +1 for one at a time

<AdrianHB> We seem to have confusion about the distinction between an "offer" and an "invoice"

<adamm> how is selection of payer instruments 'payer privacy?'

<Ian> (IJ notes that the "detailed requirements work" in this IG will continue after the FTF meeting)

Wendy: we will talk more about authentication tomorrow. This IG has a valuable role to help provide use cases and requirements to W3C work on authentication, e.g. specific biometric or other factor.

<Zakim> wseltzer, you wanted to discuss biometrics

<Ian> (Based on the prioritized use cases and capabilities)

<Zakim> dezell, you wanted to talk about small flows and other standards

David: we worked hard on the segmentation of payment flows as this makes it easier to align with 20022.

<nick> i believe selection of payer instruments = “payer privacy” in the sense the contents of a user’s wallet / available payment instruments is privacy

<Dipan> What happens to use cases not prioritized in version 1 ? Since the timeline to deliver standards is 2-3 years out, does one have to wait that long ?

Manu prepares the ground for the show of hands

Adam: a quick question about the things we’re going to vote on, I am not sure about the question on privacy

<Ian> 6.2.2 Selection of Payment Instruments

<Ian> Payer Privacy

Manu: merchants should not need to ask for which payment instruments the payer has available as that is a privacy issue for payers

Ian clarifies: Perhaps we should change the label to discovery privacy (Katie concurs)

<Ryladog> Suggest changing the name of 'Payer Privacy' to 'Discovery Privacy' for the use case name

Ian: merchants may be willing to offer inducements to payers for personal info

Manu: let’s push that off for now

(we are running over the time for this session)

Manu: who wants to see invoices taken out (11) kept in (9)

<mountie> invoices kept in +1

Manu: who wants to see discovery privacy taken out (2) in (lots)
... password based authentication taken out (8) kept in (10)

<nick> were we going to vote on biometrics / generic authentication?

Manu: is there rough consensus that we keep the rest as described in the wiki?

Dave wonders about support for adding subscription use cases?

<AdrianHB> Are we renaming MISSING USE CASE to encompass generic auth or just passwords?

We will come back to the use cases tomorrow

Manu: does everyone agree with the list in the wiki less the ones now in red?

<dbaron> There are still some items on the list that I don't know what they are

Ian: we have a session on what next for uses on June 18

dbaron: I am unclear how some of the use cases relate to web standards

Ian asks dbaron to write up his questions for discussion tomorow

Pat: if we remove invoices we can’t do push payments

Manu: we can talk about that tomorrow
... is there a rough consensus about the current list less the ones in red (yes from most people in the room)

Browser perspective (Zach Koch)

<wseltzer> Zach's presentation on browser perspective

Zach: I work at Google on the chrome browser

This my take on what payments should look like in the browsere

<m4nu> scribenick: m4nu

Zack: People spend a good bit of time online transacting
... We care about great web experiences, needs to be fast, and secure
... We want to make sure developers can rely on the Web to be successful
... We want to continue being free and open.
... Buying and selling things on the Web is a terrible experience, lots you have to care about as a developer.
... PCI compliance - typing in CVCs, numbers, is difficult
... Shopping card abandonment is pretty bad.
... time spent shopping online is on mobile... >50%
... This is a user pain point - we want to provide a better way - we care.
... Here's an example of a complicated flow - facilitate payment process - good mobile experience. Why can't I just pay w/ my thumb?
... Stripe has a good way of doing this.
... Where the web is like - long way off in UX.
... Chrome launched autofill in 2010
... Helped people complete form fields faster - Firefox also does that now... forms are a painpoint, let's let them do it faster.
... In 2013 - RequestAutocomplete - WHATWG spec around letting browser control experience around credit card input.
... Browser UI handled things like internationalization, optimization for mobile, validation was taken care of... it was not very successful - it didn't get adopted by merchants or other browsers.
... The other interesting thing, in 2013 - MozPay - a much more robust line of thinking from RequestAutocomplete... full scale API for payment instruments.
... it went over to FirefoxOS and doesn't have a strong presence on the Web.
... in 2015, we're back to autofill.
... It's a big pain point for users... we view this as stop-gap measures. It's us trying to make it as least painful as possible. That's why we're interested in this group around Web Payments.
... Some lessons learned - merchants tend to be averse to making changes - you can create a great API, but that doesn't mean merchants will integrate. They tend to have few dev resources - checkout flows are very optimized for things like upsells.
... You have to make a strong case for implementation.
... Merchants are concerned with their bottom line - the question they're going to ask - does this drive more conversions?
... We have to incentivize correctly.
... We can wave a great technology in front of merchants, but hard to get them (merchants) into it.
... For a browser, we want a it to be open, secure, etc.

<vishshastry> another thing merchants are interested in - maximizing conversion

Zack: Browsers sit in a really cool, interesting place. Browser can be a really cool facilitator - great UX - high assurance levels to CnP transactions - stronger notion of person that's buying is who is on the credit card. We are excited about tokenization.
... Browsers can be great facilitators of Web Payments - browser is in a great position to help facilitate that process.
... I don't think we have any desire to be a wallet
... There are a few things that have immediate impact - selection of instruments, can we display payment instruments?
... Authentication/access to instruments - unlock instruments w/ biometrics... tokenizations.
... Two things that are important - subscriptions and biometrics
... Very important on the Web. Merchant integration - If target has a mobile application, you can get same experience on Web as well as brick and mortar.

Srikant: Selection of instruments? Automatic selection? How is that possible when we have multiple devices?

Zack: You would need some kind of sync... I don't think browser should store that.

<Zakim> dezell, you wanted to talk about "why merchants adopt"

dezell: with my w3c hat on, you've hit all the high notes... walled garden approach is problematic. Company X provides a toolkit for your app - that's great, because devs want to get things done quickly.
... It's not that people haven't solved this problem... it's that it hasn't been solved in a way that's truly scalable.
... I'm wearing my NACS (National Association of Convenience Stores) hat right now... merchants want data. When people started giving out oil credit cards, they did that because they could collect information.

Katie: Everybody wants data.

Zack: For in-app purchases - TEE, tokenized transactions - how do we bring that same technology to the Web... if those make sense - can we push that out to Web Apps.

<dezell2> +1 to the need for browser APIs. How to restart the interest?

Laurent: Maybe this is a question for later - how to get interoperability for biometrics or IR level - call wallet directly from browser - what is the right interaction?
... Maybe it's a little too soon for that question?

<Zakim> dsr, you wanted to ask if merchants need inclusion of support for loyalty schemes etc. to justify investment in switching to new standard

Zack: I don't have any clear cut ideas yet - don't know yet, hope to find that out from the group.

dsr: What are the minimal set of primitives that we need?
... Worrying about incentives - if we don't have enough in there - maybe merchants won't switch?

Zack: I think that this is about reducing user friction - does cart abandonment rate decrease when we get some of this stuff in place?
... That's one way
... Another way - can we reduce fraud - merchants spend $3.5B on fraud - liability shifts.
... In EMVCo spec - issuing banks may want to shift liability.

Vish: About liability shift - one of the things you have to think about - it's not merchant, it's issuing bank.
... Part of what has to happen - understanding - there's a broken framework today - it wasn't designed for the Web.

<nicktr> 3DS 2.0 is just gearing up now

Vish: 3D secure was there... it can be fixed w/ EMVCo - banks have different perspectives on how to fix that - banks hand out cards to their customers in India - row/column on paper cards.

<Magda> *what dezell2 said*

Vish: Two things - merchant needs - merchants care about upsell on warranty - or I'm selling a digital good, need it to be fast.
... Folks at Apple Pay, Android Pay have been rapidly eliminating friction points.

<Zakim> AdrianHB, you wanted to ask about selection of instruments

AdrianHB: Wanted to ask other browser vendors - question around integration - what you're talking about is a secure environment - there is a handoff from browser to something else - firm prompts me - which app do you want to use? User experience should follow customers where they want to go.
... It makes sense that browser on phone, I click pay - I get handed off to something else - want to perform the pay action - you have 5 apps that can handle this.
... Is that how the browser vendors see it working?
... The easy way is custom protocol schemes...

Zack: The concern that I have is that you send this out to external apps - so that becomes a bad UX in many cases - that's my primary concern - reasonable approach. I'm open to all of it. Completely possible.

Katie: A couple of things - merchants are not the only people that want your data - more data points you have, the more you can personalize the experience, but it puts organizations in the position of being data protectors.
... With that in mind, come huge responsibilities - 17,000 data points on a user with some folks I'm familiar with.
... I want the experience to be better, but I want to make sure there is informed consent when they're releasing their data. That's a screen that can't go away - since this is W3C, we have to make sure we take that into account.

mountie: From my experience - the Payment Service Provider handles the user experience. In W3C, there isn't consensus when user environment is compromised - maybe this can be out of scope of this group. This is important, payment case
... We have to think about security and privacy in a compromised environment.

Erik: We'll talk about liability shift on security side of things - US Fed is talking about liability shifts on end users... merchants love data, but as soon as data is breached, you are now liable - data needs to be secured end-to-end, otherwise you're liable. Merchants moving over to more secure mechanisms.
... They are attacking the merchants, they're not attacking the payment networks w/ the same level of aggressiveness - they're going to the path of least resistance.

Nick: Merchants value lower rates for payments - that's why there is MCX and CurrentC

Ian: With the meeting goal of what should we be standardizing - in particular because Apple, Mozilla, and Google are new - we want to draw diagram based on what we think we'd like to do - in breakout or in a session - does this architecture make sense?
... To David Baron's earlier point - we'd be interested in talking about those things in more detail. It'll become clearer once we've walked through the charters a bit.
... Would browser folks like to get an up close view on what we've been thinking - ultimately, the goal that browser folks are supportive of ultimate work in this area.

<AdrianHB> +1 for a browser vendor led discussion of proposed patterns

Sam: I'd like to understand what the flow looks like - I don't understand the Web payments flow because it's very abstract.

<Laurent_> +1 on a break out session on flow

Ian: Great, let's do a breakout candidate on there.

<Ryladog> Thank you Manu. Katie's point was also that the confirmation for a transaction screen should never go away for this is in essence a contract - and and accessibility requirements in WCAG 2, 3.3.4 Error Prevention (Legal, Financial, Data): For Web pages that cause legal commitments or financial transactions for the user to occur, that modify or delete user-controllable data in data storage systems, or that submit user test responses, at least one[CUT]

<nicktr> +1 on flow - and to bring 3DS 2.0 into that conversation

Joerg: First, big thanks for the presentation - big opportunities here - pattern around payments and pairing them to loyalty/coupons - agnostic of security and form of communication.
... How to connect to browser to get to right events... Chrome has said they don't want add ons now - on each platform we have different types of solutions - is there a chance for browsers to support interoperability for the same of initiating and authorizing transactions.

<Zakim> padler, you wanted to talk about customer UX and merchant simplification because of ability to use and accept multiple brands of payments..

padler: From browser perspective - notion that payment instruments - sometimes it's local, sometimes it's not - you may have a device that have access to the payment instruments, or you may not.
... How do we represent that in the payment flow? Can browsers make a callout? We have some models - how does it work? We don't want the George Castanza problem (gigantic wallet where you carry everything)

Kristy: When we talk about merchants and incentives - when we solve for it the first time - it'll be something merchants want to adopt. If it solves a peripheral problem, that's not good... it needs to solve core problems. Love the liability shift issue - happy to talk offline about that.

<AdrianHB> Liability is directly linked to risk

Kristy: Solve for the big problem - you don't need to shift liability to do that
... Don't try to come up w/ incentives - get the merchants to the table, solve the problem collectively.

<AdrianHB> Liability sits with the party introducing the most risk

Adam: Having backchannel conversation w/ folks at Mozilla - confused by motivation for single payment interface standard. Google standard hasn't been widely adopted, FirefoxOS isn't something that's been widely adopted.
... Different payer providers have their own toolkit - implement inside of their own interfaces,,, swap out one payment provider for another - it's just something that you can rip out and replace w/ functional equivalent - coupons / promotions - becomes just another payment instrument - nothing special about payment instrument.
... This feels like a solution in search of a problem for me - some see process flow as differentiators.

<Ian> [IJ: These are great points from Adam]

<vishshastry> adamm - not that easy to rip/replace payment gateways. many provide differentiated capabilities (e.g. proprietary tokenization, risk scoring, etc.) - not easy for merchants to switch

Adam: If we come up with a standard, I don't think we'll be able to do something better for their customers - what they find value in, there is a risk of creating a complex standard that doesn't appeal to parties that they have access to.

<Zakim> dezell, you wanted to discuss web+browser what's first

<jeff> [Since queue is closed, I'll try to briefly address Adam's points. As Zach described in his presentation, payments mess is getting worse. We owe it to stakeholders to try to fix it. The fact that previous single vendor efforts failed doesn't mean we shouldn't fix it as an industry.]

dezell: Creating a complex standard is a common theme in our industry - this is the name of the game -
... Vish you mentioned liability shift - liability shift is EMVCo upgrade or merchants are liable - now we're hearing liability shift to merchants, but may not stay there long.
... We're trying to keep our head above water - only other point I wanted to make - degree of protection on two systems is going to be quite different.

Vish: I didn't say payment networks are going to take on liability
... I'm saying that we want a better user experience, providing data to the people that actually need the data.
... The payment network does not know the customer - American Express does, but Visa and MasterCard doesn't - we don't have enough information to make that decision.

dezell: Ok, I misunderstood. Who is coming to dinner (we need a count) be ready to raise your hands.

dbaron: I'm not sure about deferring to OS - some are current, some are very old - we want users across all those OSes to be able to participate in the Web as fully as they can.

<adamm> +1 to david

<Zakim> dbaron, you wanted to comment about ties between browser and OS

<adamm> dbaron explained why firefox has its own CA store, for example

<wseltzer> [lunch: return at 1:30]

<yaso1> scribe: yaso

Card security and the Web model

<wseltzer> presentation on Secure elements

<wseltzer> laurent: replacement cycle usually 2-3 years

<wseltzer> ... no patch mechanism in the field, so what you put in the field stays there

<inserted> scribenick: AdrianHB

laurent: talks through the following presentation: http://www.w3.org/2015/06/secure_elements.pptx

[scribing to resume with Q&A]

<Zakim> manu`, you wanted to get update on authentication WGs from Wendy - any chance that this cross origin vs. same origin TEE could be resolved?

manu: when will we talk about the auth WGs (directed at Wendy)?
... I thought that this work had failed, has something changed that we are still pursuing

laurent: not enough motivating use cases (very restricted)
... Web Payments presents a new compelling use case
... no guarantee that all issues have been solved

wendy: I am on the agenda tomorrow after lunch
... will discuss the pre-charter WGs
... web payments use case are helping to make the case for these WGs

vishshastry: future view Apple and Google are showing ways to leverage secure elements for transactions
... not a stretch to extend to Web
... Apple has tightly bound hardware to the flow
... need to move to a cloud based model (such as HCE)
... Visa is actively working on this credential use case
... will have some APIs out this year

Laurent_: We should leave auth to the account issuer
... the networks define rules for access

vishshastry: I agree with SE tech but it's not great for all use cases

<Zakim> AdrianHB, you wanted to ask if anyone in the room can elaborate on why previous standardisation attempts (eg: Microsoft SmartCard) failed

Laurent_: MS solution was at OS level
... opening to Web had security considerations
... plus the lack of use cases

nick: Android have made a decision to not put a secure element in their devices. How do you propose to deal with this approach?

Laurent_: There are fall-backs from full Se based solution to something like HCE
... choice will be based on the use case and risk

<vishshastry> @nick that's where we think about cloud based authentication. device can authenticate itself to a cloud entity, cloud can provide transactional data (i.e. token + cryptogram) if risk parameters haven't been exceeded.

<vishshastry> +1 Laurent's point about why SEs have been slower to evolve

nick: SE is very restricted why is that

Laurent_: mostly price

mountie: Web sec based on same-origin policy. What is the plan to adapt SE to this model?

Laurent_: SE already has separate apps but we need to now tie these to an origin
... we are defining an interface that would allow an origin to be loaded as part of the SE app meta data

<wseltzer> [we=GlobalPlatform]

Erik_Bloomberg: If we use SEs I want to make the case to use it protect data not just perform auth
... Google ProjectVault is attemting to put SE in microSD so I think they do support SE based solution

<nick> +1 to on-device SEs being preferable to cloud based solutions

jheuer: use of credit card applet on a SE controlled through a wallet app already adheres to the goals of the group

<Ryladog> to say that disposable SD card to hold a secure element is an inteoperable solution for desparate devices/channels/OSs

jheuer: would be wise to draw the lines so that we somehow consider this case
... cloud doesn't solve all cases because we need to still harden the identity. We should make use of this tech because
... it is already out there although we have not in the past been able to open these technologies up
... we need to find ways to make these technologies available to the Web (they are slow and old but still the most secure)
... if we consider IoT we need to solve this problem too proving that a hardware actor is who they claim to be)

Laurent_: Does that make you a volunteer?

<nicktr> +1 for IOT actors

jheuer: Yes, or one of my colleagues

wseltzer: One of the places we hit difficulty is the difference between the security models
... between SEs and the Web
... both are secure
... we need to figure out how SEs fit into the web model
... are they "super-cookies" or similar?

<Zakim> wseltzer, you wanted to discuss security models

wseltzer: look forward to thinking through this

Ryladog: What si the argument against using a hardware SE with a web based payment?

Laurent_: There is no argument against it, I believe it should be one of the use cases
... complexity of deployment means we need to support many solutions

jeff: we have discussed the different security models but we have compromises we must make to bring them together so it occurs to me that solving the most important use cases is a good way to start

Laurent_: Payments is probably the best candidate
... (identity is too broad)

<vishshastry> offline pt 1) can't ensure that devices have SEs - many do not and will not due to cost / complexity

manu: Argument against SE in the critical path is that they are not required for MVP

<adamm> +1

manu: many payments we do today don't have SE attached.
... we need to keep it on the roadmap (and possibly work in parallel) but not put on the critical path
... speak up if you disagree

<vishshastry> offline pt 2) OS (or even browsers) can have deep insight to underlying hardware and there should be a way for consumers to provide informed consent to allow sharing data on their device to authenticate a payment

Laurent_: +1 as long as the credential you use is the payer's problem

<Zakim> manu`, you wanted to make an argument against (playing devil's advocate)

Erik_Bloomberg: Web Payments won't be successful without tackling identity and security

<aylcw3c> Erik - Fin Svcs will not move forward w/o ID and Security

<aylcw3c> +1

<Ryladog> +1 to Erik - security and identity will be essential to web payments

Erik_Bloomberg: those best positioned to solve are the browsers
... they have the distribution

<nicktr> thinks that Erik is absolutely right - we have to solve ID and authentication - but I don't think it has to be a hardware solution

Erik_Bloomberg: for high value or cross-border SE's will def come into scope

jheuer: Online payments are possible without SEs today but the diff between CP and CNP is significant so there is a financial motivator
... we need to give a way for the user to have visibility and choice

mountie: consider using existing local resources like camera to provide some form of hardware security (these are already SOP bound)

Adrian: identity is critical but I would caution against focus on specific implementations (of which SE is only one. Each implementation has different security properties so unless we plan on modelling them all I don't see a way we can focus on implementations

<evert> +1 to Adrian

<Ryladog> 1+ to Adrian

<jheuer> I don't see the necessity to model them all; rather would I expect us to come up with a 'skeleton' for all kinds of implementations to stick to. Otherwise we'd not be open to innovation.

<padler> +1 to authentication context being a piece of information which is applied to payment context..

<evert> See EBA guidelines on the security of internet payments…

Identity/Credentials: What do we need for payments?

<inserted> scribenick: AdrianHB

<Ryladog> Identity/Credentials agenda plan

<vishshastry> bites tongue about inverse relationship between payments complexity and standards 'flexibility' :)

manu: [presenting]
... let's avoid haggling over definitions in this session
... let's asses payments use cases that have credentials impact

1) credential use case - am I over 21 etc?

2) using a credential instead of needing to register

3) being able to negotiate insturments without compormising privacy

4) debit pull

5) credit push

6) proofs

manu: [explains post v1 use cases]
... do we agree that these use cases require credentials?

nick: is registration-less not a "lack of credentials"?

manu: you are giving the merchant data they require (as credentials) instead of needing to register

<dsr> [this is essentially just in time credentials]

nick: clarify that the credential includes any data about the holder (incl postal address)

ari: for FI a credential needs to verified and it is the verifier that gives it credibility
... identity is defined by credentials but they are not the same thing

<wseltzer> dezell: difference between profile attributes and credential

<adamm> +1 +1 +1

<inserted> scribenick: wseltzer

schutzer: majority of transactions don't depend on age verification

<nick> +1 to leaving it out

schutzer: so I'd leave it out of v1

manu: KYC and AML

<adamm> kyc is a us regulation, its not a universal global requirement

adamm +1

manu: pain points
... need more information to lower the risk on high-value transactions
... onboarding
... merchant adoption of new payment services.
... i.e., the sign-on from a merchant to a new payment processor
... account creation
... other industries such as education and health care also have credentialing

adamm: prepaid credit cards or gift cards.
... there's both issuance and revocation
... difference between properties of the person and credentials
... not every country has the same regulatory requirements
... individual privacy rules

<Ryladog> Identity Theft is a Pain Point

adamm: so not all should go into a global standard

Laurent_: there are multiple credentials in a payment transaction
... between multiple sets of parties
... some are out of scope, e.g. merchant-PSP
... take care to specify where we're talking about credentials

Arjun: why would you want to incorporate something this complex? KYC requirements differ by what action you're taking, what org, etc.

<Magda> +1

<adamm> +1

<vishshastry> +1

Arjun: what's the bare minimum you need to complete a transaction on the web?
... I don't think you'll ever have a central ID piece to open a bank account on the web.
... not in the next 10 years.

manu: not talking about a universal ID registry

Arjun: even the defintiion of KYC-enabled is unclear

schutzer: KYC is more involved in opening account, not the payment
... AML is non-uniform, variety of transactions

manu: capabilities, relevant groups, next steps.

dezell: lightning queue

<nick> I can do my piece in 14 words

DJackson: we keep mixing metaphors
... identity to whom.
... KYC is the bank to the next attribute
... a valid instrument may not require a credential
... if I send a verified credential, it shouldn't enable another party to re-use it
... for alternative purposes.
... Present credentials for purpose, not "we need to know"

padler: auth, cred, id, matter depending on your place in the pie. context

<Zakim> AdrianHB, you wanted to suggest that difference between properties and credentials is based on issuer/signer

AdrianHB: my understanding of credentials cg, is way to pass around verified statements
... similar to claims-based authorization
... consumer of the data makes decision whether to trust the verifier

<padler> +10 :)

<DJackson> +1

AdrianHB: extensible. we don't need to talk about what the data is, who the verifier is

nick: agree with Adam.
... this is region-specific. shouldn't be part of standard v1

manu: what about parallel?

nick: so long as it doesn't block the initial standard.

CyrilV: credentials as consistency check
... not a secure element

adamm: another pain point, accessibility to payment systems by underprivileged populations
... let's not make it more difficult for them to participate
... start with easier use cases
... online liquor distributors already have their problems solved
... user of payment instrument and its purchaser don't need to be the same person
... get an attorney who's an expert at international privacy law.

dezell: agree with credential focus on payments, but mention the benefits of a slightly wider use.
... IFSF deems that credentials useful for more than enabling payment
... uptake magnified if satisfies more than one case

mountie: credential is one of the contexts

Richard_Varn: educational perspective, pain point
... mirrors the payments problems

<Srikanth> can we also clarify on how long the credentials are valid once acknowledged and how they can be used for seamless guest experience??

Richard_Varn: we're deconstructing credential, presenting evidence
... from aggregation and collection to analysis, inference, warranty
... overlapping in the way we're trying to work, and the toolset
... credential set for employee
... licensure, test, credentials, bundle to security

<padler> +1 to cumulative evidentiary context (the evidence stack) as part of the payment information...

Richard_Varn: alignment

Eric_Korb: health care area
... I disagree that there are companies who know how to do it already
... we want to improve the credentialing
... and verification along the chain
... we need to know the credential fo the doctor
... we want to move to machine-to-machine
... drug prescribing
... dovetails with payments
... want to clarify: design of credential is privacy-aware
... you're just answering 'does this person have credential?' not sharing personally identifying information (PII)
... primary source providers to issue the credentials

Richard_Varn: security credentials are not the same as all credentials

Erik_Bloomberg: credentials are actual evidence that validates your identity

<aylcw3c> Agree with Erik Anders on the importance of Credentials in creating an Identity

Erik_Bloomberg: critical to moving forward

<aylcw3c> +1

adamm: OPM hack

<vishshastry> +1

<Magda> +1

adamm: let's focus on web payments

<DJackson> +1

<nick> +1

adamm: beware of unintended consequences
... soft identity has risks too
... the metadata problem. you think you're dealing with pseudo-anonymous info, but it's linkable to an individual identity

jeff: I heard ~4 points of view about credentials:

jeff: Will chairs help us find consensus?

dezell2: sensitive to what we don't know

<evert> European Banking Authority: strong authorisation and credentials are mandatory (legislation in progress)

dezell2: add it to a hot topic
... and aim to leave with consensus
... if you want to do it, think aout how to convince your compatriots to move.

manu: if we think credentials is something we'll do
... big if
... then what we need is cryptographic way of proving claims

<jeff> scribenick: jeff

manu: Folks will address KYC
... concerned about portability
... people should control their credentials, when given out
... care deeply about privacy
... certain class of credentials can make it difficult to find out who it is
... user consent for credential sharing
... minimize prob. of theft
... theft is really BAD
... hence hand over minimal information
... e.g. "I am a citizen"; not "here is my passport"
... X.9, Credentials CG are also working
... Open ID connect, SAML 2.0, others
... even more others

Chairs: q about to close

Manu: Next steps
... need a hot topic

Manu: Read up, come prepared
... should we go alone (payments) or align w ed and health care

<wseltzer> [with my privacy hat, I'm concerned about the affordances for "identified web" versus anonymity default]

dbaron: Difference between standardization and research
... I'm not hearing what you are modeling after
... what made them succeed or fail.

Manu: Persona

<adamm> +1

<adamm> persona def is one

Laurent: Desirable capabilities - should also be extensible

<adamm> a big learning experience

<dbaron> and also existing systems are a sign of demand for such a standard

<dbaron> demand for existing systems is ...

Laurent: others regions, schemes should be able to extend

[Ian Jacobs drops off the phone]

<Ian> I'll ask my question by IRC: One goal for this session was to identify payment/ecommerce use cases
...I missed the beginning of the session. But want to know whether some were brought to light here.
...Also to be part of this session was the question: What approaches have been tried previously? Which have succeeded (and why) and which have not (and why)?

Manu: We went through the list of use cases

Manu: no new ones were added

Manu: because we focused instead on "should we do this?"

<Ian> Ok, thank you.
...I think the question of "should we do" depends on "here are the needs"
...And so wanted to hear those articulated.
...So if we do breakout tomorrow, then we should be sure to hear "Needs" from this body

Manu: some comments were based on folks not fulling understanding what we are saying

<Ian> and also experience with technology attempts that have been tried (and if they did not succeed, why not)

Manu: before decisions (in hot topics) people should read up

Richard: You will need to figure out how to consume evidence about credentials
... Best if we do that all together

Web Settlement: Exchanging real value on the Web

<Ryladog> Scribe: Katie Haritos-Shea

<evan_schwartz> Settlement agenda presentation

DE: Introductions for Adrian Hope-Bailie, Evan Schwartz, Stefan Thomas

AHB: Agenda
... these are ideas that we have been throwing around. We are not sure Settlement on the web is a good idea
... differentiate between promises and real value
... what does the reciever of the money thinks
... that is a completely different thing from settlement
... an actual setttlement is a thing that happns behind the scene through some centralized entity
... there is a time delay
... the flow, the setting of obligations and everyone agreeing is different from the actual settement and the actual deposit
...the rules of that clearing system determine
...it talks about discharging
... today settlement is primarily faciliated by a counterparty
... the card goes through the network, done in batch at the end of the day
... money moves in the central bank ledger, sometime the next day.
... 5 party in the 4 corner model
... settlement involves breaking settlement out of that very centralized paradigm
... web and web architecture that is decentalized, can we make this happen?
... to hopefully result in a better experience
... I am giving you three options if you pay me in a way I can get paid sooner

ES: the payer and payee have to have the same instrument
... as long as all have the exact same instrument
... but thatis not how it works today for emai.....we all don't have to have the same email app
... we think setttlement can link these walled gardens
... faster settlement, speed, and cost
... in intl wires are a gigantic expense and pain - if you leave one network
... we want the UX to be great no matter the network
... we want to increase the speeed - this will increase the volume
...a whole new opprtunity
...we want to use the web as settlement rails, using openstandrads
...increase competition, market makers - which is better for users
... Web Payments standards will increase the choice among payment instruments
...settlement is about the links between the instruments ...do we have the same instruments/

<padler> /me feeling like rocky and Ivan Drago... "He's not a machine... He's not a machine.... " :p

scribe: easy, secure, cheap

Visha: Does every market maker have to be @@@

ST: I am not a lawyer, so if they are only working on an exchange they would have to be a broker @@
... It sounds great if we can have payments everywhere
... lets look at the history of the web where you had silos
... open standards allowed the web silos to speak with each other
... three levels you
... how do you make money move on the web the way that information moves on the web?
... not just to make it cheaper and faster
... the difference between HTTP if you duplicate it; will make it worthless
... there is a regulatory challange as well
... how do you feel confident about where the payments is going?
... what do these standards look like?
... our history with ledgers we learned some interesting things
... we need your input

AHB: Here is what we are kicking off - this is an invite for this Web Settlement Community Group - please join as we incubate
... the Task force in the IG exists and will continue as a liaison between the IG and CG
... it is the early days but are excited

MS: The next steps are a CG. Who is going to participate. I am a huge fan and happy that Ripple is so heavily involved. We need other large orgs
... the old fashioned community
... I think you need multiple players from those using ledgers
... getting thise folks involved - or just propose something - and then you will draw folks out of the woodwork to correct you

ST: Bitcoiners - we want more but I do not want to be Bitcoin only - we want to do it the web way

ES: We want to work with Banks and the Fed and others

<Zakim> nick, you wanted to discuss quick question re: session goals

ES: we want to take what FinServ does today and do it on the web'
... Recruiting

<nick> Nick: But we probably need to get the right expertise / org on our part. Will see if anybody is interested in participating on our end.

Cyrl: I think this is very interesting. New settlement. It is part of our discussion. They could leverage the difference between the payment system - based on the card scheme
... solutions will not be exactly the same
... we can't imagine to have payment and settlement to not be interoperable
... we will participate if we can

AHB: These things are linked but different - a bottom up way. What is a new way to do the rails?
... we have to consider the existing system
... we will figure it out along the way

ST: That is one of the advantages of web payments
... one reason our security is so poor is that it was not built on the web

Mountie; There is a mission part for the accouning systems or the settlement - this is important - the entities a traditional shift

scribe: we need some additional channels, Bitcoin, inetrchannel, intercountry

ST: I agree that i why we are spinning off to a CG>

DaveE: I want to modify - since we are an Interest Group - it SEEMS out of scope - but I think that it will end up being quite interesting and relevant.

scribe: we need people who want to work on this to come to the W3C
... The CG is a good way to bring these people on

AHB: I agree with Mountie because he said that Bitcoin can be added even if it fades away - it show that there are options. There are alternative ways
... that is awesome. The CG people let me know if you want to be involved
... we want settlement participants, usually banks to participate

Adam: It talks about Int money keys - from silos to modern payments systems - I am not sure what percentage of web payments happen in that way - usually with my card
... which is a lot less trouble - that is a specific use case.
... what is the problem that this is supposed to solve?

Stefan: You make a payment it seems to go through - the card network goes to the bank and then on to the central banks and it happenes asynchronously

scribe: clearing houses and finally thepayment is settled

scribe: you can see international payment a hundred times slower that today...then you will see larger volume
... Google did this spoof of Youtube you watch TV from your Utube - because the transaction model is too expensive
... we do not have truly fluid payments

Cyril: Be careful when you say that. Settlement or SWIFT is less that 4% of the value chain

ST: At the same time we are able to reduce the costs by 90%

Cyril: SWIFT is connected to all of the banks, part of the value they have invested for many years. It is not up to date - but it is currently connected

Cyril: you are less expensive, if you are not connected

Cyril: Bitcoin kicks you @ss not on the payment system, we do not care
... it is very interesting. Take care with what is the weapon.

David J: there are geographical differences in this

ES: One reason why we want to bring this to W3C. It is not about just creating another network. It is about using web standards for interoperability that people can adopt

<Zakim> manu`, you wanted to mention Primavera's cryptoledgers group. and to say that it's not out of scope

ST: On the web you just have to connect to an ISP - not the ISP

Manu: Primavera Phillipi is trying to bring the Bitcoin group togther on ledgers which is very interesting

ST: Working with Cryptoledger is good but it is not about Bitcoin it is about standardizing how achieve settlement via the web

Manu: second point, this is one of the most exciting future looking things - this is in scope and I hope that it comes sooner rather than later

ES: this is not in the critical path for webpayments, but it is important

Arjun: There is a role that SWIFT has here and that is in the movement of money
... you are not solving the problem of why poeple put money in the bank and not on my phone.

<adamm> +1

<Magda> -1

Arjun: I think this is a nice path buy tying it to web payment standards is maybe not a good idea. Settlement has to happen through a central banks

<adamm> agree its not a technology problem

Stefan: I think we completely agree with that. When you are building standards you are usually not thinking about replacing anything else- but rather improving the landscape

SE: Why do you think Settlemnt has to happen only through a central bank?

<adamm> dont agree that all payments need to traverse central banks, or that it's even desirable

Arjun: Lets say I send am moneygram though Western Union which is very expensive -

<adamm> I fear we are confusing money transfer with web payment

<wseltzer> adamm, I think they acknowledged that this is a distinct subject

ES: Let say you are Well Fargo - lets say you correlate two payments though two ledgers - you can have a settled payment without any money owed without going through a central bank

Add this to HOTTOPICS

Vish: Intrabank settlements between central banks is one of the most complicated transactions- what do you think about that
... once you introduce an inefficiency you may have unintended consequences
... finally I want to hear from the Fed on this....

<adamm> +1

ES: We are not FX dealers - we re trying to bring togther the participants
... I would want the banks to think about the volume story there are decently high margins on some payments

ST: Economists as soon as settlement gets quicker your velocity increases
... there are risk sides to it

David: Be careful not to push too hard

ST: We have been incubating this

Jeff: Interesting, thank you. A CG is good place to take it further. When will it be ready to bring it back? Interoperability, as you develop the concepts
... we would want to see a couple of implementations of ths

ES: Our CTO wants us to implement this

Pat: I think this is important. Central banks are not going away. Many value networks - how do we glue them together? Internationally the payment process becomes very hard
... therefore I think there is a lot of value in exploring ways to do this
... they can be different and still enable the glue between. Not replace those networks but be able to communicate between those networks
... we don't want this to come back in too late
... we can move value more efficiently - we improve the stability of the system - more fluidly exchanged

+1 to Pat

<aylcw3c> Move Value = Move Security = kyc/aml

Eric: I am going to put this in IRC myself. AS you start moving infomation between networks than your security and other requirements go up

<Erik_Bloomberg> Erik: As value transitions from one settlement network to the next so does the KYC, AML, security requirements, privacy, etc.

<Erik_Bloomberg> Erik: Framework must address protection of the data itself. A payment and information networks consists of many components—computers, communication channels, software, and users—each subject to attack and requiring defense. The weakness of each component will vary, and attackers will strike vulnerabilities with the highest expected payoff.

<Erik_Bloomberg> Erik: Engineers who protect these components make judgements about their vulnerability and prioritize each component to determine which weakness to correct. These assessments are difficult, costly, and uncertain, and some weaknesses will likely remain due to undetected vulnerabilities or imprecise assessments (such as underestimates of potential damages).

ES: Security is something we are very nterested in this. Just becasue itis hard doesnt mean we should address it

<Erik_Bloomberg> Erik: Engineers cant protect all the components all the time so we must work on protecting the underlying data. This requires a data protection framework that spans the UI to the very data storage. A proper framework will allow the web/internet to be used as the payment pipes.

<Erik_Bloomberg> Erik: Without such a data protection framework it will be impossible to safely use the web/internet because of the uncertainty of security of each network node a transaction goes through.

Mountie; Less dependency on central bank -,maybe we can xchange the data via the web and use clearing houses

<Erik_Bloomberg> Erik: Without a proper framework the Engineers will protect a handful of weak network links but not all of them. Over time, the set of weak links will change. A mild amount of uncertainty can lead to additional protection of weaker links where expected losses are high and countermeasures are justified. On the other hand, high uncertainty can lead to no protection: the defender may not know which link is weakest and thus leave all links unprotected.

Arie: I think Ripple has a great vision. I echo the Fed. Think this and that - instead of this or that

scribe: the importance of that you are also working on identity at a company level- so they dovetail

ST: the state that we feel we are at is that we feel that more than our company is need to build this

<padler> +1 to the notion of "This AND That"

Glossary

Glossary Fundamentals (Evert Fekkes and Adrian Hope-Bailie)

EF: We have been setting that up where we want to locate the key terminology as a single point of truth
... we came to an alphabetical list of terms

<dbaron> https://www.w3.org/Payments/IG/wiki/Glossary is being projected

EF: I found three terms for credential
... they think credentials aren't reuiqired for payments as of this year
... I do not expect that people are looking at this often
... Four Corner Model
... and extended 4 corner model
... it is correctly linked
... glossary reference which is smaller - this is only terms from the Use cases document
... there is merit in getting competing definitions in place to decide on clear definitions
... formatting exercize
... many different documents
... we have tried automatically linking but we have not yet achieved this
... please let us know about terms that need to be added. We do want it to be as short as possible
... we do NOT want thousands of terms. The want the kernal/nuggets of what is required to execute the payments

<Zakim> jeff, you wanted to ask about 4 corner model and payment ecosystem picture

Jeff: I think it is def of terms but also the fundamental pictures that help us to understand the terms and their relationships

Joerg: I think the glossary will help us come up with a specifc term- and collecting may never end

Joerg: We want to differentiate why we used it this way

Evert: Getting to @@ a two step process

Arie: Interoperabilty when we define it for web payments - we should say that it is at least a derivative

<Zakim> manu`, you wanted to apologize for automatic inclusion of glossary in specs and to agree that glossary should be as small as possible and to speak in favor of relationships to

EF: That is a challenge. It is up to the group to be critical

Manu: I have not yet been able to do the Glossary inclusion work...hopefully somebody can help me finish this off
... I agree that the glossary should be as short as possible
... compact and included in all the documents automatically that will be good.

Cyril: This morning we had a slice of the pie from Pat - the diagram - I think we have to be consistent.
... My suggestion was more to explain it in the context of the payment system. You put all of the actors. Add the flows and responsibilities to the Glossary to understanding

EF: Maybe this could be a breakout

David J: Let get the word 'payment' defined

David E: Tomorrow we start out with Mark. The next topic tomorrow is the breakout sessions. We will have several things to complete there

David: Settlement. What will be time consuming = please come in ready to go. Talk about it tonight. In the afternoon, We want to turmnthe corner after those sessions
... we want to talk about the proposed charters
... Dinner at 6:30 at Dawat


Minutes formatted by David Booth's scribe.perl version 1.140 (CVS log)
$Date: 2015/06/29 15:40:59 $