Web Payments IG F2F, New York

16-18 June 2015

We would like to acknowledge support from the European Commission through funding for the Seventh Framework Programme (FP7/2013-2015) under grant agreement n°611327 – HTML5Apps.

This was the third face to face meeting for the Web Payments Interest Group. We were hosted by Bloomberg.


Meeting Goals

  • Prepare materials to launch standards activities in September 2015:
    • Prioritize payments use cases and the capabilities necessary to fulfill them.
    • Review draft charter(s) and plan for first round of standardization
  • Initiate discussion on other IG activities (to follow push towards launch of standard(s) groups).
  • Solicit feedback from broader community on group’s direction (via the roundtable)

Key Themes for Standardization

  • Security and privacy
  • Identity and credentials
  • Payment ecosystem integration
  • Settlement


  • Notes from meeting planners: Start time 8:30, end time 17:30, lunch 12:30-13:30
  • We will need to manage discussion time very carefully. The agenda has slots for further discussion of tough issues.

16 June

  • 08:00-08:30: Arrival at meeting venue, pick up badge
  • 08:30-08:55: Introductions. (David Ezell)
    • We will have 40 people in the room, so we only have time to say a name and affiliation quickly around the table.
    • Ask for scribe volunteers for after the first session. Please volunteer on IRC
    • Ask people to confirm joining dinner tonight
  • 08:55-09:00: Review of meeting goals and agenda (David Ezell)
    • Reminder of call for consensus around Vision draft
    • Where we have difficulty reaching consensus we should (1) build a list for discussion during the “extra time/breakout” sessions and (2) build list of questions for roundtable participants.
  • 09:00-10:00: Capabilities for Payments (Pat Adler)
  • 10:00-10:30: Break
  • 10:30-11:30: Use case / capability prioritization (Manu Sporny)
  • 11:30-12:30: Browser perspective (Zach Koch)
    • Goal: Improve the IG understanding of how browser vendor(s) perceive of greater integration of payments into the Web browser.
    • Browser perspective presentation
  • 12:30-13:30: Lunch
  • 13:30-14:30: Card security and the Web model (Laurent Castillo)
    • Goal: Shared understanding of requirements for credentials for version 1 payments standardization
    • Input to the discussion: Secure elements presentation
  • 14:30-15:30: Identity/Credentials: What do we need for payments? (Manu Sporny)
    • Goal: Build a shared understanding of 1) requirements to lower cost of regulatory compliance, 2) terminology, and 3) tradeoffs (e.g., simpler approach if some requirements are deprioritized).
    • Credentials Presentation
  • 15:30-16:00: Break
  • 16:00-17:00: Settlement Task Force Proposal (Adrian Hope-Bailie)
    • Goal:
      • Determine whether bridging disparate payment schemes should be part of V1 of payments architecture.
    • Settlement presentation
  • 17:00-17:30: Glossary Fundamentals (Evert Fekkes and Adrian Hope-Bailie)
  • 17:30: Adjourn
    • Please send breakout session ideas for tomorrow to the group list.
  • 18:30: IG Dinner at Dawat

17 June

  • 08:30-08:40: Housekeeping
    • Ask people to confirm joining dinner tonight
    • What will breakout sessions be?
    • Scribes
    • Any agenda changes
  • 08:40-09:30: Lessons learned from ISO 12812 standardization experience (Mark Tiggas)
  • 9:30-10:45: Breakout sessions to discuss hot topics
    • Goal: We are likely to have open issues from the previous day that need additional (but still bounded) discussion. Or, we can have a deep dive on topics (e.g,. what does browser integration look like in practice?)
    • In practice we will sort through candidate topics for 10 minutes, then break for 1 hour.
    • Add breakout session topics here:
      • How does the payment flow work in detail (and where do browsers connect in the flow)?
        • Payment Flow Breakout Session
        • How does 3DS 2.0 into that conversation?
        • What is the real value (to merchants, payment service providers, account providers) of standard API at moment of invoking payment? (Cf. Adam’s points from 16 June)
      • Use cases
      • Credentials
      • Glossary continuation
      • Settlement
  • 10:45-11:15: Break
  • 11:15-11:30: Summaries from breakout groups on hot topics (David Ezell)
  • 11:30-12:30: Security Next Steps (Erik Anderson)
    • Goals
      • In light of of the Capabilities and Roadmap, understand the scope of security work necessary for Web payments, whether done at W3C or elsewhere.
    • Security Next Steps Presentation
  • 12:30-13:30: Lunch
  • 13:30-14:30: Review Roadmap for Standardization (Ian Jacobs)
    • Goal: Generate input on draft charters with an expectation to return to them on 18 June
    • Goal: Wendy Seltzer to review state of authentication Working Group proposals from elsewhere within W3C.
    • Input to the discussion:
      • Draft Roadmap, including links to draft charter(s).
      • Discussion point: Relation of deliverables of these groups to existing groups (HTML WG, Web Apps)
  • 14:30-15:30: More discussion on getting to standards (Ian Jacobs)
  • 15:30-16:00: Break
  • 16:00-17:15: More discussion on getting to standards (Ian Jacobs)
  • 17:15: Demo (Nick Shearer and Samuel Weinig)
  • 17:45: Adjourn
  • 18:30: IG Dinner at Fusha, 1065 1st Avenue (at 58th), 10022

18 June

  • 08:30-08:45: Housekeeping
    • Scribes
    • Seating will be changed at lunch for roundtable (to theater style)
    • Any agenda changes
  • 08:35-9:15: Use Cases Next Steps (Manu Sporny)
    • Goal:
      • Evaluate alignment of W3C use cases with those articulated by other organizations, notably the US Fed and the Gates Foundation
      • Review priority comments we’ve received on the FPWD.
      • Review new use case from CIP on Boleto (5min presentation by Leandro Minniti)
      • Discussion of ongoing management of use cases (notably after v1)
      • Questions from previous days:
        • Is merchant awareness of payer payment instruments a use case we need to consider or drop?
        • What does it mean to take out invoice? Do we still cover vocabulary for offer to start payment?
    • Use Cases Next Steps Presentation
    • https://www.w3.org/Payments/IG/wiki/images/b/ba/James_W3C_Fed_mtg_June2015.pptx
  • 09:15-10:15:  Adoption and Deployment considerations (Manu Sporny and Ian Jacobs)
  • 10:15-11:00: Break
  • 11:00-11:45: Roundtable preparation (Ian Jacobs)
    • Goals: Identify key questions for which we want feedback from roundtable participants.
    • Input to discussion: Submitted questions from roundtable participants
  • 11:45-12:30: One interpretation of charter (Evan Schwartz)
    • Goal: Understanding any remaining big questions or misunderstanding on the charter.j
    • Input: prototype
  • 12:30-13:30: Lunch
  • 13:30-14:30: Final session for important issues and wrap-up (David Ezell)
    • Goals of session
      • Summarize key conclusions and compare with meeting goals.
      • Review and update actions and timetable
    • If we have time: role of the Interest Group after the launch of first Working Groups
      • Optional: Next FTF meeting (during TPAC 2015) and guidance for organizing that meeting
      • Optional: Following FTF meeting (e.g., early 2016). Having met in Europe (Feb 2015), North America (Jun 2015), and Asia (Oct 2015), should we return to Europe in early 2016?
  • 14:30-15:00: Break / Welcome roundtable participants
  • 15:00-17:00: Roundtable moderated discussion
Session Slides
  • 17:00-18:00: Roundtable open discussion
  • 18:00: Adjourn


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

16 June 2015


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

<padlerCapabilities 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


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)

<wseltzerZach’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

<wseltzerpresentation 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

<RyladogIdentity/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:

  • 1.0 requirement
  • Never a requirement
  • Possibly a later requirement
  • No great harm in parallel processing

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_schwartzSettlement 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 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

<dbaronhttps://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

17 June 2015

Lessons learned from ISO 12812 standardization experience

-> Presentation by Mark Tiggas

mark: Work started on 12812 in Nov 2010
… “It was a cold winter day when we started work. The Mississippi River was frozen”
… Our biggest challenge –and likely yours– will be to keep scope to a manageable size.
… our focus was mobile…when we first conceived of this work there was no iPhone.
… the first Wells Fargo mobile banking offering was in 1998…but there was not enough acceptance at the time so we got out of the business.
… smart phones have made all the difference
… what was “in” and “out” continued to be part of the discussion (and continues to be so)
… the UK’s current position is “it’s just another computer”

scribe: our scope included opening accounts, transferring funds (payments), locating ATMs, paying at point of purchase, bill payment, value store
… We organized the work in multi parts…that was a mistake
… Part 1 is general framework
… 2 is security and data protection…probably one of the most mature parts, and also most contentious
… questions about topics like when is a signature required (e.g., not for low-value transactions in favor of speed)

Part 3: financial application lifecycle management

Part 4: mobile p2p

Part 5: mobile payments to business

scribe: note that merchants are absolved from need to know…their banks need to know.
… and so the difference between 4 and 5 is mostly about whether there are financial institutions in the background

slide: where are we now.
… we are at draft standard….ballot end date in July

mark: There will be some “no” votes
… I think that different parts will fare differently (e.g., part 1 is not controversial)
… in some cases, some experts may not be able to convince their (national) communities

[Mark walks through some possible outcomes to the ballot]

mark: ISO standard v Technical Specification (which is reviewed more frequently)
… a technical specification does not have SHOULD or MUST statements

mark: cooperation/competition roadblocks surprised me.
… e.g., problematic to take requirements from smart card forum but didn’t have an IPR regime for doing so
… One challenge that W3C may not have….there are many payments in the ISO space…one of the expectations in the ISO world is to honor and refer to previous ISO standards
… e.g., there are terms defined for cards standards like “proximity payment”
… we had to invent terms that are close to other terms
… e.g., proximate is not proximity payments or contactless payments

scribe: political sensitivity to EMV
… similarly SEP/ISO 20022 terminology dominated the early drafts
… everybody wanted to make sure their prior investments were preserved

[Mark praises DavidE’s group management skills 🙂 ]

scribe: payments baggage weighs on standards process
… invested base and their business relationships
… trust relationships
… some of the trust relationships involve some shady elements and after the Dodd-Frank legislation we had to get out of certain payment activities
… also mobile is moving rapidly; harder to standardize

mark: Now matter how you organize your self…it’s going to be wrong.
… capabilities organized by chunks is clearly the way to go

<Zakim> manu`, you wanted to ask about splitting time between breakouts and to ask about legal implications for technology providers for NOT following ISO12812

manu: If 12812 passes, how does that impact this group? (e.g., language in our specs, topics we should cover or not cover)
… of the technology implementers potentially implementing 12812, what happens if they ignore 12812….lawsuits? annoyance?
… what teeth does the spec have?

mark: much like the w3c, standards internationally vary by country with regard to their weight.
… I don’t see many standards as a good basis for regulation, due to lack of regulators at the table.
… some nations will likely take it more seriously than other….but in the US, for example (like W3C and X9) adoption is voluntary
… in the case of many of our standards in financial services space, they gain their acceptance through outside groups (e.g., consortia of banks) to agree cooperatively to use the same standard.
… the MUSTs and SHALLs in the document are generally around business principles (less so about technology, except in the security space where there is a nod to existing technology)
… it may be hard to determine that one has violated the standard….there are, I note, some statements in the standard around consumer protection (with participation from those stakeholders)
… I would like to say there is more meat in 12812 than there is, but that is the middle path among the different countries

DavidE: Today, in the petrol space there are hundreds of apps … these are provisioned….any thoughts on consumer protection?
… there are clearly some challenges with permissions many apps are asking for…in part because the granularity is not where it needs to be (e.g., file system access gives access to everything)
… we tried to go down a path of doing some more appropriate, but many nations recognized that they did not have control of that space.
… the more important things around things like consumer rights of dispute, e.g., some form of record of a transaction.
… I think that those are important areas.
… but the platforms have the control over some of these areas.
… In the US, EMV continues to be a big deal….people are looking at alternatives (e.g., to mobile payments)
… do you have insights into opportunities there?

mark: There was a bit of contention, especially early on….mobile devices have added an interesting dynamic to the process…
… one reason US was slow to adopt is that the average lifetime of a point of sale device is 10 years.
… now there is a push for updates (and liability is shifting to those that do not upgrade)
… in various jurisdictions change happened either due to liability shift or regulation

<evert> In Holland we convinced merchants to migrate by demonstrating lower cost of EFT to cash…

mark: …in the US our fraud losses were relatively lower, and so there was less of an incentive to change
… People change their mobile phones more frequently

nick_s: How does defining a standard help you differentiate your offering?

mark: Wells Fargo (or any other bank) will leverage what it finds useful.
… that decision will be a business decision.

claudia_s: I participate in X9. It’s also fair to say that standards can be infrastructure and there’s a lot of opportunity to differentiate on top of a standard.
… eg., there are checking services and lots of differentiation in checking services

DanSchutzer: We did a study with the Clearing House (when I was at FSTC)
… around that time, P2P was big on mobile
… there was a consensus based on that
… Clear Exchange came out of that study
… the bottom line is that the cooperation was necessary to get critical mass to achieve your objectives as a company
… you want to grow the market so that customers flock in the direction of the standard

padler: what would motivate Wells Fargo (or another company) to adopt the standard?

mark: one of the reasons that part 6 fell on hard soil is that not people saw a lot of value in a mobile application
… except perhaps for provisioning and deprovisioning
… but the area where there was the most cooperation was around payments since I can’t do payments by myself
… I really need to be able to accept a credit card payment from a customer of another bank
… payments has always been one of those areas where people recognize that to transfer money you need cooperation among multiple parties

DavidE: What is people’s biggest concern around the standard?

Mark: Disruption of existing infrastructure
… no compelling business need to change to get the same capability with new programming….
… adding cost in the short term is a challenge, and a big reason why there is little uptake of new payment systems

Revisiting Credentails Briefly

<evert> EBA document: http://www.eba.europa.eu/regulation-and-policy/consumer-protection-and-financial-innovation/guidelines-on-the-security-of-internet-payments

<evert> Strong customer authentication is, for the purpose of these guidelines, a procedure based on the use of two or more of the following elements – categorised as knowledge, ownership and inherence: i) something only the user knows, e.g. static password, code, personal identification number; ii) something only the user possesses, e.g. token, smart card, mobile phone; iii) something the user is, e.g. biometric characteristic, such as a fingerprint. In addition, the

<evert> elements selected must be mutually independent, i.e. the breach of one does not compromise the other(s). At least one of the elements should be non-reusable and non-replicable (except for inherence), and not capable of being surreptitiously stolen via the internet. The strong authentication procedure should be designed in such a way as to protect the confidentiality of the authentication data.

evert: Every financial institution is a PSP.
… it does not imply a particular technology
… in PSD2 if you do not implement strong authentication as a financial institution, you are liable

<evert> Credentials mean the information — generally confidential — provided by a customer or PSP for the purposes of authentication. Credentials can also mean the possession of a physical tool containing the information (e.g. one-time-password generator, smart card), or something the user memorises or represents (such as biometric characteristics).

Adam: little interest in credentials

Nick: Similar view from Apple….I see financial institutions have a strong interest
… browser vendors have to support globally…but markets will differ globally

<nick_s> (NB: I don’t speak for WebKit, but I expect the position to be similar)

IJ: I am hearing no credentials for v1. But what about v2? What might be different then?

Nick: Need more international payments people in the room

Adam: Also, credential and authentication standards have been used and abandoned because of flaws
… it’s a rapidly evolving space…the more tightly we define the more headaches there will be
… these are driven by business requirements…there are standards at the application layer, not built into browser.
… web payments are hard
… mobile payments are hard…there is value we can add

DavidE: I propose for the breakouts..it sounds like flow is really important
… my concrete suggestion is that we do flows in breakout
… and we take use cases and other topics to a separate space

<Magda> +1 on David’s proposal

<adamm> +1

Ryadog: We have a long ways to go on credentials before we get there…what we want in terms of browser vendor involvement is enablement.
… we want to enable what’s necessary

dbaron: Following up on the credentials topic: part of the browser view is what pieces are being used today and the question is what can we move into payments to improve payments.
… it’s at least not clear to me why or how credentials work can be improved by the browser knowing things about it
… maybe that’s a useful coffebreak conversation

<Zakim> manu`, you wanted to mention that the ask is not a browser vendor ask – it’s a format and protocol ask from W3C.

<adamm> +1 david

manu`: I feel like we are miscommunicating….nobody has said browsers have to build anything into the core of the browser

scribe: my concern is that we table credentials entirely based on this misunderstanding
… there is a set of people in the room for whom this is important; it does not have to flow through the browser / native APIs

vishshastry: From a financial institution perspective, there’s a recognition between what a merchant wants (get person through checkout rapidly) and bank need for strong authentication
… seeking this balance has led to complexities in the ecosystem
… it would be great if this group could evolve technology in that area.
… one area would be provisioning of data from a browser or device all the way to a bank
… giving greater confidence in the device where a request for a transaction started
… at a given point of time
… doing something like that might be a better way to manage the credentials issue
… I’m sensitive to the privacy issues
… but there has to be a balance between device as proxy for easing financial transactions

wseltzer: [Wendy introduces herself]
… I get to take back recommendations back to W3C for new work to charter as W3C WGs
… we also know that there are other types of groups like IGs and CGs
… one of my goals for this meeting is to come out hearing specific needs that go into rec track work for charters as well as where else should we keep our ears open for that work in the future
… there can be lots of productive work that happens outside chartered working groups
… that’s a plea for thinking about where each of our items is phased…what needs to go into a web-wide standard and has the interest from all the people who would be needed to make such a standard work
… and which pieces are fodder for discussion or can be made a useful standard by a smaller subset of participants
… who can go and create it in a smaller space
… I hear one stream of payment architecture work
… I will speak later about several streams of security and authentication work (from here and outside)
… I hear another stream on credential work
… each stream has a different set of people interested
… breakouts could be a place where different clusters group and help us work through levels of interest and who is interested

erik: Bloomberg has its foot in both doors (both tech and financial services)
… I agree that many times the work does not belong in the browser
… is there a difference between web standard and browser standard?
… I think we should table credentials until we have a better understanding of what the needs are

<Zakim> nicktr, you wanted to say that given how much discussion of credentials we’ve just had, we should include it as a breakout if only to continue this argument

nick: -1 to breakout on credentials; we just had it

padler: I think that Mark said earlier that there is a big difference between how the credential data is created, and how important it is to pass the data within the ecosystem
… I’d argue for the payment flow discussion …what information needs to be passed (in US, PSD2, etc.)
… we need clarity on what information is passed so we can do payments…and then we can talk about standards necessary to fulfill those needs
… and stakeholders may differ depending on the device, etc.
… if we standardize on the payments stuff first before understanding how the information is passed will lead to problems
… so maybe let’s focus on message passing first

<adamm> adding comments to log:

<adamm> credential flow: issuance, revocation hardware identification: in a client/server connection, it’s hard to trust the client. based on what? hardware ids can be spoofed. even a tpm is a rabbit hole: how much do you trust the tpm chip issuer which is essentially a CA? What happens when someone at pwn2own breaks the chip implementation in everyones device? how do you know the presenter of the credential is the owner?

<nicktr> identity and the flow of payment credentials are fundamentals of payments on the web. if we don’t progress these we aren’t moving anything forward


At this point we have two breakouts: one on payment flow and the browser, and one on use cases. The minutes below are about the former; we reviewed the findings of the use cases breakout later in the day.

Payment Flow in relation the Browser

<dsr> scribenick: dsr

Pat: let’s start with discussing what people here want to ask?

Nick: I want to understand payment flows and how they differ

Pat recaps how the payment flow discussion evolved withing the IG.

Pat: everyone agrees that we want to narrow the scope. We ended up looking at what information exchange is needed at particular parts of the flow and how we could improve on today’s practices.

Pat presents a payment flow diagram (URL to follow)

He talks through the various entities used in diagram (shown on rhs)

A user on a merchant’s website, putting something into the shopping cart.

The website prepares the information needed to initiate a payment request.

Payers could push payments or respond to a pull request from the merchant for payment.

Ian describes the idea of a minimal set of information needed for a payment request.

Dan: what would be the benefits of standardising this?

Pat: you wouldn’t have to provide your credit card info to the payee

We’re looking at a standard web request

It’s a communication request

Ian: it is supposed to be abstract at this point

Mountie: the IETF has some proposals about the information needed

Pat: it includes information necessary to fulfil the payment to the payer.

<mountieECML v1.1 (Electronic Commerce Markup Language) from IETF

Dan: typically the merchant has a back end connected to a payment processor. The merchant wants confirmation that the customer has agreed to make the payment.

<mountie> another example with banking and push payment.

Sam: the diagram as presented could work with both push and pull payments.

Dan: there would be a risk if the merchant discloses their account details

Pat: this too can be tokenised

<mountiePush Payment with banking service example

Sam: establishing the identity of the actors in a payment transaction is essential and this involves credentials

Dan: the merchant can provide a token that payment service providers can utilise

Ian: The merchant provides information on how it can be paid. The customer chooses how to pay. The customer involves a payement service to pay the merchant. The merchant gets a proof of payment. The merchant provides the customer with a receipt.

Pat provides further details of what happens in the background, and how the approach also supports push payments.

Dan explains how today’s wallet solutions work. The wallets have not taken off as the approach is rather cumbersome.

Vish: the approach presented isn’t how things work today

Pat: we started the diagrams to capture how existing systems work today.

We wanted a standard way to talk about things consistently across models

Vish: maybe push and pull are a little simplistic, but once merchants have settled on an approach, the cost incurred in setting this up creates a barrier to further change

Dan: indeed

Pat: one aspect of web payments is …

Joerg: we wanted to abstract from the details of how payments are processed and to instead think about what information needs to be exchanged

We should not interfere with how processing is actually done, as we want to leave that space free for innovation.

People here are very involved with the details of payment processing, but that is not what we need to deal with this here

The customer needs to understand what choice of payment instrument to use for this transaction.,

Mountie: we should add more context

Pat: we’re trying to step away for specific use cases and to instead identify the information that is minimally needed for a push or pull payment to be completed

Srikanth: how do you ensure that the payment authorisation only applies to this merchant?

Pat: this diagram abstracts away from the additional information relating to the transaction, e.g. terms and conditions on the sale of some goods.

Some flows may have strong requirements in respect to KYC/AML, others may not

Dan: the customer needs to know what he has to pay, and has to provide his confirmation of agreement to pay.

Pat shows another flow diagram

Dan: so you don’t need to cover routing numbers etc.,

Pat: right

Sam: there are existing players with a huge volume of payments, and there are problems with data breaches and liability

Ian: we want to model existing payment frameworks and not to replace them

Pat: to focus on the consumer, why do you have to use so many different payment techniques for all the companies you have to deal with

What can we standardise at a level of abstraction that overlays existing payment solutions?

Ian: the W3C work started with the question: what can we do to simplify the job of a web developer and giving end users maximum freedom for how they choose to pay

we want to lower the cost for developers and to enable an improved end user experience

Ian: I get that autofill of forms is an improvement for the UX, but what are the other pain points?

Dan: users have to authenticate themselves to their payment processor

Today, if users register with a merchant, the merchant can simplify the payment UX

The pain point is that merchants then have to store sensitive info at risk of breaches

Cyril: where is the step for authentication take place?

Pat: how do you the authenticate the device, how do you authenticate that the person with the device is the right person, and so forth

We get into the regular confusion over different ways that different players have used the term wallet.

Pat: we just need entities that fulfill the role of payment agents, we don’t care how they work, just so long as the info passed to the agent is standardised.

Mountie: we could move the wallet to the browser (?)

… talks about vending machines in China …

Pat: there could be a trust agent that facilitates things

Trust agents and payment agents could evolve in parallel

<nicktr> +1 that payment agent need not be the provider of identity – simply the container for payment credentials

Mark: conceptually the abstract flow makes sense, today everything is based on credit/debit cards and the model is heavily loaded on the merchant, you’re also seem to be requiring continuous connectivity.

<nicktr> but some level of ID is a precursor to the negotiation of the payment instruments

Mark: invoice is a very loaded term, and usually represents a commercial agreement, and I recommend you avoid using it for the sense you need

<mountie> token can be used instead of invoice. “requestToken”

Sam: I understand that the IG will set up WGs, including a payments WG. Is the goal of these diagrams to describe the scope of that WG?

Ian: the IG indeed serves to recommend what WGs are needed, We will go into the details this afternoon.

Sam: do we have a diagram that covers what the WG will enable for payment flows?

<mountie> UML Sequence Diagram is better

Pat encourages people to create diagrams covering their specific payment flows

Sam: I would be happy to go through Apple’s basic payment flow, and we like to talk about crypto and how trust is facilitated

… that has been missing from the current discussion in this session

<mountie> trust relationship between contexts can be established via PKI (in some countries) or blockchain network

Ian: I think we all want to do what you want, and need your help

Ian runs through the stakeholders in the IG

Sam: I don’t think the idea of having multiple wallets is a good idea

Ian: this is in part a terminology problem

Pat: we need to standardise the interface that avoids the need to have multiple wallets.

Joerg: I agree very much with Sam’s point

Katie: we have to support what’s there

<mountieBanking example

Joerg: the flow diagrams were intended to be neutral

I want to make it clear to the end user what information is being passed.

Vish: the use cases makes it appear that you’re trying to boil the ocean, and you want be better off clarifying the pain points that you are aiming to address

Users should be free to choose which browser that they use on any device

Sam: you shouldn’t standardise the means to support multiple wallets.

DavidJ: I strenously disagree with Sam about “only crazy people carry multiple wallets”

Different payment instruments may have different requirements in respect to biometrics and so forth. We need to enable that not close it down

Adam: we should be addressing threat models for the payment flows

Pat: yes, that is valuable.

<Srikanth> Just in time payments and Returns are couple of things which are missing in the payment flows

Adam: ultimately it is very hard to trust devices

An operator cannot always be sure of the owner of a device

Joerg: trust is based upon establishing relationships through certain means

Ian: I will attempt to summarise for the session. I want to thank everyone for their input.

1. what standards that we need – what will simplify life for merchants and likewise for browsers

2. don’t use the word invoice as it is causing confusion to some

3. we need to understand the payment flows and please help us to realise this and to help with threat models

Ian wraps up the session.

Summary of Use Cases Breakout

DaveR asks people from the breakouts to post summaries into the minutes

Credentials are out for V1 of web payment standard. Registration-less purchases are in for V1.

Multifactor authentication should be in scope for V1.

<Ian> Nick: “Electronic confirmation” rather than “receipt”

Receipts are in for V1 for delivery of physical goods, and for ….

<padler> receipt as payment confirmation is similar to the feedback on invoices…

<wseltzerUse Cases Breakout wiki

Retail industry will depend support for refunds/reversals

<padler> also… sounds like it might be interesting to talk about standard payment message codes… (Payment received, Payment Acknowledged, Payment declined, Payment Authorized, etc… ) it would be good to have a standard vocabulary for these…

DavidE: we will take up the glossary discussion on email

Evert: CRUD means create, read, update, delete

There are some diagrams for the capabilities doc

some comments on formatting the glossary doc


Security Next Steps

Erik Anderson presentation on security and  wiki to help prepare this agenda item

<dbaron> ScribeNick: nicktr

<Ian>[Erik introduces guests for the security session Ron Parsons and Ed Schmidt from TecSec]

Erik: directs us to the capabilities doc

Erik: review of capabilities
… Identity, privacy and consumer protection – privacy clearly super important
… must be able to bind web and real-world identities
… Some regulatory env’ts require notification of users where their PID is accessed
… only minimal info should be disclosed
… Payment account providers should ensure that account identifiers should not be sufficient to reach “real world ID”

Ian: Can you help us understand what needs are being highlighted?

Erik: We haven’t done a lot of work on this space yet. I’m telling the story from the perspective of the capabilities document
… some access is timelimited
… Role-based access may be required from a regulatory perspective
… Highlights from Fed Reserve Secure Payments Taskforce inaugural meeting
… 1. Controlling security risk and containment
… 2. Reducing fraud
… 3. Data breaches
… 4. Limiting access
… 5. High risk of emerging payment mechanisms
… 6. Privacy
… 7. Fraud alerts
… 8. No mention of digital signatures
… 9. Tokenisation is overused
… Key takeaways
… Counterfeiting of payment instruments is becoming nearly impossible

<Ian> Erik: Key theft a bigger problem than counterfeit

Erik: Theft of ID and credentials are the key enabler
… ID theft is increasing rapidly (25-50% pa)
… Credentials have long lifetime and therefore higher risk
… Current standards secure the network – but each node is also vulnerable
… If you use public networks, you need to secure each node
… So the only solution is E2E security
… Consumers don’t use corrective financial protection mechanisms
… Fraudsters move to identity fraud as instrument security improves
… National concerns should align with international standards
… Keep costs low –
… The right security framework will allow internat based commerce to attain low transaction costs
… Framework must cover each components
… Existing standards
… ISO 20022 – no built-in security
… ISO 12812 – PArt 2 has many relevant compnents
… X9.69, .73, 119pt2, 122 all relevant – but 119pt2 only static tokenisation
… All this documentation should be available to all WPIG members via Bloomberg Impossible Mission doc server

Erik. these docs will self-destruct in 10…9…8…

Erik: Diagram (slide #9) – RHS indicates each institution tailors their own risk/cost profile
… Split your id into fragments which allows you to administer your own security/data
… What occurs on LHS is API for secure transactions
… Application developers shouldn’t be exposed to crypto
… Financial Institutions do the hard work
… Software and hardware implementations both required
… TecSec are open sourcing CKM
… Provides a working example of how dynamic keys are generated

Ian: Purview of this group is the very topmost sliver
… what do WPIG need to do?

Erik: Yes – on the last slide

<mountie> what does it mean CKM?

Erik: Each key unique for each transaction – so breach horizon is 1 transaction
… Slide 13: Pseudo random ID bound to a specific institution
… Biometrics shouldn’t be used directly
… Geolocation allows ID binding to location
… Time-based access also possible
… Token is bound only for a single transaction
… Legal/regulatory: ID is global but permissions local
… Onion model shows security layers on layers
… This stuff was built in the nineties
… what do we do next? Short-term – protect data everywhere. Mid-term: Poretect e-cash letters and improve card authorisation. Long term:
… Standardise security protocols
… Minimise the standards
… Proprietary standards don’t work internationally
… Align liability to the party best-suited to prevent fraud
… FIs and merchants must accept consequence of fraud/sec failure – but this is misaligned to those who can fill the gaps
… For internet, put liability on users and merchants (so there is a motivation for users and merchants to select secure solutions)
… The browser has international penetration – very few other solutions do
… All the tools are there and have been around since the 90s
… Fraudsters are after static keys – short-term goal must be to protect the info

<Zakim> manu`, you wanted to be confused about next steps.

Manu: Lot to take in. Can we see 5 bullets to help us focus?
… I don’t know what the next steps are?
… Are there suggestions?

<Zakim> Laurent_, you wanted to ask about scope

Laurent: So for me, there is one bullet – what is the scope of the security task force?
… Securing web payments is solving the security squared

<Zakim> dezell, you wanted to ask for clarification about X9.119-2

Laurent: I think we should only focus on securing the interactions between the actors. Question for the group – what is our scope?

Dezell: We can take questions about x9.119-2 offline

Wendy: <look of puzzlement>

Max (Bloomberg guest): Which info is going in and define an encryption scheme

Max: Don’t use proprietary tech
… These go obsolete – everything can change
… Don’t mandate specific schemes. be agile.

Wendy: We have a web crypto WG which has built an API to give standardised access to crypto from the browser
… We are totally into the mantra “build on standards”

Srikanth: In the long-term we still putting the liability on the merchant
… All the merchants are getting is an acknowledgement – why should merchants be liable

<Ian> [especially in the long-term]

Erik: It’s all about aligning incentives

<Zakim> manu`, you wanted to mention a list of security needs that I think should be in scope.

Erik: It takes too much time for people to change

Manu: I want us to focus on message format and digital signature/encryption

Erik: I don’t agree that signatures are required and it does not solve non-repudiation

Pat: Sigs and encryption are needed – it’s not binary. Compound sigs also needed

Jake?: Digital sigs carry baggage back to CA

Jake: Better to describe them as electronic signatures

Manu: How do we encrypt the message channel – do we need more than SSl?
… authorisation and authentication
… tokenisation

Manu – this will suss out the technologies that we require

Adam: The liabilities are already well-defined. All of PCI is administered through chain of contract

Ron: Tecsec bringing new tech to the table
… Finegrained access, signed, all flexed re risk and cost

Ron: We are offering a connector that allows browser to generate the headers
… http, https, httpv (which avoid MITM attack)
… Take those pieces and make a security connector in the browser

@@@ Connectors that are not in the PCI domain like ACH

aylcwrc: the idea is to make a secure matrix so that everyone can operate and we can all dance like leaves on the wind

Max: developers should not have access to crypto APIs – should be abstracted
… Keep it simple. Minimise the number of keys
… Everyone screws up (“To Err is Human”)

Jeff: We wanted to abstract the underlying h/w
… I like Max’s idea of taking it to the next level

<AdrianHB> +1 to sticking to payments and not trying to solve security and crypto that is the domain of the payment scheme

<Ryadog> Web Payment API

Jeff: Is on the table with IP commitments?

Ron: Zero dollars/pounds/yen/BTC

Erik: One note: by putting security in an accessible manner including browser – secondary effect on other things (JLaw’s photos no longer available)
… This is not just for payments. It is for all of identity.
… Tecsec solution is 150 algorithms. Institutions can pick and choose.

Group breaks for lunch.

<screen> – Define the information to protect

<screen> – Define the message format

<screen> – Define the lifetime of the data

<screen> – Use electronic signature not digital signature

<screen> – Tokenization mechanism

Review Roadmap for Standardization

<dezellIan shows the draft roadmap and draft payments architecture wg charter

<dezell> Ian: we want all of you to share your ideas on what should be standardized.

<dezell> Scope is minimum viable payment flow between payer and payee

<dezell> Ian: is this modest enough for scope, or can it be even smaller?

<dezell> Ian: a few other things – descriptions (a la vocabulary), alternate payment schemes, registry/discovery.

<dezell> Ian: ancillary features include RESTful APIs – proof of payment, invoice processing.

<dezell> Ian: we’re looking for feedback.

<dezell> Evan: another input, just mailed a proposal for things in/out of scope for this proposed WG.

<dezell> …: features or limitations of payment instruments are not really in W3C area.

<dezell> …: some concrete examples: can we make “filling out forms” less annoying?

<dezell> …: for another group, too many parties need to store information about a payer, and it needs to be solved.

<dezell> Evan: to clarify, many things we talk about are really problems with payment instruments.

<Ian> evan: place for interop is in how people provide data

<dezell> …: I would argue that the relationship of a user to a payment instrument should not be standardized.

<dezell> Ian: what about the payment initiation with information blob (like invoice) to kick it off?

<dezell> Evan: would include what payment instrument(s) and amount.

<dezell> Evan: authentication, tokenization, active fraud prevention, and proof of purchase – all these are things that should be out of scope.

<Zakim> manu`, you wanted to mention that “vocabulary” doesn’t mean “glossary”

<Laurent_> +1 to evan

<dezell> manu: “vocabularies” are machine readable, not glossary.

<dezell> nick_s: receipts are mentioned several times in various places. Are people really wanting to tackle this requirement for track 1? It’s quite variable between countries.

<nick_s> +1 for adrian’s recommendation

<dezell> adrian: this predates the breakout on use cases, I would suggest we change “receipt” to “confirmation of payment” that would work better.

<dezell> nick_s: would be OK with that.

<dezell> adrian: output from breakout was “Optional link to receipt.”

<dezell> Ian: so there are two things – initial proof of funds, and completion of transaction.

<dezell> Srikanth: we care about advance transactions and the finalization also.

<dezell> …: the authorization (of funds) might be all we have for several days.

<nick_s> +1 again for adrian. It’s payment scheme specific.

<adamm> +1

<dezell> adrian: we shouldn’t be trying to standardize the really large flows, and the individual local rules should be handled separately.

<dezell> dsr: there are concerns like this trying to formulate a global receipt. But people want a standard way to collect receipts.

<dezell> nick_s: we’re all very interested in receipt formats. It’s great that they could be used interchangeably for different purposes, but not for v1.

<Ian> Ian hearing:

<Ian> * support for confirmation of payment to both payer and payee

<Ian> * receipt format is not for v1

<dezell> adam: so people really just use credit cards and billing records. The receipt structure etc. is not important.

<dezell> important list: *identity of merchant, *amount paid, *date

<dezell> evan: I’ll argue that we don’t need a payment confirmation to be part of the standard. It’s part of the payment instrument integration.

<dezell> Dan: agreed, but with one caveat – I think the items are useful to an end user.

<dezell> evan: I’ll disagree, but I don’t see the problem that it’s solving.

<dezell> adrian: I think we have something simpler in mind – verification of payment.

<dezell> Srikanth: when we have one identification of that transaction, how is the receipt going to look at various points in the transaction?

<dezell> …: what is the “identification” flow?

<wseltzer> ian: note the transition from merchant-side processing

<dezell> …: how is the transition from “merchant side” to provider characterized?

<dezell> joerg: there is use in having a symetrical “start transaction” data and “end transaction” data.

<Ian> dipan: you do need ack of protocol completing

<Ian> …but invoice more broadly is complex, too much here

<dezell> Dipan: I concur with Joerg. Receipts are very complex and I don’t know that we have the right players in the room. Actional digital receipts are quite complex with international implications. Not to mention coupons, loyalty point use, one receipt, multiple receipts, etc.

<nick_s> +1 dipan

<dezell> …: retailers and POS integrators are the people needed for this discussion.

<Ian> dipan: provide a hook!

<dezell> Claudia: are we closing on the definition we had this morning with a proof of purchase.

<dezell> …: I’m not sure I agree that it’s done by the payment scheme.

<dezell> adam: with added complexity comes added risk. For every new data element, there should be a rationale for each.

<dezell> …: I have many receipts that I don’t really need – they add clutter.

<dezell> …: it might be good to have a receipt format.

<dezell> …: but it’s a whole lot of rabbit holes.

<Dipan_> +1 for Adams Law

<dezell> zach: it seems that payment doesn’t originate with the merchant, even though that is the main way it is done today.

<wseltzer> zkoch: make sure architecture supports current processes

<dezell> pat: I think the architecture >does< support it, but new group members should look and way in.

<dezell> manu: we made it clear that both merchant and customer initiated payments are in scope.

<dezell> …:(via use cases)

<dezell> pat: goals of the architecture are to support both.

confirmation of transaction message must cover payer and payee initiated payments

<dezell> pat: what is the “minimum viable receipt?”

in fact, all of the messages/components need to work for both initiation sources

<dezell> Note: charter must cover both merchant an payer initiated payments.

<dezell> Srikanth: we need to clarify the “receipt” vs. “payment confirmation” terminology.

<dezell> …: regardless of which, there will be multiple players involved in any transaction.

<dezell> …: and there may be varying security constraints.

<dezell> evan: my objection with payment confirmation. Personally, I’d love a cryptographically signed receipt from the payment instrument.

<Ian> IJ to srikanth: please write down the detailed intervention of various parties in the payment flow you described

<dezell> …: I’m concerned that this kind of change is far reaching from somebody to have to conform to. We’d have to get VISA, MC, and everybody to provide a cryptographically signed receipt.

<adamm> +1

<wseltzer> evan: I personally would love to have cryptographically signed reciepts from credit cards, but I don’t have Visa’s public key

<dezell> adam: post/redirect/get pattern is an appropriate place for a yes/no response in the context of application logic, that doesn’t require a complex response.

<dezell> …: but defining any kind of response limits the usefulness.

<dezell> …: where does the confirmation happen?

<dezell> ========

<dezell> jeff: I have a comment not related to receipts.

<dezell> (next)

<Zakim> wseltzer, you wanted to ask “shall we talk authentication?”

<dezell> wendy: Technology and society domain is where we might start this work.

<dezell> …: we also have interest in next steps in secure authentication.

<mountie> +1 for payment confirmation. receipt need the purchased product and payment result. too complex.

<Ian> scribenick: Ian

wseltzer: Two groups in discussion
… first is FIDO-based
… we are discussing collaboration with FIDO where they could bring specs to w3c (as input) and work through our usual process.
… that’s for multi-factor authentication and device enrollment
… and device capbilities.
… the other group in discussion is hardware based security: secure elements, TEE, smart cards, SIM cards
… where we want to leverage those capabilities for the Web, through defined APIs
… and make sure those fit within the web security model
… what capabilities can we build an abstraction layer for that would benefit the web
… discussions from Global Platform, Gemalto and others involved in smart cards
… both of these group charters are at the “preview” stage….only earliest phases of development
… we want to hear input, requirements, and statements of interest in the work
… to ensure that we are scoping it properly, especially for those requirements from the Web Payments IG
… what is needed? how do they compose?

<adamm> adding to my prev comment: for a web service, the payment acknowledgement would be in the http response to the rest call. the message could similarly be true/false or complex.

cyril: do we need secure element work via the browser? It’s not the same thing browser v. hardware

cyrl: We have payment service providers connected to the merchant that are doing pull/push payments
… if the PSP is connecting tot he merchant, there’s no issue between pull/push
… even if we think on the merchant side there is only pull, that’s not the case, on the merchant side there can be both as well

wseltzer: On the role of secure element…we are looking at that as a services question – what services does the web want from hardware?

<mountie> with push payment, we can invite more payment participants.

wseltzer: if one desired service is “secure storage” what does the API look like? Are there limits on use? Is it origin-bound?
… so hearing the use cases (and what the desired services look like) help us scope a charter and work to build it to meet the web need.
… Meanwhile, web crypto WG finishing webcrypto API
… the webappsec WG is doing CORS, CSP, and other elements of support for web application security
… the TAG is also interested in security, as is the Web Security Interest Group (which looks at more broadly scoped questions)

jheuer: We should distinguish the “use” and “provisioning” stages
… e.g., we have implementation of a ticketing system….they can provide tickets via NFC
… the tickets sit in the secure element
… I can imagine communications channels to provision (or pre-provision) the hardware
… eg., to verify a ticket on the web
… I think good to distinguish provisioning and how you “use” the information that is stored.

wseltzer: We’d like groups to be moving by the fall.

manu: We don’t have anything in the critical path for V1 re: authentication
… or do we?

padler: I think that a question is, for the message flows, that we will need a way to share info about the entities involved in V1 in a payment.
… but we may not need to standardize the collection point for that information in V1
… so priority is minimum amount information to be exchanged

padler: but I am struggling how we will make a payment without credential/authentication information
… the challenge is understanding that the message has come from a verified source.
… I think we need “hooks” even if we don’t standardize everything in v1

manu: Are you saying we need to find a way that the merchant has signed a message?

padler: more what is the basic structure of the payment message, so we know where to find information.
… we don’t want to lock ourselves in a single auth. scheme or crypto method
… especially given global scope
… I am less concerned about the details in the message, but more that the message construct allows us to plug in.

<wseltzer> to clarify, we’re talking about end-user authentication

padler: we want to allow for evolution….we need v1 to have a notion of authenticaiton

adam: unless it were a wrapper (e.g., like a digital signature)

wseltzer: the authentication you are talking about is different from the authentication we are talking about…FIDO work is end-user client authentication
… and you are talking about authentication of entities sending messages in the transaction
… and there we can draw on existing standards for messaging and authentication
… if there are components missing from those existing things, we need to figure out what to do (and not reinvent CAs)

jeff: I don’t know whether the payments community needs FIDO-style multi-factor auth in V1. But I want the payments community to pay attention to the work. Don’t want the payments community to come around later and say “we need it but not this way”

<mountie> messages (invoice?) can be verified by recipient in various ways. do not need to standardize it I think.

jeff: I hope that the payments community will look at this work as it is being planned

Laurent_: I want to add my voice to Pat’s…we want a placeholder for what a payment scheme would have to define on top of our work
… e.g., maybe we can add this to the document … an example of what a payment scheme extension would look like to do a web payment

Erik: Hard to add security on later….

adamm: I agree. The placeholder is there. It’s external to the message. If we want to design a standard, then I think a good approach is what we were doing – minimum standard necessary to design a baseline transaction and the rest is layers around it.
… as the message traverses the system, you don’t have to predesign the layers of the software that unpack the data
… you want an extensible system so you can, e.g., get rid of a flawed authentication system….shed the external component and leave the internal parts untouched

dezell: I think the WG can work out the layering
… we can feed them the use cases
… but we should stay simple…and not tell them “how” to do it

<wseltzer> Ian: we’ll summarize later

<wseltzer> … wrt Evan’t proposal: increase usability by making it less necessary to enter data (?)

Dan: I thought I heard these top-level things

– proof of purchase

– individual authenticated (either way)

– transaction authorize

scribe: and not a whole lot more
… some elementary message sets that can be accommodate and extended

<wseltzer> adam: define the simplest possible message formats and protocols

<Zakim> AdrianHB, you wanted to clarify a point in the scope

<padler> +1 to identifying users of apis… this was the intent of the pie diagram… namely in that it could illustrate who is sending, who is receiving.. and the specific type of interaction..

dbaron: (not in v1) but a site could send info to browser on how to handle payments, rather than the browser having customized knowledge

<dbaron> One comment in reply to jeff: we’ve had charters that have had optional deliverables in them.

<adamm> +1 jeff

<jeff> +1 to dbaron’s point (in response to my earlier point) to include certain charter items as optional items

<mountie> think SSL negotiation.

<evan_schwartz> +1 to Nick’s point, minus the payment confirmation

<Zakim> manu`, you wanted to say that there is a flow that has been implemented that supports registration.

manu: On registration
… one of the things we were concerned about when we talked about registration was vendor-lockin
… we want customers to be able to switch providers, we want people to be able to use instruments across devices and in multiple locations
… having a mechanism where your payment provider can associate themselves with you so that in any context you don’t have to constantly sync devices together to make sure all payment instruments are available
… we don’t want to create a system where you are locked into using payment instruments on a single device
… there are technical implementations of this that we could look at to see how this registration and sharing works
… so before we take things off the table in the names of complexity or clarity, we should look at work that’s been done as part of deciding what to take up in v1

dans: Thought experiment…look at point of sale terminals historically….lots of merchants have processing systems…but thanks to standards, I can swipe a card and key information gets into diverse merchant systems

<nicktr> +1 to dan’s comments. Note that part of that very basic “walk up to a terminal” experience includes the discovery of payment instruments in the selection of the AID (application ID)

<adamm> +1 evan

<nick_s> +1, note that some payment instruments that are stored locally can’t be synced easily, and they should be accounted for

<padler> synching is VERY important when the data concerned is a representation of value…

<padler> not just information (like passwords)..

<adamm> PCI DSS

<Zakim> dezell, you wanted to +1 dbaron characterization of a wp

<padler> +1 to specifying who the consumers of the APIS are and how the api’s will help them..

<evan_schwartz> +1 to Adam’s point that this is still an evolving space and it’ll probably look a lot different in 5 years

Ryadog: Sharing/synching is a pain point

<Zakim> AdrianHB, you wanted to propose some changes to the scope (https://www.w3.org/Payments/IG/wiki/Roadmap/PaymentArchitectureWG/ScopeProposal)

<Zakim> jeff, you wanted to respond to evan about useful standards work for payments

<Srikanth> +1 Erik, We should still suggest a minimum required security for the payment instruments to be exchanged from the initiation to rest

<AdrianHB> For anyone looking for something to do this evening there is a free concert in Central Park by the NYC Philharmonic: http://nyphil.org/concerts-tickets/1415/concerts-in-the-parks-june-17

Do our use case changes affect our charter scope?

<Karen> Scribenick: Karen

Ian: proposal for how to run session is to look at use cases

…and make real adjustments to charter scope to see if we are on the same page there

…Do people have other recommendations to establish where we are?

…high level read of the room

…on the screens, left side is use cases

…right side is the original list

…Things marked originally at risk

…Will focus on what the break-out group did

…go through what they thought should be in first

…then begin to attack it

…Registration lists payments was considered in by the breakout

…no account is required to make a payment for some types of payments

…multifactor, payer initiated

…of at risks on right side, here is what we said

…Adding back payee and payer initiated

…consensus we should cover merchant initiated in the charter

…Delivery of physical goods

Manu: Idea that you can buy

…in version one, in previous list we said virtual only because it’s easier to deal with

…physical goods is about buying a tangible item

IJ; Is addition of that use case changing the charter?

Adrian: purpose of use case is to consider that in the flow the merchant may want to get additional information from the payer

…like get the delivery details

IJ: not that it’s bikes, but that some additional information may be needed such as shipping address

@: will that be covered?

Joerg: Should we name it more generically

Adrian: we could call it out more explicitly

IJ: just enough to do what is needed

weinig: when constructing…you can set address…one way to think of it

IJ: In payment flow we have negotiation of terms

…hearing that this happens in the negotiation of terms

…things critical for completing transaction

Jeff: Katie suggestions delivery details

IJ: Delivery details or something like that

Adrian: use cases in scope

…ordering physical goods, the requirement is addresses

IJ: electronic receipts

…acknowledgement of payment is what we were talking about

…confirmation is in for B1

Jeff: first level

IJ: subscription

…doing a one-time payment is easier than subscription

Adrian: two in there
… subscription and common refunds, stretch goals for V1

…a lot of demand

IJ: those are considered optional
… anyone who iews not stretch goals

nick_s: We consider subscription to be similar to brick and mortar physical details

Evan: with subscriptions, that sounds great; a request for payment, but more complicated

…merchant needs a way to request that

…but aren’t refunds on the level of the payment instrument

…do we need APIs

Kate: Also the merchant and financial institution

Adrian: Was there a request for retailer

…difficult to get adoption if cannot match refunds to purchases

…if we ignore there will be a challenge

IJ: is that enough to satisfy the merchant requirement

S: [missed]

…at same time, subscriptions

…I think if we don’t complete by then

scribe: that would be a challlenge

…subscriptions is a big industry

…no different from payer initiated transactions

Chris: a lot of pieces of refunds

…parts of that need to be tied to the purchase

…peel back the onion

Joerg: my question about refunds

…if we voted the receipt out of V1 and we need the approval of merchants for the refund, how does that work

Adam: in the design, first one was

…with confirmation

…not sure we are ready to decide if that is necessary

…don’t think we understand enough to decide to pre-determine yet

…maybe for V1

…but for overall design of subscriptions, suggest we move to V2

…look at simple as possible, we have not designed it yet

…and look at more complex payment…feels like putting cart before the horse

<Zakim> padler, you wanted to discuss transaction context..

Pat: Comment on

….going back to February F2F

…they described economic transactions as a series of context…return of goods

…as part of those mechanisms, greater transaction context

…how to pass the receipt; how to reflect that

…not needed day one but need books for them moving forward

Magda: Agree with that

…several of hese things are termed in

…better to have in

…list critical path

<padler> +100!!! 😀

…multifactor, including biometrics, subs and common refunds

Manu: updated list is on the right

…is on V1, including the stretch goals

Mountie: want to identify user

…not so common

<Zakim> dsr, you wanted to keep commercial transaction and payment transaction weakly coupled

Dave: Adding to what Adam said, I like clean separation, architectural layer

…we talked about commercial layers

…and payment transactions

…need a minimal coupling

…refunds, disputes, taxation

…I understand we need different stakeholders

…how do we keep the minimum coupling to do the work

Zack: i talked yesterday about our learnings

…request auto complete

…what we did

…we did not pass back credit card numbers to the merchants

…we passed back proxy cards

…We learned that was a big blocker for impemetnations

…biggest reason for lack of adoption was subscriptions

…auto complete

…want to throw it out there

<nick_s> +1 subscriptions

<Srikanth> +1

<padler> For those that were not at the Utrecht meeting, here is the link to the FOCAFET informationreferencing Economic transactions…

David Ezell: Any relationship to V1 and 2017

IJ: We should determine deliverable dates once we know fully what is in the charter.

IJ:…and figured out our activities

…and divvied up among charters, we will have the time

…but longer it will take if one group does one spec

…if we break it out, like security groups in parallel

…proposal is to charter group for two years

…i did hear the sentiment

…here is V1, very tight and agile, and low hanging fruit, but it will take to 2017

…I don’t think those two should be planned

Jeff: David asked a good question about schedule

…maybe not the case we can figure it out in a large group

…to get to any schedule, we have to learn how many people are willing to put time into things

…there is real work to be done

…If there is a dedicated team, we can do stuff in a year

…but it could take longer if people cannot dedicate as much time

…we have 42 orgs in this IG

…find out about resources across this community

IJ: I would like to go through this list

…and see, yes, if that is what we would like and try to map them to the charter

Ryadog: not revote on what we have voted on?

IJ: Not everyone knew what these things meant

…is this what they are doing?

…do people know what these short keywords mean?

…Any thoughts on right screen; is that what we are doing for V1

Katie: Minus credentials

IJ: Seeing no questions, can we see a show of hands of support for V1

[Ian counts hands]

ij: 27

…are there objections to this group to V1

…no objections

…now we can map to the charter

<Magda> *mentally cheering *

IJ: exercise is to figure out where things go

[Scope section]

IJ: Web site is meant to say discovery is meant to happen in browser; do same instrument

…Registration-less is … not sure that impacts the draft charter

Manu: It does, we minimize it to mean you should be able to buy something without creating an account on a web site

…may have to fill out some information, but not have an account

IJ: Not including that question

Katie: it includes this

IJ: draft charter doesn’t take this into account either way

…by including registration lists, we are not implying any change to charter


Katie: Are we trying to determine which use cases fit under one of those four bullet points?

IJ: Adrian’s tweak for what fits into a Working Group

…the things we would like to be in is the charter prime

…taking into account comments from the group

…not changing anything

…in the charter

…finding out what changes to charter are needed

Katie; Stick a number?

IJ: Not sure it maps directly

…one-time payment

…Ubiquitous schemes I believe is taking into account existing and future schemes

…not all-inclusive

…not clear in draft charter

Manu: Schemes that are widely deployed

IJ: Like some systems like cards

…so we have to include merchant initiated schemes

…and these are subsets of that

…Discovery; I have lost where we were

…on the mood of the room on registration of payment instruments and discovery

[reads from document]

Adrian: Can we distinguish between discovery and registration

…we want to mandate if you are confirmant to spec, you allow any scheme to be registered; that was my understanding, but not standardize that process

…that is pre-payment

…Discovery is some form of negotiation of a common scheme

…to describe the payment schemes available

Manu: Discovery has to do with you having multiple digital wallets on different services

Adrian: That is payer selection

Manu: But it is labeled discovery in the document

Adrian: why is that discovery

IJ: My understanding is that the user shows up

…installs the BOA thing, and I can have it

Adrian: my understanding of workflow differs…selection by the user

IJ: that’s good

…asynchronously I show up and it’s known to the system; in browser

…then when I go to pay a few days later, the browser can discover and invoke it later

…then I select from among

…register, invoke/discovery and then choose

Adiran: Discovery is some scary stuff

…vs payee making the selections

IJ: browser helps in finding the intersection and invokes…

Manu: not what the use case says

Adam: Should operate in a way that it’s user choices; no automated discovery from merchant

Joerg: You are talking about refinement; register every schema; whether done by browser or operating system

Jeff: we are trying to match undefined words on right with undefined woods on left

…one of the exercises that needs to be done

…not sure if we can do all the details with all of us together

…but we need to get clear definitions of each step and the use cases and define what the terms mean

…we can surface issues, but not sure we can resolve

Manu: we should understand use case work and flow

…we have done that

…no time to rehash it now

…then for specifically for the discovery use case, to clarify we should use the text in the use case first

…versus trying to derive what it means

Jeff: for 6.2.2, what is the verb? What do you do?

Manu: assumption is that when provided multiple options, and choose from among them

IJ: that process is described higher up in the document

…Looking at these, I sense it’s largely covered

…some have to do with terminology, some around clarify

…multifactor covered in a different WG charter

…subscription is a stretch goal

Adiran: We will need to change something in scope to handle that; second bullet says pay and payer on one-time purchase

IJ: Virtual goods and physical goods is about delivery

Nick: not sure

IJ: this broader context of ecommerce vs narrower focus on payments

…this charter seems narrowly focused on payments bits

…in charter should we give more context to help people understand where we are coming from

…the bigger sense of receipts and invoice

Pat: Goes back to something

…Evan said on break

…what we can do now is thinking about the broader economic transaction to specify placeholders in V1

…they have to be there so as pieces emerge, we don’t have to completely rewrite the transaction message

…if we can define some of this, we can let go of details

IJ: Can you as architecture guru, capture somewhere, like capabilities doc, or elsewhere

…and to what extent there are regulatory hooks

…so we can add into charter as needed

Pat: yes, I will

…and for group’s benefit, if we can get a consistent skeleton for message, we can use whether it’s an international transaction; makes it easier for hardware vendors to standardize

IJ: Pat needs help

…to write up a skeletal structure

Adrian: That is WG work

Laurent: Where do you propose to do that?

ij: …Adam said how to layer architecture; great if you would write out the layers you have in mind

…charter says it does

<scribeACTION: Adam to write up architectural synthesis of what he is thinking [recorded in http://www.w3.org/2015/06/17-wpay-minutes.html#action01]

<trackbot> Created ACTION-110 – Write up an architectural layer synthesis of components of the web payments stack. [on Adam Muntner – due 2015-06-24].

IJ: I don’t see anything else requiring substantive changes

Magda: might…

IJ: Some identifier common between payment request and confirmation to satisfy the refund thing

…just need to know this is the same things as that

Laurent: rephrase as refund request

IJ: either an annotation or referring to refund request

Magda: I defer to the retailers

Adrian: Sufficient there to…

…we have examples of what is in the payment requests

…can I put in transaction type?

…that is how it is done in @ today

…purchase type or it’s refunds

…when you do a card transaction today

…when you get your payment request document

…in that payment request I want it for this transaction type

IJ: Retailers are nodding for transaction type

@: for acceptance schemes

…might not initiate refund, as long as there is an acknowledgement

…of payments, but could be more clear on the structure of the message

Cyril: Payment report is @ 14

…description of everything

…full XML description of payment instruments

IJ: Vocabulary or data fields

Cyril: everything used in ISO22

IJ: Can you write references into irc?

Cyril: yes

IJ: sounds like next action is to modify the charter

…Adrian, can you continue to make the edits

Adrian: I added in discovery of instruments that can be used as intermediary step

…updated dated in payment request

…that’s it

IJ: there is a wiki with the original charter with concrete deliverables

…don’t know how these changes affect the concrete deliverables below

…do they affect?

Adrian: I think they do

<scribeACTION: Adrian to create revised WG charter [recorded in http://www.w3.org/2015/06/17-wpay-minutes.html#action02]

<trackbot> Created ACTION-111 – Create revised wg charter [on Adrian Hope-Bailie – due 2015-06-24].

IJ: Jeff said we should say how this is going to benefit different audiences

…would we get buy-in from people in this room because it improves interoperability of payments

<CyrilV> here is the url to the pain 013 (payment request) and pain 014 (payment report)http://www.iso20022.org/full_catalogue.page

….I see some nodding

DavidEz: creating a payment request sounds like half job

IJ: these bullets constitute a flow

…there are other bullets to be done

David: Ok

IJ: One thing I would be happy to work with people as part of the Comm TF is to get a clearer articulation of what we are trying to do

…what are you doing; how is this new; what is it going to look like

…Is there anyone who is keen on the expression on the broader audiences

…Help me with a one-pager to explain how to make things eaier

…Manu, Arie, Claudia

Jeff: Anyone with a past comm role?

Erik: and anyone who is good at it?

<scribeACTION: Ian to work with Arie, Claudia, Manu, Srikanth and Zack on communications [recorded in http://www.w3.org/2015/06/17-wpay-minutes.html#action03]

<trackbot> Created ACTION-112 – Work with arie, claudia, manu, srikanth and zack on communications [on Ian Jacobs – due 2015-06-24].

Jeff: that is a great selection of names

…with representation from all the bases…browsers, banks, merchants, etc.

IJ: if someone with visual skills, would be good to have a chart or visualization diagram
… maybe Pat could spearhead that

…anyone who could do the visual flow descriptions

…that would be a nice set of materials to give to the membership to support

scribe: David, Laurent, Adrian, Srikanth

Srikanth: clarify contribution…

…I will do what is working today and how we want it to work

IJ: Does someone want to take the lead?

…Yaso will take lead

Pat: We are going to have people reflect that part of payment system

…that feels like next step

…first to understand the flows and then do others for marketing audience

…maybe a higher level for others

IJ: for AC?

Pat: depends upon the audience

IJ: My thought is it is more flow oriented to help people understand the charter

Pat: for WG to consume

<scribeACTION: Yaso to organize a flow diagram conversation to produce what is supported by the charter [recorded in http://www.w3.org/2015/06/17-wpay-minutes.html#action04]

<trackbot> Created ACTION-113 – Organize a flow diagram conversation to produce what is supported by the charter [on Yaso Córdova – due 2015-06-24].

IJ: Thank you

…Sounds like a nice foundation for where we are and what is next

…Dinner is at Fusha (sp?)


Presentation on Apple Pay


Nick: demo of payment flow

…last week is first time we talked publicly about Apple Pay which is in the presentation

…we have seen many apps with Apple Pay, more high value transactions, greater growth of transactions using inApp

…can see that in the deck

…talking about payment flow

…Apple Pay works with a secure element [scribe missed something here]

…See in web context, how this would work

…if you did not have PayPal, you can divert the checkout

…If Apple Pay is available

…you can display it

…ask if touch ID is valid

…some stuff happens here

…secure element and touch ID

…are encryptographically paired in factory

…we can still guarantee that it’s not been tampered with

Katie: live finger print?

Nick: yes

…So the secure element creates a cryptogram

…we support a full EMV format and code 3DS

…because you send it over 3DS rails

…difference between Apple Pay and others is we have a slightly different method for running it

…two options

…this gets encrypted and goes down to our servers

…We don’t trust the transport

…so you have to create a merchant identifier

…and a certificate you give to us and we re-encrypt it

…only merchant can do it

…encrypted by secure element

…this bubbles back up through iOS and delivered to merchant

…most support Apple Pay

…people make payments and it runs through the normal rails

…that’s kind of it

…the flow I described just now maps somewhat to what we have been talking about at this meeting.

…We have a payment request

…describes payment you want to make

…confirmation, we return a confirmation to merchant with this cryptogram

…we sign the payment, you go off to process it

Katie: what do you feel in this chain is where you have the highest level of vulnerability?

Nick: very good question

…we would probably say in this chain it is where you send the cryptogram back to our servers to be signed

…not a huge amount of vulnerability

…it prevents merchants from taking a token and charging it

…the underlying data has already been encrypted

…But you might have realized you are sending to iOS before you encrypt

…We sign and encrypt with a secure element

…We are never sending ….

<Magda> For Further reading and learning: https://developer.apple.com/apple-pay/

Katie: encrypt and re-encrypt

…I think the process is one of the more secure out there

IJ: When we are coming up with charter, what are the implicit security requirements in our notes

…encrypt this in our requirements, so these things have to be tamper proof

…that suggest technologies or protocols

Katie: and a viability of where the secure element

Nick: We are not proposing this flow for web; it’s for Apple Pay
… ApplePay owns the stack from application through OS

IJ: If we want to create a secure flow, I am hearing you need confirmations and so on

Nick: A token anonymizes the payment information

…I don’t want to put Google on the spot

…Android pay is similar

scribe: one of big differences is that Android provides a pure token system

…if it was intercepted over the transport, there is no embedded information

…We encrypt with token ID

…ultimately, looking at security and advice we would give

…it’s not enough to trust the transport, you are encrypting your own data

Sam: Hard to do this in a web context

…one thing we are able to do

…because we established relationships with merchants, we can get merchant public keys ahead of time

…at no point do we have to trust that channels are not compromised

Sam: Good question, that does not exist

…similar ideas are certificate authorities

Nick: Android pay, based on documentation

…you can integrate directly with payment processors

…Stripe and @

…you can ask Google to send you a stripe token

…kind of a solution to that

…our flow relies on merchant having registered with us ahead of time

…that may not be ideal for the web

…merchant may not want to do that

…we do it for control

…allow additional security and revoke identifiers and bad actors in the system if someone is harvesting tokens

…This is independent of the standard

Adiran: how similar this flow is for what we envision for the Web

…if we replace iOS layer with the web context

…looks similar to what we are proposing

…that check-out is what we call a payment request

…Only thing I would say is this is merchant authorized

…flow to Apple Service, if instrument specific; maybe send a proof of merchant payment

Nick: reason it goes to merchant is that Apple mainly deals with credit and debit cards

…there is something similar to what you are talking about

…payment gateways

<Ian> Nick: Stripe, Braintree, first data, authorize.net

…that offer device side SDKs

…merchant often never gets any of this data

…get to step where we generate cryptogram…payment gateway sends back to device

…merchant never sees any payment information; an implementation detail of this system

…coudl go straight to the user

…I think it’s similar

…device does its thing

…discovery is a big difference

…we have API

…allows us to query types

…to discount

…on web side, having a discovery scheme, you want merchants to offer up front what they are prepared to offer

…a few differences

…go off and make a pyament

…there will be some schemes

…replace the secure element with PayPal

…then there is no token coming back to the merchant

Adrian: maybe they don’t need that

Nick: nothing to prevent browser from adopting this

…additional protection in apps environment

Adrian: it feels a lot like the existing implementations

…informative references for what API should look like

…Apple Pay, Android Pay may not be that much different; perhaps a proxy to the Apple API

<Ian> scribenick: Ian

<Karen> How we handle contact and shipping information?

Nick: when merchant provides payment request
… they can also ask for information they need (e.g., shipping address, email, phone)
… the merchant does not at this point know shipping cost (depends on destination)
… we don’t release the full shipping address
… we display it on a sheet but don’t release until touch id
… what we actually provide apps before the touch id
… is we obfuscate the shipping address
… we provide just the zip code and city
… this allows merchants to estimate shipping
… they tell us that’s not enough in the US especially for tax
… in the UK it’s a single tax rate…but in the US the tax rate can vary by zip code
… another interesting difference with android pay is that we always make you touch id
… android pay has more of a consent-based model where you can delegate after the first time

<Zakim> Ian, you wanted to ask whether we need to have public keys to secure our payment data?

<Karen> IJ: we have 5-6 people in queue

<Karen> IJ: I was curious about this public key registration thing

<jeff> Ian: Is the added security you would get; make it a great feature for the web?

<jeff> … “if you have public key – we’ll do a better job encrypting”

<jeff> Nick: Merchants would say it is more painful than card number

<jeff> … Target has implemented

<jeff> … I don’t think it is too hard

<jeff> … But a centralized key for the web is not great.

<jeff> Sam: This was a decision made by one company

<jeff> … but TLS and HTTPS are secure channels

<jeff> … people should be happy with that

<jeff> … let’s not denigrate TLS

<jeff> Ian: I was not suggesting centralization

<jeff> … A user might want to use 1:1 with merchant’s public key

<jeff> … if supported by browser

<jeff> … merchant is happy

<jeff> Sam: You could pass along public key with payment request

<jeff> Srikanth: 2 factor with RSA is an option

<jeff> … can instrument consumers

<jeff> … get entire payload sent to server

<jeff> … I don’t think it was painful to support ApplePay

<jeff> … payment networks helped

<jeff> … pain points: tax changes, reauthorization, returns

<jeff> … unclear – can we store and reuse cryptogram

<jeff> Nick: Cryptogram depends on brand

<jeff> … “tokens disappearing” is an EMVCo issue

<jeff> Cyril: ApplePay is mainly a wallet for users

<jeff> … then you add relationship with public key, contractural with merchant

<jeff> … three corner model

<jeff> … to put it on the web it will be hard because Apple Server could be split – Merchant payment service provide and user payment service provider

<jeff> … But it is harder if these are two separate devices then incorporated into AppleServer

<jeff> Nick: We don’t propose this for the web

<jeff> Cyril: The merchant only has token (not card number)

<jeff> … so token is inside the secure element

<jeff> … prefed?

<jeff> Nick: We have a security white paper (IOS security)

<jeff> … IOS cannot query secure element for that information

<jeff> … even if device is compromised.

<jeff> Cyril: Where are the flows that get the token inside the secure element?

<jeff> Nick: Magda will post link to video

<jeff> Erik: Use PKCS-11; chained together keys

<jeff> … use a key to encode merchant’s private key

<jeff> … vulnerability only gets to outer key

<jeff> Nick: Somewhat. Merchant key is entirely separate.

<jeff> Erik: To rekey the system.

<jeff> Adam: Mozpay is totally different. Only for virtual products.

<jeff> … similar approach w/o hardware element

<jeff> … sign JWT (JSON Web Tokens)

18 June 2015

Use Cases Next Steps

<evert> … some people joined us

<evert> … karen myers, w3c,

<evert> … James Dailey gates foundation

<evert> manu: use cases

<evert> … made good progress on use cases

<evert> … now question is what will we do next

<evert> … let people now how use cases will be added

<evert> … alignment with US fed and Gates foundation to be arranged

<evert> … be aware of each other work and goals

<evert> … alibaba biometric use case

<evert> … bio is in for v1

<evert> … afak use cases for v2 and beyond – submit to mailing list in the format as used till now

<evert> manu: how much focus should we set on use cases: should we back off for now?

<evert> … how much time to spend in the calls?

<evert> padler: use cases to be sent to the public list

Boleto Use Case (Brazil)

<evert> leandro: Boleto use case presentation

<evert> leandro minneti: Boleto a payment method from brazil

<evert> leandro: works at CIP, clearing house of Brazil

<evert> … 41 shareholders (all banks), non-profit org

<evert> … Boleto payment method – famous in BRazil

<evert> … Invoicing for b2b and b2c transactions

<evert> … for banked and unbanked people

<evert> … 1.3 bn boletos have been issued last year

<evert> … may be paper or used on web

<evert> … can be used up to due date, after that only at the bank issued the boleto

<evert> … boleto shows on paper the payer, payee and a barcode

<evert> … barcode also has a numeric presentation

<evert> … unbanked customer can use internet access to order something

<evert> … selects Boleto as payment method

<evert> … the Boleto is then generated (paper)

<evert> … boleto than brought to nearest bank to pay it

<evert> … bank credits payees account then

<evert> … and e-commerce goods can be delivered

<evert> …Banked people can directly log in the banking system

<evert> … Merchant will receive amount paid from D+1 t D+n (depending on float of the bank)

<evert> … merchant will bot be deducted by fees duchs as MDR (merchant deduction rate)

<evert> …25% of e-commercie is paid through Boleto

<evert> … on e-Bay, Deal Extreme and AliExpress as well

<evert> Claudia: any details on B2B volume?

<evert> Leandro: details not available now

<evert> Leandro: credit card payments – easy monthly installments

<evert> Q&A on Boleto

<evert> mountie: does merchant receive the funds on the same moment?

<evert> leandro: CIP does clearing and settlement

<evert> mountie: does merchant receive the total amount?

<evert> leandro: yes, the total amount is received

<evert> … bank may charge the consumer a fee such as $1

<evert> Arjun: is boleto used by mobile?

<evert> leandro: mobile app can read the barcode of the boleto

<evert> ian: what does this resemble in other regions?

<Ian> Arjun: Asian bill-paying

<evert> vish: voucher based system do exist, some in europe, other in asia

<evert> … thinks that boleto usage level is falling

<CyrilV> there is a lot in Europe, often basedon a Credit transfer

<CyrilV> France will launch RUBIS 1206 in July, a boleto-like based on 1) electronic request for payment 2) validation by user at mobile or home banking 3) Sepa credit transfert.

Gates Foundation Level One Project Use Cases

<evertJames Dailey – Gates Foundation presentation

<wseltzer> James_Dailey: Here from Bill and Melinda Gates Foundation

<evert> james: here as observer

<evert> … Gates Foundation looks at financial inclusion

<evert> … payments is a way for improving financial inclusion

<evert> … Financial Services For The Poor

<evert> … working with central banks, finance sector

<evert> … in The Level One Project

<evert> … started 1,5 yr ago

<evert> …what if people could pay from phone to phone

<evert> … sign up very rapidly

<evert> … integrate with anyone in the world

<evert> … and cost nearly nothing?

<evert> … as Bill Gates said on SIBOS

<evert> … shows DFS System Reference Model (slide 4)

<evert> … DFS Digital Financial Services

<evert> … models for issuers, acquirers

<evert> … roadmap for architecture

<evert> … rules, rails, accounts, apps

<evert> … use cases

<evert> … make bulk payments to anyone

<evert> … self-issue, figuring out identity issues

<evert> … send money anywhere

<evert> … buy from any merchant in person

<evert> … connect to credit offering services

<evert> http://www.leveloneproject.org website just launched

<evert> … discussion forum for these issues

<wseltzerThe Level One Project

<evert> … low cost, zero barrier to entry financial system

<evert> Cyril: what is tiered KYC?

<evert> james: under a certain level of transaction, you may have to know less about the consumer

<evert> … could you use the social networks of people?

<evert> … vs government issued credentials

<evert> dan: are you thinking this replaces cash? what is the vision?

<evert> james: vision is partial replacement for cash. mpesa is only doing 3% of trx in Kenya, greater % isrequired to 40%

<evert> padler: broad field of view, what is the most important standards required?

<evert> james: identity is one

<evert> … how to create interface between different payment schemes and providers?

<evert> … interoperate well

<evert> … south africa has modern rails, but other countries are on other standards in the region

<evert> mountie: design principle for immediate fund transfer:

<evert> james: immediate clearing

<evert> … push payments and irrevecobality give some push-back

<evert> … irrevocability raises the bar to send to the right person

<evert> … USSD is widely used still

<evert> … (like SMS)

<evert> … session on server, send information back and forth


<evert> … prototype to confirm sending to the right person, and then initiate the push payment

<evert> arjun: how to deal with FX rates?

<evert> james: not interested in international remittance, everything is within a country

<evert> … in Pakisatan huge flows from Karachi into the country

<evert> … cash-in and cash-out to be made digital where possible

<evert> zkoch: mpesa, google initiatives. Not too much success

<evert> …what have you learned making this successful?

<evert> james: world is changing very rapidly, smartphone growing quick

<evert> … MNO market interest growing fast (customer relationship)

<evert> … inter-op is the missing piece. multiple oeprators

<evert> … require connection between at least a number of MNOs

<evert> …mpesa doing wonderful work, also now with merchant services

<evert> … VAS such as credit facilities for merchants

<evert> … goodness with the rails

<evert> dezell: where did you get push back?

<evert> james: from incumbent institutions in transactions today

<evert> … replace 4-party system with irrevokable push based payments

<evert> … is pushed back from incumbents in that markets

<evert> James: getting the next 3 bn people getting access requires a new business model

<evert> vish: is this about new standards?

<evert> james: we put out an argument, a vision and want people to reacht on that as first.

<evert> … working with specific countries to realise pieces of this

<evert> … tip business models a bit

<evert> … on a technical level design how this would look

<evert> … central switch, KYC, take a mesh/distributed approach?

<evert> manu: work to do on use cases, dialogues with FED and on use cases

Adoption and Deployment considerations

<evert> Ian: now 45 minutes to talk about deployment

<evert> … then prepare roundtable preparation to identify questions we like answered

<evert> … then some time for hot topics till lunch

<evert> … and plan further meetings

<evert> … implementation considerations: what is required for success?

<evert> … W3C needs help to predict hurdles to success from the participants in WPIG

<evert> … who have deployed systems: what have you hit at any point in time? Interesting for us.

<evert> … how do you set up an implementation?

<evert> … experimental phase with payments, are people prepared to join?

<evert> … how should roll out plan be designed?

<evert> … Very early discussion, not even a working group

<evert> manu: would be nice to get commitment of organisations during next 6 months to doing implementations

<evert> manu: version 1 should not depend on hardware (sw only)

<evert> … not try to standardize something which does not have an active prototype now

<evert> adrian: apple demo – why not be web? – the api’s look very similar to what we would need in the browser

<evert> ian: w3c requires that two implementations are needed

<evert> … not over-constrain requirements now

<evert> … many WG’s start implementation much sooner than standard

<evert> … WG should begin rightaway to explore possible implementations

<evert> … pushes back a bit on implementations

<evert> jheuer: are we looking for vertical integrated solutions?

<evert> … payment solutions or platform?

<evert> … w3c should be more on the platform

<evert> … what would be outcome of w3c work?

<evert> … so horizontal (platform) of vertical? (payment)

<evert> … need to support an ecosystem

<evert> ian: ecosystem reminds to developer too

<dezell> ian: we need to consider developer buy-in and how to get people invested in the platform

<evert> srikanth: target is doing feew thins, bringing in inter operability

<evert> … develop prototype for standards

<evert> … consolidate standards asap for building prototype

<evert> manu: supporting both native and cloud sounds simple, but is a difficult political questoin

<evert> … outline what would be seen as success in v1

<evert> … eg getting two retailers on board, a certain number of transactions, etc

<evert> Erik: people can combine mobile and pc in one transaction

<evert> … hardware we already have, fido has authentication mechanisms which can be used

<evert> Laurent: sees mostly things we should NOT do

<evert> … now we need to break down the work as being a developer

<evert> … define parts which are a problem now

<evert> mountie: paygate as a small company develops a banking platform in korea. part of banking is ISO related. start ups need standards

<Erik_Anderson> Iterate on what Vish said last night, users place the item in their card on a mobile but do the checkout on the PC. This is due to security concerns about doing the payment via a mobile device. We can use the FIDO U2F for better authentication for v1.

Presentation on Deployment Considerations

<evertPresentation by Dave Raggett

<evert> dsr: launching a WG, minimal standards

<evert> … recaps on some details

<evert> … not on tech expert, but issues need addressing

<evert> … what happens when WG is launched in the IG?

<evert> dsr: payment request from payee: what data elements, schemes accepted, additional fees, passing proof of payment, idinetify payee to the payment scheme

<evert> … passing public key for the payee

<evert> dsr: selection agent to present choices

<evert> … identifiers for payment schemes can be used to match

<evert> … however not a guarantee to work. human readable names, images for branding: how is this passed, where is it held?

<evert> … payer may want to ser prefs to pay with given instruments

<evert> … seamless experiences across devices

<evert> … or browsers

<evert> … technical: how will agents be implemented?

<evert> … native, web app, local web app, browser expansion, integrated in browser?

<evert> … payment request api must be independent of implementation

<evert> … could replace merchant web page, pass an IFRAME,

<evert> … URIs could provide a way to pass info to agent apps

<evert> … analogy to android intents with browser as abroker and registrar

<evert> … we may not need a multi step dialogue

<evert> dsr: payment instrument


This slideshow could not be started. Try refreshing the page or viewing it in another browser.

<evert> … software and hardware used as client for payment scheme

<evert> …. valuable role for browser

<evert> … w3c strong authentication WG planned for late 2015

<evert> … level of assurance required will depend on payment instrument and value of trx

<evert> …need for standards for conveying details to authentication API

<evert> … this does not address binding web identitiy and real identity

<evert> dsr: beyond V1

<evert> … value added services around payments


<evert> … persuade users to switch over from physical wallets

<evert> … economic trx are much more than just payments

<evert> … examples: expense claims for business travellers, manage monthly expenditure

<evert> … support tax audits

<evert> … avoid need for paper when returning goods

<evert> … fill purchase order screens (shipping and personal details)

<evert> dsr: Receipts

<evert> … part of merchant transactions

<evert> … rich information is required, more than in creditcard statements

<evert> … machine interpretable plus flexibility for presentation

<evert> … may be collected by an agent for the user

<evert> dsr: bigger opportunity

<evert> … purchasing tickets, paying taxi ridepurchasing gift cards, sending flowrs, etc

<evert> dsr: Where Next?

<evert> … WG should get a simple standard out first

<evert> … additional things: broad context of payments

<evert> … push payments, subscriptions, reversals

<evert> … oflline paymetns and p2p

<evert> … brick & mortar, contactless

<evert> … pre-authenticating of payer on entry to store

<evert> … related standards work on a broader scope

<evert> … loyalty, prepaid vouchers, coupons

<evert> … coneecting web-identity to real identity

<evert> …expanded role for web payments IG?

<evert> … new stakehoders, such as tax authorities, loyalty providers

<evert> dsr: hopes this triggers thoughts on how to proceed

<evert> katie: should we do cloud based?

<evert> manu: yes

<evert> padler: regulatory viewpoints? what is UK doing on digital strategy, enabling digital shift? Need proactive guidance from systems

<Dipan> +1 Key to have EU representation in the group.

<evert> jheuer: those who do have wallets now: chat about implementing things

<evert> jheuer: have legal issues in the company on joining working groups and seeks a way to help with the work

<evert> dezell: we are all motivated, but back in the day jobs it will be difficult

<evert> … need energy of others as well

<evert> … VAS work like loyalty may look peripheral but do pay the bill for investments required

<evert> … other VAS is in line with what Gates Foundation wants

<evert> … IG needs to look at complementary standards

<padler> x10 to encouraging others to join us!! 🙂

<evert> … align as much as we can with standards whcih are useful to us

<evert> … call from the chair to join the weekly meetings and get involved as much as you can

<evert> Erik: api’s should also be there for KYC

<evert> … could all different types of agents be put in the glossary?

<evert> … Fido (eg ubikey) will distribure U2F hardware to people

<dbaron> Or, alternatively, maybe the architecture shouldn’t be complicated with all those agents?

<evert> … here for general financial services conducted over the browser

<evert> nicktr: observes a lot of extra use cases root in the consumer side. Attention required for merchant side of things

<vishshastry> +1 on merchant participation

<evert> … people representing merchants are important for the work

<evert> … Tax is so complex, we should defer that to V10 or later

<dezell2_> Also, tax handling can lead to “unintended consequences” in developing areas.

<evert> zkoch: browser to help addressing merchant painpoints such as increasing conversion

<CyrilV> Krysty q+

<evert> nicks: apple here to cooperate as a browser vendor (webkit)

<evert> kristy: merchant participation: ton of efforts all over. Working on ti, but a struggle. Most merchant apps are native (rather than cloud based)

<evert> … that may complicate matters

<evert> … may different levels of involvement

<evert> katie: cloud based wallet can still be offered to merchant, should not be worried about that. must be brandable

<evert> dan: cloud based would need a connection in a store. does it work when offline?

<evert> srikanth: MCX and currentc use cloud based approach too

<evert> … multiple wallets – apple, mcx, etc

<evert> … interoperable in stores is very important

<evert> dbaron: not sure on what wallets mean from a browser perspective

<evert> … needs to understand better what is going on there

<nick> +1 on that point

<evert> ian: charter describes communication channels

<evert> laurent: browser part is implementation choice

<evert> … we have to be open on different implementations

<padler> +1 to Laurent’s comment…

<evert> … different secure elements too

<evert> … it is not about the browser but about the web

<padler> the important point is that the “wallet” may be decoupled from the “shopping interface”… regardless of where either “lives”

<evert> … still too soon to make implementation choices

<evert> ian: main portion of the meeting now finished

<nicktr> Ian: Evan has implemented a prototype based on the revised charter

<wseltzer> [break]

Roundtable preparation

<Karen> Scribe: Karen

Ian: Coming to this afternoon, we have guests from about 20 companies [reads off]

…with those people in mind, what is that we want…

…and welcome Rafael from GSMA

…How to prioritize work and fill in gaps

DanS: I think you should ask same questions you ask of us

…we have browser vendors here, so ask them what they would like to see

IJ: That is a good broad question, anything more specific?

DanS: interoperability and security

IJ: topics to hit on are interoperability and security

Adrian: On the break we had an interesting conversation

…around the web context and security and the tools available to banks and financial institutions

…you are limited by what browser gives you

…Is it important for browser to vastly improve

…or should browser hand that off to something else

…either browser is capable of giving a better tool kit, or better at handing off in a more interoperable way

IJ: I was going to say for WebKit, Firefox and Chrome folks in room, what you would like to hear

…that would help you say, ‘that’s good to hear; we were wondering about browser next steps’

…you may already know these things from your relationships

Katie: for them to encourage

…only appears to have one gov’t agency

IJ: We have US Fed

Claudia: We’re not a gov’t agency

…but an important infrastructure

Kate: We want to encourage agencies involved in the development of this

…so they don’t say ‘no’

…important that they are at the table and a part of this

…have to work in concert

…and understand what their pain points are and what to look at

Magda: Which gov’t agencies and countries

Katie: finance, merchants, consumer protections; those organizations [globally]

Claudia: I think there are certain groups

…gov’t orgs, merchants, etc.

…who will not be willing to participate at this level

…it’s too small of what they have to do day in and day out

…we should find other models

…for their review

<jheuer> Qeue is already closed, so here are my fivepence: ask for the major pain points and drivers (naturally). Beyond this: what are the expectation wrt/ openness and non-discrimination?

…Other standards organizations I work with have developed mechanisms for input

Kiate; I agree, but it might be possible in some cases

…agencies are newer tech agencies

…not make it an expectation

IJ: For external review task force; should they develop that as a plan for how to do that

Katie: Back in your lap!

Claudia: Task force in action

<scribeACTION: Claudia to organize task force discussion to solicit discussions from stakeholders such as regulators [recorded in http://www.w3.org/2015/06/18-wpay-minutes.html#action01]

<trackbot> Created ACTION-114 – Organize task force discussion to solicit discussions from stakeholders such as regulators [on Claudia Swendseid – due 2015-06-25].

Joerg: Everyone wants to hear what the pain points are and what the drivers should be

<mountie> Basel Committee can be one of stakeholders

…when talking with political guys and industries that see they are going to have process changes

…how far what we do here is neutral

…and how much is going to be non-discrimination

…what are their fears, and how can we give them confidence that this [non-discrimination] won’t take place

IJ: I don’t know what that means

Joerg: Banks say we want to issue the wallets

…users say if I am a customer of that bank, but I do have a credit card and that does not fit into the solution so that is not good

…while other orgs come and say we want a non-discriminating platform for access for postal services

…only the big incumbant could install boxes

…now there is an attempt to come up with regulation

…on basis of this solution, they are considering digital keys

…one of those things that says it needs to be non-discriminating

DavidE: I have been hearing, we have not talked too much about regulation

…we may get some worries that we have not thought of

…what are their current challenges; how do we make that better or worse

…and are we going with the right standards

IJ: they may not have enough info to answer that

…and frame as web questions

…rather than broad question of what regulatory pains…

David: opposite, from what you know about web, what regulatory challenges do you see

<Zakim> manu`, you wanted to ask about how can we help them convince their organizations to participate.

<stefan_thomas> Also: What are their questions for us? They are trying to modernize regulatory frameworks, so I think the web perspective is unique and relevant in that respect.

Manu: I have heard conversations that large financial institutions find it hard to join an organization and work like this

…Arie has a list of objections

…so question is how can we get you involved in some way

IJ: I don’t want them to feel trapped

Manu: say it some other way

IJ: maybe there is a way

…seems premature to ask that question to invite them to get involved

…I’m still interested in the pain points

…it’s the first time we are seeing them

…note sure how to modulate; participation should be the story

<dezell2> “How can we make sure that you feel enfranchised in this effort.”

…not sure we can say that exact question

Manu: yes

Erik: on the regulatory side, I have had discussions with Jennifer @ from @

…and consumer protections…

…they won’t get involved until there is something to regulate

…if we give them a tool set, then they may get involved

…reduce the work they need to do

…but you have to do it in way that tool set allows them to do their job

…they are in agreement, but need some reason

Katie: not limited to regulators

Erik: yes, consumer protection as well

…they do come to talk to me

Arie: I was going to echo both of the comments

<Zakim> evert, you wanted to say that financial industry players do need open “tools”

…We discussed a more blended group of participants would help create a more ubiquitous deployment of W3C standards that is not lop-sided by retail

…I made efforts with Karen to invite people to attend today’s roundtable

…shared sentiments…whom to assign, allocation of person’s time, interest in implementing standards, cost to participate is a hurdle

…I have only spoken to financial institutions…some initial feedback

…how to overcome those resistances may be focus of a small group’s efforts

…before going out to market you consider those objections and have answers to those objections

…I am happy to help and to participate in that group

IJ: thank you, and we’ll continue to work with you

Erik: and the patents; they want to hold onto them

DanS: I don’t know how technical they are, but they have all seen mobile take off and take control

…we saw Apple’s capabilities yesterday

…could be important to relate mobile and web to them

IJ: Jeff has some of that in his presentation

…is there a question in there for them?

DanS: I think they know what you are about, but how does it relate to what they are trying to accomplish

…underlying foundation and why

…excellent suggestion, we know that they don’t have the time and bandwidth to participate, so what is best way to keep apprised of best way

…without being fully engaged

IJ: Voice a word of caution

…we do have merchants and banks in the room here

<dezell3> please see my suggestion for wording – keeping them “enfranchised”

…we have to work through some of these challenges, so let’s not put them at arm’s distance, but good stuff about how to get them to join us

Katie; we know anti-discrimination as anti-trust, so that is an important comment

Joerg: different dimension

…not 100 percent the same thing

…we work in field of certain monopolistic nature is natural

…we are asked to be non-discriminating

…if we have a partnership with YouTube

…then we should open same option to any other service as well

<Zakim> padler, you wanted to talk about large payer perspectives to encourage adoption…

IJ: we are non-discriminatory in that all these banks should be W3C members

Pat: about comment of paying workers in the field

…US Treasury is the largest payer

…if you encourage payer perspective, that could be interesting dynamic to add

…both payer and payee side

Katie: don’t make assumptions

IJ: Interesting comment on payroll

Pat: If people can receive payments using the standards that is a huge uptake

IJ: US Treasury is not expected to be here

…but good question is to ask who else should be in the room

Pat: Companies are using standard web tech to do B2B and B2C

…if you really want adoption, get to the wallets

Cyril: From my POV, we have seen that it’s not easy to make use cases and to implement them

…important to articulate existing systems

…Visa around table

…we have seen Apple work

…in Europe we have put a lot of money in transfer payment systems and ISO 20022

…what we have done here is not exactly compliant

…we know the details will be a nightmare and difficult to sell

…At Rabobank, I don’t feel that alone

…what we do may not be compliant, so normalization is important

…people who do normalization; ISO 20022 or other bodies

…and maybe some regulators

…it will be important

Katie: SWIFT will be here?

Cyril: yes

…biggest system we have

…one day we have to connect them

…there is always structure of data, developers can do that, but sometimes special results

Taylor: yes, echo Arie’s comment to engage financial institutions

<Zakim> jeff, you wanted to suggest that the conversation should be less about regulation and more about the web.

Jeff: Some comments about financial institution participation or regulation

…I will mention in my slides

…but not real focus of today’s discussion

…nothing we can do or fix for regulations

…not necessarily the dialogue we want

…On membership, it will just put too much pressure on them and on the meeting

…I think this needs to be positioned as, here is the web community, multi-stakeholder

…and we want to have a dialogue and this gives you a unique opportunity to talk to constituent elements

…and we have five panelists

…I’m not opposed to recruiting

…but it’s important that we ask every speaker to state their name and company names clearly

…and we can identify those who have most plausible interaction and follow up during cocktails

IJ: As moderator, I expect to reach out

…to people who are not part of the discussion

…so please feel free to speak

Jeff: If a question is not best for someone on panel, should ask those who are here today

Evert: In European arena, strong converging regulation

…the reason Rabobank joins this work

…is that we need proper tools to operate our business in this market

…to get to mobile payments…trying to get reliable tools to our customers is what worries me

IJ: Thank you for that impact

…Evan, do you want to come up now?

<Zakim> jeff, you wanted to riff on “what is a wallet”

<Ian> IJ: Ah, you have an indirection on how to read the rest

<stefan_thomas> @manu

<nicktr> The schema beneath Evan’s excellent demo appears ultimately to be coming from this very interesting initiative: http://www.heppnetz.de/projects/goodrelations/

<nicktr> I’ve not seen this before but it does look like an excellent starting point for a discussion

<Zakim> manu`, you wanted to say we will need a basic set of fields.

<Ian> scribenick: Ian

<Karen> Manu: I really appreciate the amount of focus that the payment request has, that is great

manu: I appreciate the amount of focus in the payment request

<scribe> scribenick: Karen

…having used JSON LD to do things experimentally, we are not going to get away with that

…When it comes to charter and vocab documents, we may need to define far more than this

…would be great if we can get away with this

Katie: explore more schemas?

Manu: We have a good relationship with Schema.org

…and JSON-LD was designed for payments

Evan: personal perspective is not to limit scope of charter, but add to what this might look like

<scribe> scribe: Manu


<Zakim> Ian, you wanted to ask if this is a charter refinement

<dbaron> Perhaps I should have been clearer about the ways in which I’m not happy with the charter

<Zakim> dezell, you wanted to recommend External Reviews TF to investigate how to represent ISO20022 in schema.org

<Zakim> jeff, you wanted to explain why the “kitchen sink” charter has challenges

<screen> [lunch]


<screen> … Review progress against goals, we did pretty well.

<screen> … Prioritize use cases

<screen> … Reviewed draft charter

<screen> Ian: 3 areas we looked at principally

<screen> … Most progress on payment architecture

<screen> … Timetable: IG consensus, W3C management support, propose to membership in August

<screen> … Group to form in Sept., meet at TPAC in October.

<screen> … 2d. Authentication. Wendy presented 2 proposed charters. we’ll see more

<screen> … 3d. Credentials. There’s more work to do.

<screen> … Security? main next thing will be around authentication.

<screen> … We still have security work to do in sending requirements to those other groups

<screen> dezell: Thanks to W3C staff

<screen> … next activities for the IG.

<screen> … Started thinking about what life in the IG will look like after launch of a new WG.

<screen> … DSR gave us some points to ponder.

<screen> … Finally, this roundtable.

<screen> Ian: Jeff will open with a brief presentation.

<screen> … followed by rich discussion.

<screen> … then drinks with Ripple at Le Cirque

<screen> dezell: Our next face-to-face meeting is TPAC in Sapporo, Japan. Registration is open now.

<screen> … AC willing, we’ll have a WG chartered too.

<screen> … Following F2F?

<screen> Ian: For f2fs, it helps to find a host

<screen> Claudia: The Fed would host

<screen> Adrian: Ripple Labs could host in South Africa

<screen> Magda: We should go back to our respective orgs

<screen> Ian: Are there any European orgs who’d like to host?

<screen> Juan Jiménez Zaballos: Spain?

<screen> Ian: We’ll decide asynchronously

<screen> dezell: Thanks to our host, Bloomberg.

<screen> [applause]

<screen> … thanks to Erik and the Bloomberg staff.

<screen> Next all-IG teleconf: 29 June (no meeting 22 June)

<screen> Ian: I’ll clean up the minutes, create a summary.

<Magda> *yay Ian*

<screen> Magda: What’s next with settlement?

<screen> Ian: Evan launched settlement TF at Feb F2F

<screen> … that discussion continues.

<screen> Stefan: We’re not trying to start a WG just yet. Working in CG

<screen> Erik: I’ll be talking to Ripple more.

<screen> dezell: Thanks W3C

<screen> … Thanks to everyone who shared presentations, talked, shared ideas.

<screen> [adjourned to further conversation]

Closing the Gaps
Native vs. HTML5?
The HTML5Apps project's goal is to close the gaps! Read more in the project's factsheet pdf file.
Project Funding
EU logo This project is funded by the European Union through the Seventh Framework Programme (FP7/2013-2015) under grant agreement n°611327 - HTML5 Apps.
February 2017
« Oct    
%d bloggers like this: