Web Payments Interest Group Meeting
26 Oct 2015

Introduction

Goals summary:

• Review and update the strategic plan of the Interest Group
• Reach consensus on the next standardization priority and develop a plan and timeline for the creation and socialization of a new Working Group Charter.

dezell: One year ago, we started this work - we have discussed a number of standards and work since then. We've worked on vision, roadmap, wallet, web payments WG charter.
... This is all very important work, very proud of this group and the work it's done
... We have a strategic sandwich for out agenda, where we are and how we did
... get perspectives from folks, then open discussion.
... So starting off w. strategic direction, security activity next steps, discussion from various stakeholders
... Then more topics, accessibility, automotive, capabilities "reset", ISO20022, interledger protocol, then open discussion across important things we've missed. We should also discuss missing organizations
... Ian will also discussion strategy pt. 2 after that, upcoming conferences to think about, etc.

Strategic Direction for the WPIG

Ian presentation on strategic vision.

ian: We have communication barriers - so speak loudly, slowly
... Ask questions on IRC, to raise a question - do "q+" - be inclusive.
... The channel for IRC is #wpay
... We have a strange seating arrangement, so, we're going to try to get through all of these challenges. Grab us if you have questions, we want everyone to get something out of the meeting.
... We are trying to answer the question - "What is the shared understanding of 'Why are we here?'"
... Let's look at what our charter says we should be doing - so this presentation is about that - analyze it.
... Then see what the industry thinks we should be doing. Given what we've heard and what we think is important at the end of day 2, we hope that we have consensus - another topic area for standardization.
... If people think the IG isn't doing the right things, let's correct that.
... For this presentation, let's look at our charter - are we doing what we're supposed to be doing?
... I created a rating system - very good to fair to poor. We also have not prioritized and premature ratings.
... The last two are non-judgmental - we need to understand whether we should change the priorities - what I'd like you to do during the presentation, as we go through slides - if you think there is something important there - make a note of it.
... so, let's start - slides linked from agenda. Agenda is in IRC channel.
... First, charter says you should get participants from various industry verticals. We have mobile operators, browser vendors, merchants, merchant associations, we don't have great direct user representation.
... there are more than 43 member organizations, 100+ people in the group, so we're doing well there.
... We had another thing where we had to participate in other W3C groups - this s a bit premature, we expect to participate more heavily in time.
... There are lots of groups - automotive, WoT, there will be groups for us to provide feedback to, but not yet.
... Industry engagement - we have a good rating here - we have ISO20022RA, we have a class D ISO liaison relationship now, we had a good interaction w/ NYC and conference participation.
... So, good engagement with industry, but we can do better. We may want to get C-level folks involved w/ industry participation - Web Payments IG owns vision, WG is doing specific piece, Security is doing another, even a higher strategic vision at industry level.
... Roadmap - we're doing fairly here.
... We did publish a vision, use cases, roadmap, and capabilities. roadmap is drafty and capabilities is stalled.
... We have a set of capabilities and when we're going to do - it was done in June, this is out of date, we need to update it.
... the IG sent to the membership, in April, on August 3rd we would send them a charter for review. That was never been done before. On Aug 5th we sent it - congrats to IG, that is good planning. We want to have a clear picture by end of week.
... It's fair because it's out of date.
... Capabilities - we're stalled - that's one of the things - whether it's priority for us, etc.
... Next up - deliverables in detail - we haven't done much there - ISO12812, ISO20022 - we've looked at them, IETF specs around credentials, it's not been a big thing that's part of the IG discussion.
... Identify future challenges for Web Payments - from technical, business, and legal perspectives - more than in other groups, attentive to business use cases.
... We did multistakeholder interviews - we're trying to pay particular attention to use cases
... Use cases, we're doing good there - that's ongoing - one way to think of IG meeting, update use cases document - are we talking about all use cases that we should be talking about. Updated use cases document - identify standards, where standards are needed to ease interaction.
... Identifying what standards are needed - we're doing really well there.
... Looking at invoices, digital receipts, warranty, coupons - not prioritized - terminology - evert did work on glossary, even in charter, we changed from glossary, more work needs to be done there.
... Identify role of digital wallet - we're doing fairly here - we decided to not do this yet, still differing views.
... Wallet and Wallet API - open framework for innovation in digital wallets - very good. For new payment instruments, not prioritized yet.
... We wanted to integrate all payment instruments, doing well there.
... Identify and review existing technical standards - poor - ISO20022 kept coming up, that's why we want to get these folks here.
... Tokenization - erik tokenization standards are proprietary - should we have open tokenization standards at W3C.

Erik: Yes, and EMVCo isn't here.

ian: Identify requirements for payment transaction messaging - not prioritized - we could change that, we want schemes to manage that. We're not dealing w/ UI questions. Identify requirements/constraints. Payment transaction messaging - not prioritized, but we do have an Interledger Payments CG.
... I think this is a piece of it ILP CG.
... PSD2 is the driver here.
... We haven't prioritized mobile - we've thought it should include mobile, but haven't pointed it out specifically.
... In June we talked about Credentials - we have new use case survey data that we're going to go over later today.
... There are some things that this group is not equipped to be doing - where we have requirements, that work should be done in Security activity.
... Erik has had a big push for security - I keep pushing that to Security Activity - that's where expertise is.
... Are they a part of security on the Web, or something else?
... identity providers - not prioritized, data protection, privacy, secure hardware, trusted UI, moving to next section of charter.
... Review/comments on other people's work - ISO12812, secure payments task force, not yet prioritized as a group effort.
... IG hasn't been sending official reviews - there is some interaction, not a formal group effort - Manu has mentioned Faster Payments Initiative will come out with an evaluation scheme for platforms - your platform can be seen as interesting if you satisfy those criteria.
... When these things become public, it could be something this group should look at. When it's public, I hope we can spend some time on it. I attended and asked when we could review it.
... Traditional payment methods, cryptocurrencies, we're not treating specially - they are supported.
... Newer front-end payment initiation messages - NFC and Bluetooth - other parts of W3C are going to work on input APIs. Alibaba has said that we should look at QRCodes, barcodes, etc. This group may say that the work should happen, but elsewhere.
... Loyalty points, coupons, not a part of our discussion.
... peer-to-peer payments, very interesting.
... flows - business to consumer flows - we're doing well there.

ian: I'm happy to have Japanese colleagues join us.
... We need more people from Asia-Pacific region.
... Payment Strategy Council - quarterly meet and look at trends, should it be done in IG?
... We've had a lot of effort going to start first WG - clearly push from management to get WG started, opportunity to shift our accent a bit - do more industry engagement, study, what is our next priority.
... What should our next deliverables be? Our Task Forces are not working now, what are we doing for the next six months - what other questions around payments are not covered - what have we not touched on at all.

Kepeng: What is the priority of the security WG - current priority is not too high.

Erik: Second that - it should be higher.

ian: Wendy will be covering that next.

<Ian> Judy; The AB will also talk about security integration into W3C groups

Judy: Want to add - we will talk w/ AB about integrating some of this work together - still trying to figure out how to do all this.

ian: Brad Hill will join WG meeting on Friday - two axes, WG agenda - what are we going to do - another big thread for WG meeting - how do we do all these things? Adrian and Nick have asked us how to talk about to do all this. Janina is going to talk about accessibility, DOM is talking about WebRTC about server-side stuff. Talking about API design, it should be an interesting look at how you put work together.

<Zakim> m4nu, you wanted to mention work load moving forward.

<Ian> m4nu: Good work on review of the work

<Ian> ...I want to discuss why we have not made progress in some areas.

<Ian> ...we have not enough people participating and workload on those who are is high.

<Ian> ...that was necessary to get the WG off the ground

<Ian> ...we could (1) get more people to participate and (2) make some prioritization decisions

<Ian> ...I think external reviews and capabilities were deprioritized due to lack of participation (and getting charter out)

<Ian> ...I would like to see new commitments from people to do work (e.g., 3 hours per week)

ian: One of the ways we put together the meeting - distribute the load - we had a nice breadth of participation.
... If you feel that there have been barriers to participation in the group, let's talk about that.
... We adjusted telecon time to make it easier to participate.

<Zakim> dezell, you wanted to talk about work shift

dezell: We do struggle under this a bit - there are a couple of good things coming here - creation of WG reduces the geek factor in IG - we can become more high-level big picture stuff - I see that improving.
... I know we have a couple of important merchants in the room - woefully underrepresented by merchants - we need more banks as well - getting these folks in is my highest priority. We want to make sure we're not victims of our own success.

ian: We have a bit of time to hear from you - areas that you think we should be spending time - topics in IG, increase the priority of - are there ways of working that would be superior.
... I don't know what pace will be at end of week.
... Not small number of people working on deliverables - other things to do.

Kepeng: Biometrics - is it a priority?
... For all of those authentication approaches - I think we're going to hear from Wendy on authentication side. If you think it's not covered, let us know.

Erik: Not just our roadmap, W3C's roadmap in general.

ian: The Roadmap for payments is our responsibility.
... If we do verifiable attributes/credentials - don't know where that would go - automotive stuff would go in automotive WG.
... We're saying "here's what you need to get payments done" - you need payments, identity, security - that's what the capabilities are about - roadmap is out of date, but we own it.

Erik: About participation - bringing banks in - how is the browser going to be used as a secure payments initiation mechanism.
... Roadmap needs to include more than just us - it needs to be more about more than IG.

ian: It's not about just IG - looking at roadmap diagram
... Capabilities document - simplified payments ecosystem document - we were going to organize web payments into blocks, security - build on that - other blocks.
... If we go back to roadmap - it takes those blocks and says who is going to work on them.
... We had green - web Payments WG - web authentication, hardware-bases security, digital signatures, credentials - web settlement - no plans for the latter items.
... capabilities document is a really important piece of communications - when we say payments, it's important to know what we mean. We had a drafty version of that - some talk about security charter in review - but that didn't happen for a variety of reasons - FIDO collaborating now with more organizations, we can talk about it more
... We need to have this roadmap - beyond just this IG.

ShaneM: What do you mean by "our"?

ian: We own the vision for Web Payments at W3C. If we are doing our job right, we try to tell the story, other WGs do the work. We want consensus around this.

<Zakim> padler, you wanted to talk about focus of the IG

padler: Talking a bit about capabilities - why is that important?
... When we started as IG last year - we had to focus on chartering first WG - put WG charter out - we took eyes off of bigger picture. As you look at capabilities - it's important to see number of different facets to payment. So, for biometric - what parts of authentication are needed for what players?
... There will be a good opportunity to break work apart, we don't want to do this sequentially.

<Zakim> dezell, you wanted to comment on getting steps in the use cases, and dropping things we can't work on.

dezell: Talking about biometrics, proximity payments - retailers and merchants priorities, we need to get these things into the use cases. We need them to be highly visible, group can get their hands around that at that point.
... Some things need to come out of charter - simplifying - we want to make sure we don't lose items. We need watch items, but would hate to see them vanish. Section 5 of deliverables had to identity, authentication, and security. Question whether we're the right group for that or not.

Katie: Another responsibility, communicate to make sure they're not feeling threatened and make sure they're interested in what we're doing. One of our responsibilities as an IG, we want to establish those responsibilities. Where you try to work with banks - not try to solve all problems - but find specific answers to their pain points, we may want to gain more traction to get them to the table with that approach.

Kepeng: About security work - we will define requirement, then security groups will define detailed solution. That's my understanding. How do we make this happen? How do we coordinate these groups together?

Erik: Would like to hear from Wendy about how all that works.
... How do you make the browser trusted?

padler: We create requirements here, other standards bodies implement stuff.

Judy: We're worried - we define use cases, requirements - for new companies, they don't know what detailed relationship between WGs IGs and CGs - who is talking to whom?
... We want to make sure that there is a closer relationship - one way to add something in charter of future security groups, add biometrics (for examples).
... Other way, add some examples in roadmap of how to do biometric security - we need to clarify how this will be done.

<Ian> (Ian notes that the Web Payments IG is not listed as a liaison in either of the authentication WG charters)

joerg: I'm Joerg from Deutsch Telekom - I'm seeing improvement.
... View on security here is problematic - I hear biometric payments - I think we need to keep authentication, authorization, and payment in different boxes. Payment initiatives that don't care about Web tech will start creating another silo.
... We need to be able to cope with this, just like we need to come where authentication/authorization happening elsewhere.
... I think the goal could be - if we can solve authentication problem, we can have a set of standardized authentication mechanisms available - transparent and standards-based. That is the stack we're working on.
... IG should definitely work on authentication / authorization for payments - what does that look like.

mountie: Similar issue related to biometrics - missing in discussion is Same Origin Policy - if we keep biometrics, that is browser-based, we have to consider how we handle same origin policy.
... User had some rights - they can do their act - you have to act discussion topic on Same Origin Policy.

ian: keep thinking about these things - I should pause and thank everyone for getting Web Payments group started.

dezell: We're trying to stay really visible - being activists in greater community/being visible is really important.

ian: Our charter expires in 10 months - we can do another round of work - then we should figure out if we want to recharter.
... Something to think about.

Security Roadmap

<Ian>Wendy Seltzer presentation on Security roadmap

wendy: In our roadmap for thinking about security at W3C - we've been thinking about what we work on in 3 areas. user security, web app security, web platform security.

Wendy: Crypto API is currently in CR - Web User Security.
... Some work doing HTTPS goes toward end user - helping users to having stronger protections is important work.
... Web Application Security - lots of work in WebAppSec WG. Few pieces in there, CSP - referrer policy, credential management, permissions API, WebAppSec WG - HTTPS support from Web-developer perspective, make deploying website easier to do so in a secure manner.
... Not getting insecure content injected - mixed content - upgrade insecure requests - help app developers make that transition. More of Web is HTTPS, good for everyone

<npdoty_> yay for privacy and security reviews, early and often

Wendy: Putting security/privacy considerations into specs, reviewing those for correctness and depth, don't add new feature to platform w/o having reasonable security profile.
... Sets better expectations for the Web Platform. We are doing liaison work with other organizations - a few of those - IETF, ICANN, domain registrar credentials, FIDO, automotive, etc.

Wendy: What are we planning more specifically - draft charters - pre AC reviews - drafts for discussion, improvement, those are web authentication and hardware-based security. Initial drafts for FIDO Attestation format and Signature format - going through their member review process - before they make their work public, they take it to member vote.
... That vote takes place in next weeks - give inputs, that's for multifactor authentication as core feature of web platform.
... second is around hardware-based security - interest from secure hardware smart card, secure elements, looking for initial drafts around which to start that work.
... We can look into charters in more detail - is there a queue?

<Ian> m4nu: Any more info on the FIDO Attestation format? I am wondering about relation to Credentials CG work there

<Ian> Laurent: I think there's a lot of overlap with what you want to do with identity credential format. The "attestation" is the credential. Their approach is more user-centric, whereas you wanted to do things more specific to payments

<Ian> m4nu: Actually, sounds like direct overlap

Wendy: The focus here is not on identifying individual visitors

Kepeng: There is something around signatures here - signing of the attestation - signing of operations on authentication tokens.

Wendy: Signature about operations -

Kepeng: Second question - biometric authentication - two WGs, one is authentication WG and another is hardware WG.

Wendy: Neither organization has biometrics as a core feature - if that's something of interest, then we should be looking to see if it fits into other areas - or if it is another area of work.

Erik: There is no proof that the token in the persons hand is still them. There is no way to bind token to user in offline format - breaks core need of financial services - KYC parties - FIDO is a good step in the right direction - out of scope - multi-origin credentials - keying material - without giving people access you can't bind to user in offline format? This sounds very FIDO centric.

<Laurent> +1 for Erik's remarks

<nick_s> can we get back on the queue, we seem to be wandering

joerg: Together, we should try to figure out what exactly FIDO is trying to do here.

Brad: FIDO will provide attestations of a device type - RP can understand local authentication support. It can support touch, fingerprints, enroll of fingerprint, same device/key attestation - device is tamper-proof, you can have full understanding of user continuity. Single wire crypto protocol - different levels of assurances.

<wseltzer> FIDO Alliance Overview

<Ian> Brad: You can as an institution treat device class; FIDO doesn't specific since requirements will differ in different contexts. So there's a standard way to get an attestation about a device type and also an attestation about key continuity. Overview of how UAF works: that's how protocol is architected. Biometrics are local to device, as an institution, you can trust a device class - get attestations of device class. Each bank/market/healthcare attestation certification are going to have different requirements - banks will have different requirements - corporate vs. personal. FIDO says how to get attestation on device type - attestation of key continuity - combine those two things to build level of assurance you need. You can build whatever level of assurance you want based on your needs from those 2 things: Non-clonability and physical presence is a good first step - instead of sending biometrics across network.

<schuki> +1

Keiji: I have been watching Web Payments and Security - current goal - web payment has different goal - transaction authentication, there should be some security design function within each group - that is my personal opinion.

Erik: Agree

<Ian> (Keiji thinks this IG should have some role in security requirements for other groups...that is my understanding of his comment)

AdrianHB: Comment on charter - in Payments WG charter - have use cases defined and having concrete work input to group - what's the process here? Are use cases and input there?

Wendy: The proposal here is to have FIDO as input.
... What does the web need to globalize those.
... We are expecting a Member submission;won't charter group until we have that

Mountie: For Web user security - is there any discussion on user environment being compromised - there is too much effort done for protecting the user environment. Some parties process in OS service - securing use environment - is there something more?

Wendy: There is a lot done at implementer level for user agents

<bhill2> fido links:

• Overview
• UAF Overview
• Security Reference

Mountie: Maybe implementer has important roles - if we have principles - big view of secure user environment - implementer will have more security in their user environment. Web application security can be handled by big orgs, but there are bits missing at the user security standpoint.
... If we talk about securing the user environment, that would be good.

Wendy: How do we give Web Access to secure execution environment. Provide security and access to HSM - how do we send Web content into a Trusted Execution Environment?

Ryladog: Secure communications for a device - couldn't our spec have some hook into biometric authentication.

ian: Our spec?

Katie: I'm talking about WG spec to allow the communication ... are we allowing for communication through Secure Element - we don't want to disallow that from working. That's one way of addressing biometrics through HSM. That's one way of doing it.

dezell: We have time at end of day for this topic - not a commentary on the charter - don't see Web Payments on there. We should figure that out

<Ian> (Question: Add liaison to WPIG from both charters?)

<Zakim> m4nu, you wanted to wonder if there is someone that understands the overlap in this room, or is directly involved in this work?

<keiji> The assignment of tasks to each group may have some strategic aspect. But we should aware that there may be some possibility requirements in this group may be different from other group. So we need to think about how to handle this difference.

<Ian> m4nu: Are there use cases that the FIDO group has or will submit with the submission?

<Ian> m4nu: Second question/ request I have.....has anybody else looked at the FIDO attestation specs?

<Ian> (Other than Laurent Castillo)

<Ian> (Also Axel has)

<Ian> M4nu: I saw multi-origin credentials out of scope for the proposed WG charter, but I've heard some FIDO people say that multi-origin stuff is possible)

<Ian> BradHill: In Version 1.0, all keys are origin-bound ...a device can have a cert..when you register a new key you can say it was generated inside a device of a given class ...how you much you trust those attestations depends on your own needs. So device class attestation follows origin-specific key

<Ian> m4nu: I heard attestations COULD become more free-form, but I am hearing from Brad based on his (past) participation that was not the case.

<Ian> BradHill: I suggest talking with jeff hodges and virginie galindo

<Ian> Erik: Let's also see what we need to REMOVE from the browser to make it more secure such as capabilities that provide access to DOM. Maybe we need to strip browsers to make them more trusted. See X9 documentation...they were talking about separation of merchant shopping (session) from payment execution (hoping). Before we start adding more capabilities in the browser - remove access to things that make it insecure - what's the minimum set of functionality that we need to execute payment. I documented that in security wiki - before we add hardware/auth - maybe we need to remove browser capabilities. X9 docs - US branch of ISO, they were talking about removing merchant shopping session from everything else.

ian: I think expectation in WG is that those are separated.

<Erik> https://www.w3.org/Payments/IG/wiki/Security_Issues

<Ian> [IJ has sent Erik extensive comments on that wiki....but they have not yet been taken into account.]

Wendy: Are you talking about a session, or a use of CSP to restrict where scripts can come from?

Erik: Small manifest to control what's loaded in browser, remove functionality in browser.

Kepeng: FIDO is an input document - some parts are missing from FIDO spec. Make reference to FIDO - define some missing parts.

Erik: This is a FIDO spec, not a payments spec. If that doesn't contain what you mean on payments - is that another module that should fit in a different spec. Is it universally needed, should it go in Web Authentication recommendation. Is it one charter, multiple charters, one charter w/ multiple REC-track documents.

ian: Where does that conversation happen?

Wendy: That can happen in the Web Payments IG - what do payments need - what is or is not present. Web Security IG - more general discussion of what security needs we have - open mailing list.

ian: If we were to get requirements in Web Payments IG, can we send them to them?

Wendy: That's unchaired - bring comments to me.

Bank stakeholder input

<Ian> Arie Levy-Cohen presentation on input from banks (and also narrative)

IG reached out to a group of around 30 banks

Got feedback from about 12

(Not a very big dataset)

Many of these companies came to june f2f so was valuable as a comms exercise too

One observation, the narrative from the feedback was not obvious

Ian: 3 groups of banks and interactions
... banks to banks, banks to customers and internal banking ops
....banks: faster settlement, open access
... bank to customer: onboarding, KYC, auth, payments, mobile, wallet definition, payment methods
... internal banking: security, trust btw apps, moving to the cloud
... Questions: Is it web related, will it lower costs, are there new business creation opps, does it improve quality?

kris: faster settlements - is it Web related? No.

ian: the act of settlement doesn't traditionally happen on the web

kris: settlement needs to happen soon after payment

ian: the interpretation is that (at a protocol layer) settlement doesn't happen on the Web

padler: to clarify, settlement does happen using web tech even if it is on closed networks

ian: what is the Web is an interesting discussion point.

ian: one def is that you use URI as identifiers
... another common def is the experience I have through my browser (usually Internet but also Intranet)
... a third def is: uses Web technologies
... this puts the use case on the W3C agenda (example: ePub)
... I mention this because it's useful in deciding what is in scope for us at W3C

padler: settlement fits all 3 defs
... just because some of it is more secure (less public) doesn't mean it shouldn't be in our scope

<Zakim> nick_s, you wanted to ask about account creation

nick_s: in the absence of ILP, would it not form part of a Web standard to on-board users to a new scheme? (if not supported by the payee)

ian: there are two things to handle: 1) data gathering and 2) KYC
... (hardening identity)

aylcw3c: in account creation, management and onboarding you could divide it up between a lot of divisions within a bank
... (i.e. it happens in every BU within all FIs)
... they all have concerns with some level of regulatory compliance
... KYC and AML apply to all
... security is also a key concern
... at many levels (and also regulated)
... the reason banks are unsure about how to respond to this is that each FI must gather and verify the data in their own way. There is no standard.
... banks recognize that improvements in onboarding would lower costs
... problem is that the requirements from different FIs will be different
... and banks don't consider KYC at another bank as sufficient to skip it themselves

<Zakim> m4nu, you wanted to mention that there is "on the Web today" and "will be on the Web"

m4nu: is it related to the Web is very interesting. Should be asked in two parts: today AND the future
... responses appear to be related to current situation
... many people believe that everything is shifting to the Web
... so a question we should also ask is when will this be done on the Web?
... getting this data from banks helps us prioritize?

aylcw3c: various FIs and people have very different opinions on this ... some think this will never happen on the Web (often leadership) and yet a few people down (example: security lead) will say he believe that the bulk of his resources will move onto the Internet. The commonality is that all see this happening faster (move to Web) if we can answer some questions around security (including ID and credentials)

dezell: Onboarding is clearly high priority but should not be our only topic for discussion

cyril: I do not agree with the matrix entirely
... internal and bank to bank are effectively closed loop

cyril: b2c needs to be divided in 2

<Ian> IJ: the bank-to-customer was designed to be the bilateral relations (not payments).

<Ian> Cyril: Let's move payments out (payment initiation)

cyril: we should separate payment, payment init etc from bilateral comms

ryladog: Are you talking about the banks process for establishing identity?

<Zakim> Ian, you wanted to talk about bank as identity provider

ian: we are talking about data gathering and verification?

ryladog: the data gathering def happens on the Web today

ian: Is there an opportunity for banks to act as identity providers?
... especially if we bring this closer to the Web

<aylcw3c> There would have to be a revenue rationale for banks to be Identity providers

<Erik> 1) I disagree with Blockchain as the technology for faster settlement. Identity and secure sharing of credentials will allow faster settlement by bringing their back-end functions to the Web

<Erik> 2) Paypal, Alibaba, etc are very successful because they have written their application around the insecurities of the browser.

<Erik> 3) I disagree that settlements will purely happen on the web, but I agree as Pat mentioned, that settlements will transition via open and closed loop networks (Open: Bitcoin, Closed: ACH)

<aylcw3c> +1

<Kepeng> +1

<Ryladog> +1 to Eric

<m4nu> +1

<Ian> Erik: Things will happen on both closed and open-loop systems ...how do we bring to the table

ian: there will be interesting intersections between payments and Web of Things

mountie: User Centric architecture of this IG has related to web on the view of mobile banking, will lower the costs and give new business opportunities

<Ian> Kepeng: Account creation includes two parts: (1) opening account from the web (2) bank can also create. The first part is most important...authenticating account creation over the web (e.g., authenticating id card)

jurgen: we should be more concerned with faster payments than faster settlement. the key is availability of funds for the receiver
... there are requirements that participants need to consider in settlement such as KYC etc which sometimes need to be done prior to inter-bank settlement

ian: how does the group feel about the format of this stakeholder feedback?

<aylcw3c> Enjoy Japan everyone~! Cheerio~!!!

Building trust for P2P transactions

SCAI presentation from Cyril Vignet (Bringing 4-corner to the Web)

"My tribe" solution - networking trust parties

(Slide 8: Workflow)

Cyril: Authentication needs can vary by tribe needs
... transaction and authentication are separable

(Slide 12: Benefits of "SCAI" proposal)

Cyril: Can easily tokenize data if tribes deem necessary

<Zakim> m4nu, you wanted to ask about whether or not this work is supportive/competitive with the ILP work?

m4nu: It seems to me the proposal is mostly about message encapsulation and counter-signatures, so that you end up with a record of how the message flowed through the system.

Cyril: It's primarily about "consent to pay"
... ....all actors know whether there is consent, or where it stopped
... there is a record of consent all along the way
... we have documentation of "consent to pay"

M4nu: Is this part of messaging to happen in WPWG?
... or a heads-up to the group that these are parallel ideas?

Cyril: Part of this concept was raised because of discussion around use cases, also P2P issues around PSD2
... could be interested for messaging, but also relates to inter ledger protocol

m4nu: The structure that you have here is highly compatible with the structure of the credentials WG
... interesting to see it coming from a different place

Erik: Regarding slide 12 "except for secret data"...payments is about transparency except for sensitive information...you could also add regulatory bits on slide 12

Kepeng: You mentioned centralized org for p2p payments
... do you mean the bank or the PSP or the government?

Cyril: I am not proposing a single trusted intermediary
... that was just to show that other models are better. :)

jheuer: I wanted to focus somewhat on semantics
... if you just have the means to do things in a secure way with crypto doesn't mean things get better
... processes and jurisdictions are different
... so institutions may not be able to rely on data unless the semantics are transported
... the risk and responsibility interfaces could somehow work together
... business model is that some parties could act as bridges

Cyril: I agree, the SCAI layer I talk about is "underneath"
... if we deal with payments in Europe under 20 EUR, then you have one level of verification
... if you have large payments you need another
... but in the end, there is a way to transmit that, whatever the needs

jheuer: Let's not stop transactions, but enable them with different business models

IJ: Look for different stakeholders saying similar things over these few days to find common interests (e.g., Cyril + ILP)

AdrianHB: Also, this presentation suggests some things for the WG as well
... different risk profiles for same flow.

Mobile operator perspectives

Natasha Rooney Presentation on Mobile Needs

Natasha: We shared that info internally with GSMA
... and we have some updates from GSMA

[Remote payments]

(slide 5)

Natasha: When discussing this internally at GSMA...trying to figure out where operator fits within chain of payments is difficult.
... some operators do this successfully
... but finding out exactly where operators fit into this chain was difficult
... I think moving away from being part of remote payments and more providing an authentication role

(slide 6)

One-click checkout

scribe: they want to be part of the in-store one-click payment via mobile devices
... one of the most recognized issues is that "regulation makes this globally impossible" (e.g., in some jurisdiction, 2 clicks minimum are required)
... investigations on this reveal some operators are moving away to this ; we are not seeing universally even if some operators are still doing within a given country

(slide 7)

Natasha: Operators may be generally moving away from value-added services, but some are still doing
... On the other hand, big demand for carrier billing
... 1-click payment came up in this context
... because 1-click is not universally interoperable, carrier billing is not as widely adopted as it could be...but many developers are asking about this
... There are also some operators who have app stores; but not so much in Europe
... Shifting now to topic of operators as authentication service providers....some movement in this direction
... Identity and authentication have existed separately in GSMA for a long time
... identity and payments that is; they are starting to hold hands increasingly
... I think transaction authentication is one clear area
... generally speaking we think all payments will become remote payments
... even if physically in store
... online fees are high today but tokenization might help. We want to see whether interchange fees can drop based on increased authentication up front

Natasha: Needs we've identified: tokenization, attribute checking, anonymity of payer. For more information about relevant identity standards, see OpenID, FIDO, IETF

Natashs: SIM can be used, but tokenization is preferred
... depends on operator and their preferred solution

(Slide 11)

TSM, TEE, Hardware elements. TSM is not as popular with mobile operators right now. As far as hardware element, operators generally have support of SIM or other things ... GSMA will participate in the future W3C authentication WGs (in particular the hardware one)

Natasha: Some observations that Apple/Google/Samsung approach to payments seemingly gaining traction

Cyril: In Europe, the online interchange fees are lower (re: slide 9) due to regulation
... so depends on the country

Erik: I want to stress the importance of slide 9. Mobile device for multi-factor authentication for Web payments
... one question I have on 1-click and 2-click
... can you provide some documentation?

Nick: We call it the TSM
... when you say "TSM is less popular" it depends on perspective...in raw numbers we have a lot; TSM quite popular

(Realities and conclusions slide)

• Users will continue to want to pay with different forms of payment (credit card, bank transfer, pre-payment, pay by bill, etc.)
• Cash transaction will decrease
• User will want to pay with a variety of devices (not just mobile phones)
• People will want different identities for different purposes
  ... e.g., different identity for logging into a site. v. how I pay

(Conclusions slide)

Natasha: Tokenization seems quite important (whether or not operators are involved another question)
... handsets /user devices will be instrumental in "challenges" (in the authentication sense)
... regarding Requirements for the Web. Some include:

• Token sending/storing/receiving (but have security issues)
• Supporting FIDO-style challenges
• Enforcing HTTPs
• Simplifying payment provider and merchant onboarding and user enrollment

scribe: The last one is important for getting ubiquitous payments
... this IG could produce guidelines documents ... or regulation guidelines
... I would like to hear from mobile operators in the room on these comments
... and any other additions to the notes

<AdrianHB> Ian: you started to broach the topic, wrt to carrier billing as example, that API's were needed etc. Would standards for account access be useful?

<AdrianHB> Natasha: it would be difficult for an operator to share account details over the Web.

IJ: Would it be possible to bring operator billing into web apps?

Natasha: Some operators have existing APIs....and there are backwards compatibility issues
... my big question mark is ... a mobile operator could release APIs themselves to have direct relationships with developers....

Cyril: Operators may prefer to dominate a local market

Pat recaps Ian point: if merchants can take billing from any operator, then lower cost for operators to be connected

Erik: Please add "authorization" to the slide.
... phones are good at identifying users, but also need to integrate authorization
... this way you absolve the financial institution of liability
... mobile operators can help on that front
... mobile apps doing that already

AdrianHB: that's what Mobile Connect does

Erik: One thing you are missing - identity assurance

Natasha: Yes, that's the point about lowering interchange fees

jheuer: Payments secure element could sit on SIM card or elsewhere
... could enable provisioning during life of SIM card.
... how to use secure element is basically part of the discussion at the Global Platform standardization
... Attribute provisioning definitely belongs on the list here as a potential service from the operator

Kepeng: On the wiki page, what are the requirements to keep identity anonymous? What are the proposed solutions?

Natasha: Standard OpenID connect flow
...example: I can log in with my OpenID Connect info, and that limits what the merchant sees
... so it may not be strictly anonymous but it's a small amount of information about you, and you've authorized it, and they won't have seen your mobile phone number

Natasha: Mobile phone numbers are not widely used as identifiers
... Operator COULD offer you as a user to authorize the session of your identity to the site
... even geolocation

<Zakim> ShaneM, you wanted to ask why mobile wouldn't just be another payment instrument?

Jheuer: ....the important thing is to keep them separate by design

ShaneM: Regarding Ian's question...did you mean "do you want to make it easier for carrier billing to be just another payment instrument"?

Ian: Yes, that is what I meant but I started talking about account access...I like your summary better.

ShaneM: I agree then that's an interesting question - would that be interesting?

Natasha: Yes

AdrianHB: In my experience, part of the problem is that mobile operators and banks compete for customers
... e.g., that's why NFC did not take up - people could not decide who owns the customer
... carrier billing is another example where the mobile operators (IMO) want too much out of the deal...it's more expensive by orders of magnitude than for cards.
... I wonder what's going to change for mobile operators to suddenly be a payment instrument...would carrier billing suddenly become competitive with other instruments? I think a lot would have to change on the operator side

Natasha: I wanted to focus on identity and authentication rather than payments, in part for that reason. I agree with your point on NFC and there are other topics like that. I do see some changes in GSMA happening, however.

AdrianHB: If PSD2 mandates in EU that banks have to provide access to accounts, and operators treat pre-paid accounts like bank accounts, how long will it be until it's regulated.

Nick-as-devil's-advocate: Carriers have not gotten a lot of traction in the payment space. It makes sense to concentrate on identity and authorization
... other companies like google are getting involved
... are operators being pushed out?
... e.g,., when you buy an iPad the SIM card is Apple's not the mobile operators

Natasha: Good question ... I hear two:
... I think that there are some big company issues that are blockages

IJ: I am hearing mostly "identity and authentication:"

Natasha: You would be right to hear that.

Merchant / Ecommerce perspectives

David Ezell Ecommerce Needs Presentation

DavidE: Consumers don't want to have to load another app (just to use a credit card)
... Focus of merchant priority is serving the customer....just having another way to use a credit card is not enough from the merchant perspective to do something new/different.

(Slide 4)

DavidE: People want to know "what the best deal" is.
... Also, taxability is a big deal (and may vary based on payment method)
... one use case that is important in the US for merchants is the use of "food stamps" (called SNAP in the US)
... you also want to be able COMBINE payment instruments
... the killer app tells people how to get the best deal.

(Slide 7)

scribe: in the US there was an Amoco card back in the old days; with loyalty benefits
... Retailers banded together to find a way to accept payment to keep customers loyal to the brand...
... they are still doing that.

(Slide 8)

scribe: example of Flash Foods (a southern US store chain with ~150 stores)
... rewards are very important to them. This company made up for loyalty offering by implementing their own ACH
... this pattern of rolling your own payment network to do loyalty is pervasive.

<Erik> Dave: One thing you are missing from slide 5 (What merchants are thinking…): Merchants love and hoard user data

scribe: In 2014 Flash Foods created an app for competitive fuel pricing
... but it only works for Flash Foods, and it's yet another app to download
... so what I think we should be doing is meeting the retailer need (so they don't have to all create apps)
... merchants need promotions for all those things (taking the form of coupons or loyalty points)
... low risk cash vouchers (a new model for coupons)
... in my mind, the digital wallet has got to be able to do is make sense of this chaos
... there are all these ways to do these things and the customers want to know "what's the best deal" and the merchant wants loyalty
... inserting payment service providers has complicated the landscape...they too want to gain customer loyalty
... and Amex, for example, now lets you pay with points
... how does 'paying with points' fit into our picture?
... every major card brand is preparing to enable paying with points as well

(slide 9)

scribe: we need to be able to answer in our flows questions like:
... can it be applied to this purchase?
... can it be combined with other instruments, etc.

Cyril: When you are talking about Go Blue, is there direct debit at the end of the payment process

DavidE: Yes

KevinF: Target does the same thing...you can get a Target debit card..ACH's from your account...they give you 5% on everything in exchange for the value you give them by sharing data with them.

Erik: Merchants love data.

nick_s: Why do you think private label store cards are popular in the US?

DavidE: ACH popularity in US; may not be the reason elsewhere
... the #2 cost at stores is INTERCHANGE....#3 is people

AdrianHB: You mentioned what's in and out of scope for the WPWG....in the instance of store cards, where the store provides the payment instrument, that should be within scope for the WG

<nick_s> +1, I think we really mean Value Added Services are out of the initial scope

AdrianHB: the challenge would be if loyalty/coupons fits into the flow elsewhere
... what would not fit in easily is when you pay with an instrument that happens to be a loyalty card, and that would affect the flow.
... The merchant runs the site...if it's their own proprietary scheme they can advertise it..and if the payer has that instrument they can pay...closed loop will work with the WG scope
... but complex loyalty will be harder to solve.
... either you put it in the flow so that you pre-calculate (and it would fit in our flow) or there is more back and forth (and that would be harder to fit into our intended flow)
... however the alternative is that we come up with rulesets...
... and the payment instrument does the calculations

NickTR: No

Kevin: That won't work since there are also personalized promotions (e.g., starbucks 10% off in the next hour)

AdrianHB: I think we are going to knock a number of use cases on the head already in the WPWG
... I think if we were to allow a combination of payment instruments we could knock off even more
... don't despair!

<Zakim> ShaneM, you wanted to ask about interchange fees and private label cards

ShaneM: There's a unique situation that you've described where there are private-label instruments v. global instruments
... they have different interchange fees
... as a merchant I know I can't pass on that fee explicitly to my customer (per my agreement with the card company)
... can I say to the customer that my retail card is a better deal?

DavidE: There are ways to finesse it
... but it's a valid point
... If you are taking coupons and food stamps you need to know what's in the transaction, but if you know what's in the transaction you may be violating the credit card agreement

Laurent: I think on slide 9 there are a lot of things that can be pre-computed

DavidE: We have in our use cases a discovery of offer...there is a natural place where this could go, we just need to make sure we cover it

Laurent: I see a problem of incompatibility between requirements: (1) merchant needs access to your list of payment instruments to offer you promotions (2) for privacy you don't want to share that info

DavidE: Where did you infer the first?
... I didn't mean to imply that
... rather it's the wallet, not the merchant, making this determination

IJ: I am hearing consensus that it's a user side thing in any case; whether or not it's easily do-able

<Zakim> nicktr, you wanted to say that PSD2 changes this in Europe

nicktr: PSD2 changes in Europe...merchants WILL be able to surcharge....they don't have to honor all payment instruments
... once upon a time you could not expose how the pricing was done...but that's changing
... you'll be able to say as a merchant "I'll take card X but add N%"

Adrian: That's not regulation, that's in contracts

Nicktr: But regulation will say those are not enforceable clauses

Manu: I think that's changing in the US as well
... there was a lawsuit

jheuer: I want to reinforce the finding that we need to have some instant where the interest of the user is handled
... when we implemented our mobile wallet, we contacted MasterCard and other companies and they said they would not allow us the mobile operator to provide anything like a receipt
... the claim was it was a privacy issue
... because the user wants to see it
... so it became a non-issue...I think it will be the same for other information
... today people may not want to send data but we know that users will be interested

jurgen: I think independent of PSD2 it's already possible to do surcharges etc....

scribe: that's because payment schemes push liability back onto merchants in many cases
... and it's going to get increasingly painful for merchants

DavidE: Merchant hot topics: they want to:

• reduce cost
• improve security
• reduce liability
• increase connection to customer

DavidE: Merchants mostly save money by moving to ACH

(slide 13 security)

<nick_s> I am very wary of merchants “needing” to know who is transacting with them. “Want to know” would be more accurate.

(+1 to Nick_S)

(Slide 17 changes to use cases)

• treat loyalty / coupons as first class payment instruments
• support multiple instruments per transaction
• quid pro quo with customer to gain benefits by exposing more data to merchant
• also need a standard to match "products" to payment instruments

scribe: and have enough information so that SOMEONE can compute "best deal"

(See slide 18 for specific use case changes)

IJ: What does "taxes" mean?

DavidE: Certain choices may give customer financial benefits due to taxes / no taxes

dsr: there's an opportunity for value-added services to access these details
... e.g., people are confused by too many options or may wish to save points
... the services should have "rich access" to data
... but would not provide the data back to the merchants
... there's an opportunity here to encourage innovation around services based upon low level APIs that facilitate innovation around valued added services with rich access to personal habits

DavidE: I see a rich wallet market

Manu: You can look at coupon / loyalty card as a payment instrument, or also as a credential that you apply at the point of sale.
... one way to think of it is that "all these things are payment instruments" another is "credentials will affect the offer, but in the end the transaction is carried out by a 'real' payment instrument")

Kevin: I think it's BOTH
... I think some loyalty cards are credentials and some are payment instruments....

nick_s: Thanks for the interesting presentation
... I like the idea of wallets determining the best deal; I think we should pursue that
... even if some may not like it (e.g., an app that plays retailers off against one another)....so good idea in theory but may be difficult in practice
... I think that merchants don't NEED loyalty information; I would say that they WANT it.
... I think that giving data should be an opt-in process
... I'm sure there's a middle ground somewhere

Erik: You need to opt-in to share information

nicktr: In the WG meeting on Friday we have a discussion on deployment issues
... great topic is whether what we design and whether it will be unattractive to some parties like merchants if it takes away too much data.

Kepeng: On slide 14....you mention "the merchant needs to know who is interacting with them"
... why is this a requirement since it's true by default?

DavidE: Some proposed payment instruments give zero information to merchants....merchants are reacting to that

ShaneM: I think this is about brick-and-mortar transactions...they want to know who you are

Kris: You pay in cash...they don't need to know who you are

AdrianHB: it's important the WG fits into the whole commercial flow....the WPWG work is at the end
... the merchant should know who you are because that happened earlier in the flow

DavidE: How do we make sure that the brick-and-mortar case is a first class case?

AdrianHB: Online, my site should encourage users to log in....I should get user to interact with me ...and merchant needs to decide how hard to push or lose the sale.
... I think it's important to be clear that we are not cutting out merchants; check out can be the same as before.

DavidE: In the brick and mortar case where you have a push payment scenario...in that situation, the merchant knows nothing.

Kevin: that's true today...they may want information moving forward that they don't have today

DavidE: They want security without losing data

AdrianHB: We are creating a platform with choice...for both merchants and users
... you'll have a spectrum of payment methods
... it's about the relationship between merchant and PSP
... if we are successful, it's easier for either side to make choices

jheuer: In the brick and mortar scenario....loyalty cards already there
... gives transparency to user...
... I'd like to see that solution in the online world as well
... I could use a loyalty card online
... and that would have all the information the merchant needs...it could be regulated (even regionally)

<ShaneM> Don't forget that there MUST be a way for the merchant to recall your purchases using your payment instrument. So that the consumer can have an easy return / exchange experience at a brick and mortar without a receipt.

jheuer: I think it's a very user-centric approach
... and it should be even easier to get adopted since you don't need physical card; it's just data

BradHill: We talk about the wallet metaphor a lot...it's also useful to think about the "user agent"
... it's useful to think about competition among browsers
... think of where it plays in the protocols

padler: We've talked about using points to pay
... what strikes me in the question of privacy v. returning customer
... perhaps we should talk about how the loyalty data is provisioned for merchants
... if that were standardized (e.g., provisioning a particular kind of key to a wallet)
... that would help a lot...you are not giving away personal data but the merchant still gets "this is the same user"

Katie: Deidentifying

Manu: Mark Nottingham made a point before leaving the room...the HTML5 spec talks about a prioritization of constituencies
... it helps make difficult decisions
... seems like something this group should do

Payment Service provider perspectives

Zephyr presentation on Payment Service Provider Perspectives

(Part I: China internet finance)

Zephyr: Internet brings us: big data, cloud computing, internet risk control, credit system
... Development of internet finance in China has led to more crime; but internet risk control can help
... Alipay functions
... Alipay lets you visualize a lot of information about your payments
... all data from the cloud services

(Part II of the presentation - PSP requirements)

scribe: we think that standards can help improve:

• security
• help fulfill governance

scribe: PSPs need: purchase information, payment security, and mobile payments

scribe: in China QR code is important to encode payment information
... used in restaurants, hotels, etc.
... there are potential problems with QR codes....
... also need more standards around authentication

<scribe> ...new authentication include biometrics

UNKNOWN_SPEAKER: Alipay does face and fingerprint recognition....
... not yet iris authentication
... biometrics are more secure and convenient, but they also have issues and are new technology
... for example, how to increase accuracy of face recognition, but also stolen biometric data

Lastly, mobile payment is important to PSPs

(Part III presentation)

some topics for discussion:

• purchase information (barcode)
• Security (biometrics, etc.)
• mobile
• user experience

Nicktr: One of the interesting things from PSP perspective is around simplifying the interface between merchants and consumers
... the challenge will be how to convince PSPs to start supporting it
... is that a sufficient benefit to them

<Zakim> nick_s, you wanted to ask for more background about usage of barcodes in China

nick_s: I have a China question. You mentioned that bar codes are an important use case in China. Why is that?

Zephyr: It's very convenient...use app
... you can complete payment for small amounts without password, biometrics

Mountie: What size QR code?

Zephyr: < 1K

Kepeng: One use case is to use QR code to pay. Another one is to display the offer via a QR code.
... I scan the bar code offer then pay

Judy; We should focus on user needs. In China airports, restaurants, a lot is done around bar codes

<ShaneM> See the QR code in China article

scribe: in addition to convenience we think it's also security

<Zakim> m4nu, you wanted to wonder if there is a list of "top things we'd like to see"

<CyrilV> additional info on barcode. https://ants.gouv.fr/Les-solutions/2D-Doc is a standard to signed barcode and to enable static authentication

m4nu: Is there a list of "top priorities" from PSPs?

IJ: We didn't get there yet.
... We didn't get there....we need to do more

M4nu: PSPs seem reluctant to adopt the WPWG work

<nick_s> ultimately are merchants not customers of PSPs? if the merchants push for WPWG adoption PSPs may well follow?

<Zakim> AdrianHB, you wanted to ask if NFC, QR codes etc are in scope for the IG as input to the WG flow

IJ: we have more work to do on both fronts (1) value proposition of WPWG work and (2) what PSPs want

AdrianHB: Here's my view on bar codes and NFC...
... in my mind these are means to transfer data
... these are parts of the flow (before payment)
... I feel like we need to figure out use cases for where these fit in
... and today we heard that one is an authorization use case and one is an offer display use cases
... and we should think of the Community Groups that are working on these as data input methods

<padler> +1 to the description of the data exchange...

Erik: We've heard some issues around NFC (due to interference issues)

<nick_s> I am extremely dubious of the claims a grocery cart amplifies NFC

Erik: also, time in checkout line increases cost to merchant

<Erik> Erik: 2 lessons from Walmart (Utrecht Netherlands F2F?)

katie: Biometric time requirements vary

<Erik> Erik: 1) Shopping carts became NFC antenna and users paid for things that weren't their own

<Erik> Erik: 2) An additional 1 second at a checkout line costs $12,000,000 year.

<nick_s> I think point 2) is only true when you’re not using EMV

Kris: How does Alipay work with respect to other global cards
... how does payment flow work?

Judy: You can associate a credit card with your Alipay account but Alipay also does banking functions
... we have something like a virtual bank coming up
... also we need to satisfy Chinese banking regulation
... We should discuss Chinese use cases, e.g., Alipay account can make it easier to get a travel visa
... let's keep talking about user perspective
... Another interop challenge is reading fingerprints on a variety of devices

AdrianHB: A comment with respect to the WG
... in a scenario where you authenticate with biometrics or you use a QR code, that will still be possible, but will be up to the payment scheme
... the intention with the WPWG is too just standardize the flow
... you can implement what you want in the scheme.

Credentials

Manu Sporny presentation on Credentials Use Cases

Manu: Question is whether credentials are necessary for payment process.
... in June we said for basic payment case, credentials were not critical path
... but they continue to come up, as use cases from today have illustrated. So we did a survey (see anonymized data) We had 44 orgs respond ... payments, education, healthcare, government

(Use case themes)

• simplify checkout (easier provision of data)
• easier enrollment (KYC)
• automatic compliance
• ensure proper licensure and training

(Credential capabilities)

Manu: Mostly deemed important; least important was about storage

(Existing technologies, slide 7)

Manu: the formats used the most are: Email, PDF, x.509
... it's all manual; there's no automation
... some people concluded that existing technologies are not sufficient to meet their use cases completely
... Lots of interest in participation

Manu questions:

• are there use cases we need to document?
• would we have a workshop?
• should Web Payments IG drive the discussion?

DavidE: Is my Visa card a credential?

Manu: I don't think there's consensus today on that.

IJ: I don't think it needs to be mutually exclusive.

<nicktr> IMO the PAN is a credential

AdrianHB: Based on proposal on the table, payment instruments are credentials that have business logic

Mountie: How do you see identification being handled in your view of credentials?
... Also a technical question on use of JSON-LD

Manu: The use cases we are talking about here are not about authentication
... FIDO does a better job at user authentication
... the credentials work we are talking about here are signed claims
... Your use case was a prescription written for your Mom and you pick it up.
... that's a great use case, but we're not yet at the point of discussing it in detail.
... the question today is whether we should start a group (E.g., Interest Group) to hold those discussions.
... the Credentials Community Group has some work you can look at.

<gjaya> We could call it third-party transaction (buying on behalf of someone else).. can apply to loyalty points. ex: I send my son to get some milk. He buys on behalf of the family

Manu: the question here is whether Credentials should advance in an IG, in this IG, elsewhere?

Laurent: We should add a payment use case - unlocking the payment instrument by verified credentials.
... can I use a credential to unlock my account to allow a payment request to go through.
... You listed 10 different identity standards...the first question an IG should answer is "What value do we bring compared to the previous work? Why can't we use them to solve our issues?
... my concern about doing credentials work is that it solves some issues but not all of them
... another solution is to create a credentials standard that is specific to the web payments work.
... but I"m not really in favor of that idea.

AdrianHB: My question ties to Laurent's - if we were to form a WG, where would we draw the line for scope.
... my proposal would be to define a specific WG for defining a way to exchange credentials and stop there.
... a "credentialing format" as a start and evolve from there.

Laurent: SAML is an attestation format

AdrianHB: We have not answered the question why is SAML not used widely on the web
... my assumption is that it's complex and not extensible.

Erik: A lot of the technologies that are already shown are deeply embedded in backend systems
... while I do support credentials I don't agree with the current direction on the floor.
... but I think we need SOMETHING..e.g., for faster payments
... why not extend some existing format rather than writing from scratch

Manu: First question is to see whether we are willing to write a charter....that comes before the question of whether people would get involved, or whether we want to push to W3M

DavidE: I am most interested in working on credentials if payment instruments are considered credentials

nicktr: When we were in New York, the banks clearly said "we need identity"
... if writing a draft charter is the way to flesh out the gaps, then that's fine.
... but I'm nervous about coming up with a competitor to existing protocols
... I think we are better off identifying use cases and looking to adjust existing formats

bradhill: The survey asked people what they want.
... it did not get into the details about difficulties and pain points of existing solutions
... and why is the answer to the difficulties creating a new format.
... the challenge is not creating attributes, it's about trust.
... you may not know my major and the major has another name at another university

<Laurent> +1 to the issue being trust in the credential

bradhill: how do I trust attributes from a university in another country
... the difficulties are not exchanging attributes, it's the cost of establishing meaning and trust
... adding another one to the pile that does not address those challenges will not help us

jheuer: I am glad to hear what I heard today: loyalty and identity and coupons belong to payments....
... I also heard people say payment cards are credentials
... I think credentials need to be more abstract...that would be different from the existing formats
... I think a more abstract spec would be different from what exists...it might, for example, offer dynamic verification service
... I would welcome this work in this IG

KevinFleming: The use case we provided was mischaracterized - not related to payments
... when I was discussing this with security architecture....his observation was that existing technologies are complex to use
... I asked about a w3c effort and the answer was "API in browser" so that Web developers don't need to deal with it.
... the person writing the app doesn't have to deal with details.
... so that aligns with joerg's view of abstraction
... the browser helps communicate credentials and trust relationships are determined separately
... so I would not do this work in this IG since use cases go beyond payments

Kepeng: How would a credentials IG relate to credentials CG?
... and what is relation to API from WebAppSec?

Manu: If there were a credentials IG, it would be like Web payments CG/IG where the IG takes input from the CG.
... but we don't know if we will end up in that.
... Regarding the webappsec API....we've been in communication with that group.

(specifically, the Credentials CG has been in touch with them)

Manu: We are looking for compatibility with the work of that group

padler: Credentials in this context are about attributes, not authentication
... it makes sense to me that identity and credentials are independent of other aspects of payments
... This IG's name includes things that go beyond payments (go into trust, identity, etc.)
... we might consider renaming this group as a "Commerce IG " or "Web Economy IG" that could include credentials

dsr: I think a use cases IG is a better fit (for use cases) than a WG, and should coordinate with external groups, e.g. at the IETF, to ensure that they are on the same page

Manu: I think that the safest thing to do at this point would be to create a short-lived IG to clarify questions raised here (and elsewhere)
... and after 3-6 months of work on use cases, would be straightforward to launch a WG

<Zakim> AdrianHB, you wanted to mention Credentials API and to also ask what it is we are looking for? Is it time to write a charter? If so, is that for an IG or WG?

<jheuer> if we are being ambitious enough to co-ordinate efforts across different working groups and even bodies, I revoke my statement for credentials being addressed in the payment IG only - let it just start here

AdrianHB: Credentials CG looking beyond browser storage
... question is "what do we want from the IG now?"
... If we go with seems to be a consensus that this is "IG not WG" we will be in same situation as with security where we do not control our own destiny

Laurent: My remark is similar to Adrian's....rather than create a credentials IG we will burn 2 years

scribe: instead, we should restrict the identity and credentials use cases to payments use cases
... and then do them in the payments IG...and then when we have a new charter, we launch a new WG

<kris> +1

scribe: if you a credentialing system that is extensible enough for payments industry, could also prove to be extensible to other industries

<AdrianHB> ian: it seems we are moving to a point where we are talking about building blocks for a system where browsers store data for users (credentials)

<AdrianHB> Ian: it's harder to imagine this technology outside the browser (not that it's impossible but harder to "visualise") so strategically we could focus on the browser as a means of differentiating this work from previous

Daniel: Credentials make sense to me for addressing identity issues
... there are clearly many use cases outside of payments
... point taken about taking too long...need to be sure to reduce scope
... specifically with respect to credentials, I would be wary to artificially hobble credentials in order to satisfy a short-term payment need
... the credentials need to satisfy payments use cases...but saying it must satisfy those and cannot satisfy others...that would be overly restrictive
... and in practice, we are likely to see that credentials are more broadly applicable and others will show up and participate and it will happen anyway
... I think it's better to create a separate IG but put requirements on the IG to satisfy the payments use cases "as a first citizen"
... but don't prevent such an IG from addressing other use cases
... an example is WebRTC, which is providing to address additional use cases
... so a separate IG makes sense to me, taking requirements from this IG

Viriginie: I think that the web platform is developing a lot these days
... this problem is not new...
... Gemalto would like to have results as quickly as possible.
... so I think we will have to have a clear priority list on the features that we want to develop
... Clear dependencies and priorities are important to get work done in a timely fashion

Jeff_: I heard Manu say that they've identified a need to work on credentials. Probably the next activity for the next 3-6 months would be to crisp up what the real need is, and position it with respect to other work
... and one of your key questions was "where to do that work" (in the credentials CG, in the payments IG in a task force, etc.)
... echoing Laurent's comment, it seems like the worst fit is to do it in a separate credentials IG>
... you want to do something in 3-6 months, but there's high overhead to start a credentials IG.
... as Ian said, it could be logical to have a task force in the IG but priority needs to be determined.
... it's also not unreasonable to launch a new CG...this would be focused on use cases and "what's necessary" (whereas the credentials CG is working on technology)

bhill2: The work of the CG distinguished by the browser role. The first question is "are they interesting?"
... getting more affirmative expression of interest from browser vendors is a better first step. The browser vendors are aware of cost and difficulties of doing these things.
... putting an API in a web browser is something you can feature test.
... but crypto protocols need to be inflexible and versioned
... if you had to deprecate something like certs or TLS, it would be a 6-year project for FB to get all browsers updated
... you can't deal with a 6-year upgrade cycle for something related to crypto around payments
... this is a hidden difficulty when you get the browser involved - getting large-scale updates

Erik: Why is W3C relevant for a data exchange format from one bank to another?
... but W3C coming up for right APIs for browser that makes sense

<nick_s> …because credentials aren’t just used to exchange between banks?

Erik: we should say what data requirements we have and then let them define their own standard.

jheuer: I had the feeling that we were modeling something that could be represented to and handled by the user
... the reference to the browser therefore made a lot of sense to me
... however, there are some limitations in browser-based approach
... but +1 to do this _through_ the browser.
... the browser is not sufficient

<nick_s> +1 to Ian’s suggestion

<judy-zhu> *i am puzzled why this is related to browser

DavidE: Regarding Erik's comment about getting something to banks, remember that W3C is a PAS Submitter

<Zakim> dezell, you wanted to worry about asking too much of the AC

<nick_s> I am going to avoid the queue because it’s very busy and I want to finish on time, but I really don’t quite see how a generic credential API should be part of ISO 20022. Maybe we can talk about this more tomorrow in the break out

JimB: First observation is that the high order bit is that we need to get going on credentials; there's another level of detail about how it's done

<AdrianHB> +1 nick_s - think that needs some more explanation

JimB: Fact that companies found this interested and wanted to join struck me.

Katie: +1 to getting started on this

Laurent: I'm not sure we should be talking about user credentials for payments

AdrianHB: Brad made the point that we need to be cognitive of - the long tail of the browser API
... if we implement something in the browser, there will be N versions of it down the line
... in the payments WG, we've taken the approach of a flow and a message envelope
... a credentials API would be similar

<padler> +1 to envelope focus..

AdrianHB: ...I think what's on the table today is that it's headed down that road, but ultimately it will also be able to handle credentials storage outside the browser
... Regarding next steps, I think we have raw material already to start a WG

<Laurent> +1 to credentials format vs credentials APIs

AdrianHB: what's not clear is who is going to put their hand up.

<nick_s> +1 to credentials being a distinct group rather than inside of payments WG

AdrianHB: Generic credentials storage mechanism via the browser is a good building block
... my proposal would be to form a task force in the IG to charter a WG

IJ: +1 to the flow + entity that manages it (which may be the browser)

AdrianHB: Many similarities with payments (but credentials have no logic)

IJ: others say Wallets have no logic :)

Dinner at: SAPPOROKKO (さっぽろっこ in Japanese)