Web Payments Interest Group F2F -- 02 Feb 2015

<wseltzer> trackbot, prepare teleconf

<trackbot> Date: 02 February 2015

<wseltzer> David_Ezell: Welcome

<wseltzer> Evert_Fekkes: Welcome from Rabobank

<wseltzer> [Dinner tonight, Borobudur, Indonesian rice table]

<steph> Meeting: Face-to-face Web Payment - day 1

[Hurrah, thank you Stephane for the good work in getting this going…]

<steph> steph: thanks to all!

<wseltzer> scribenick: Ian

Administrivia

[Review of previous minutes]

<wseltzer> Previous F2F minutes

http://www.w3.org/2014/10/f2f-wpay-minutes

<m4nu> +1 to approval and publication of minutes

Proposed: Approve previous FTF minutes as posted

SO RESOLVED

[Agenda review]

David: Will work on roadmap, statement of purpose so others know what we will be doing.

Manu: +1 to grounding discussion in use cases. Then we will look at how payment agenda will address use cases, then roadmap

Joerg: On term "payment agent"...ties into user agent, but some people have concerns about that term

manu: Might be good to add to the agenda where there might be "blind spots" in the group
... topics missing from our agenda

Katie: Why is "agent" problematic?

Joerg: In EU finance industry, "agent" has been used to mean "humans" (as in "standing in for other humans"). But today I would stick to agenda in the sense we've meant.

Pat: E.g., is a payment agenda legally binding? These are the sorts of questions finance people might ask.

Evert: We could, e.g., in definition, talk about the other meanings in industry

steph: Another good thing to do is to ensure we have all the types of actors around the table that will be part of the payments chain

Joerg: I would like to ensure we have a sufficiently generalized view, instead of focusing on a particular payment solution
... I want to ensure we are creating a level playing field, and ensuring that all the roles can interact with one another

<wseltzer> dezell: we could be discredited for being too broad or too narrow; looking for the right spot

CMN: Let's get to use cases. Person-to-person transfer of money is an example of a use case that we can look at - is it there, a blind spot, or out of scope. So I am hoping to get started on the agenda…

Laurent: Payment slightly different from purchasing experience

<Zakim> dezell, you wanted to talk about IRC and the queue

<Zakim> dsr, you wanted to ask if everyone would be willing to participate in a group photo at some convenient point during the face to face

<stefanthomas> validation!

Istvan: Milestones?

David: Our activities will include outreach
... milestones for getting standards work will be milestones for WGs

<Zakim> wseltzer, you wanted to talk about w3c process

[Wendy on W3C Process]

Wendy: Team is here (not just for technical work) but to help with the procedural steps

<Zakim> chaals, you wanted to correct^W augment what Wendy said…

chaals: The IG will succeed by getting changes to the existing technology stack of the Open Web Platform
... a lot of the way to get success is to look at existing groups that are "close to what we want" and to ask them to start working on a piece missing from the stack; to join the IG and make the work happen
... it's important that people go from IG into technical group to get stuff done
... we'll need to work with other groups (e.g., on security)
... Charles...note that if you join a WG you operate under the W3C Patent Policy
... one advantage of moving work to an existing group is that you can get greater patent coverage (due to more participants)

Manu: Two Community Groups to keep an eye on: Web Payments Community Group; Credentials Community Group

<wseltzer> IG Charter

[Quick scan of charter]

David: Any questions about the scope of work?

<Zakim> m4nu, you wanted to note that the charter is a kitchen sink.

Ryladog: Only WGs create W3C Recommendations.

Manu: One example of CG work that advanced to a WG is JSON-LD.
... went quickly through W3C Process much faster than other specs I've seen. CGs can speed things up.
... there are many paths to Recommendation

Getting up to speed

<chaals> [I have seen specs go from start to Rec in one year, by having a small and clear scope… whereas my experience suggests that trying to invent technology as part of devleoping a standard is usually a recipe for taking a looong time]

ISO20022, ISO12812, X9.119 Pt 2, Web Crypto, NFC, ....

Erik: ISO20022 XML Format integral to financial services.
... nice thing about ISO20022 is how they broke down the problem to come up with a standard.
... I am reviewing business processes that went into ISO20022
... we don't want to ignore existing standards.

IJ: Can we get permission to circulate them in Member space?

David: We got permission for staff contacts to review X9...I think they don't have a problem with us quoting them

<evert> Maybe Committee Draft (CD) documents are available public?

Steph: We are still working on this...establishing a liaison with TC68
... we are trying to see if we can get approval to share these docs within the membership or the group...we have not yet succeeded.

Joerg: Could people who know these specs give a brief overview?

Steph: there are some docs linked from the first FTF meeting on this

<steph> documents from 1st f2f linked from https://www.w3.org/Payments/IG/wiki/Reading_List

see catalog of business processes:

https://www.w3.org/Payments/IG/wiki/Use_Cases_Task_Force#Business_Processes

scribe: these will help us categorize our use cases according to ISO organization

dezell: SEPA defined under this architecture
... so for easy acceptance, we should probably think about conforming to this model.
... for the US, the standard is 8583 (older)
... so there's one way of doing things in US and another in Europe
... seems like 20022 is the way to go, however.

Nick: Apax standard in the UK is essentially an implementation of 8583.

<jheuer> ...Is this a topic we should all know - but not necessarily _talk - about repeatedly?

evert: 8583 has been massively implemented in industry...e.g., a company like ACI is not yet 20022 oriented.
... but if you look at the business descriptions, these are fine to relate to our work.
... the business concepts are well-formulated in 20022
... the fact that 8583 organizes its message framework differently should not make much of a difference
... 8583 has three versions, all differently implemented.
... so it's not a world of perfect interop anyway; we should focus on the business concepts

EriK: the author of 20022 works at Bloomberg now....
... I am also trying to make it easier to generate code ... much of that work has already been done

<dezell> q/

https://www.w3.org/Payments/IG/wiki/images/6/69/W3C_Web_Payments_-_Topics.pdf

<wseltzer> Reading List (wiki)

dezell: In my mind, message formats will flow over HTTP

[dezell reviews 12812 briefly]

dozen; UVM - user validation mechanism...validating a user's identity

scribe: it's important that we not ignore 12812
... regulatory implications are important to keep in mind

ISO 9564

scribe: basic instructions on handling secrets (PINs and keys)
... which are used to protect sensitive information
... the bar on protection of secrets is fairly absolute
... bar on protection of sensitive information is lower but still important

ARTS/NRF UPOS

scribe: they have spent decades creating APIs
... mag stripe readers, etc.

EPAS

scribe: another ISO 20022 EU-focused thing
... closely aligned with SEPA

EMV Payment Tokenisation

Evert: We need to understand how the act of payment is extended with something like Apple Pay

Patrik: Apple Pay's implementation is a variant of EMV (the one used in Europe)

Evert: Chip/Contactless happen differently at different times in different markets

laurent: Apple Pay extension to online payments also relevant for this group

Nicktr: The tokenization under Apple Pay is also an EMV spec

IJ: What else is relevant context for this work?

Joerg: Identity management
... e.g., tokens are used all over now
... moving away from session-based to token-based
... for scalability

Erik: See the recommended reading list (which came from TC 68 Chair)

dezell: X9.119 Pt 2 another tokenization standard
... Three groups to pay attention to within W3C in particular: Web Crytography WG
... chaired by Virginie Galindo, Gemalto

(Headed to Candidate Rec, for implementation testing)

<wseltzer> WebCrypto API

http://caniuse.com/#search=web%20cryptography

[Laurent gives some details on implementation status]

<wseltzer> Laurent: WebCrypto is having re-charter discussions now

dezell: Secure Element API is another topic

wseltzer: Secure Element is coming up in discussion...one of the important discussions that people can contribute to is on the question of the security model
... provisioning of authentication information from the secure element differs from the web origin-based security model
... where the origin site is the only one to have access to information that it has already sent you
... so the current question is how to bring these models together
... so that, e.g., there are not privacy leaks
... as information is exposed beyond a single web origin

Joerg: Conversations with Virginie have been around services at different layers
... is there something that has already been developed?

wseltzer: We might see a submission from some groups who have done some work in this area.

Mario: Google included host card emulation, which bypasses secure element entirely (and comes from the cloud)

Joerg: We need to have right players in the group for that discussion
... e.g., mobile operators might offer a certain level of functionality from SIM cards
... or manufacturers like Samsung, or tech vendors like AMD
... important that technology approaches are supported by business models
... e.g., we should talk to GSMA

Cyril: In Europe we have PSD 2...this directive is a new way to see the payment processor...I think this context is interesting for us to take into account
... and also the European Banking authortity is supposed to deliver a protocol between all those actors
... maybe our work could help out there.
... The term "payment" also includes various activities like initiation, clearing, etc.
... perhaps we can anticipate the work of others in our work

<dsr> See http://www.w3.org/community/trustperms/ for trust & permissions CG - a new group focusing on trust & permissions for the web platform.

Evert: we might do bindings between our terms and those of other bodies (and also differences)

<Zakim> dsr, you wanted to mention that W3C is starting a Community Group to focus o trust and permissions for the web platform

DSR: Trust model and trust allocation relevant for this group

<wseltzer> W3C Workshop on Authentication, Hardware Tokens and Beyond

Joerg: Permission model based on attributes is evolving.
... there is increasing use of tokens.
... identification of people is less important; people can use keys
... so when you say "permissions" that could include "one who issues tokens"

wseltzer: See earlier link to workshop on Authentication, Hardware Tokens and Beyond
... we brought together there various alliances and other hardware folks + web folks and got lots of discussion going
... that is where we are aiming to bring back the discussion for extending the web crypto WG, to charter a new WG that brings these technologies closer together
... we encourage you (and people you know who are interested) to join that work

<Zakim> m4nu, you wanted to mention that secure element, while important, shouldn't be a blocker for this group.

manu: While secure element work is important, I would not put it in the critical path for our work
... I think this group should be thinking about 2-factor authentication

<wseltzer> [discussion of the WebCrypto recharter is on the Web Security IG list, https://lists.w3.org/Archives/Public/public-web-security/ ]

manu: we don't need secure elements for things like digital receipts

EriK: Different types of transactions will require different approaches

Manu: I think the group needs to be considering trust and credentials (e.g., related to knowing customer, anti money laundering)
... credentials means the ability to prove you have a particular capability on the web
... e.g., I am a graduate of a particular university, or I have a passport from this or that country
... I have been trained as a plumber and have a certificate that enables me to be licensed in the state in which I am operating
... these are all very real use cases, and these are organizations in the credentials CG to try to make this happen
... the people in the CG are in education, health care, some financial
... all of them need a way to "prove who you are on the web"
... we want digital signatures on credentials to be verifiable
... if that group is successful, we will likely be able to reuse most of their work in the payments work
... groups who are in the CG: ETS (Education Testing Service)...they test 5M people a year
... they want credentials for people who are receiving new training

[Manu points to 9 use cases listed in their draft document]

-> http://opencreds.org/specs/source/use-cases/ Credentials Community Group Use Cases

Manu: For assertions like on linked in, orgs want to be able to verify
... Another use case - being able to be pseudo anonymous (e.g., showing your age without giving personally identifiable information)
... the community group would like to see W3C launch a WG within the next year to work on these use cases

<Zakim> dezell, you wanted to discuss how do we include credentials into the WP use cases

Erik: Again, need for credentials, etc. will depend on application needs

ach chaals

<Zakim> chaals, you wanted to ask about layering of credentials after lunch

chaals: There's a possibility we might want to do them here, or we might say it should be done elsewhere and we will rely on them - and to make sure that is reasonable, keep a close eye to make sure we can use their work
... we might operate in parallel....I think that might be a better approach
... it saves us work and also prevents us from inventing 4 competing ID systems

Laurent: You mentioned FIDO alliance....are you in discussions with them on credentials?

Manu: I don't personally, but we need to be aware of them

padler: I would step in between the two...there are other parts of payment where context is important (e.g., long term loyalty relationship)
... there will be an interesting line we have to walk...e.g., relying on existing systems but additional things we need to provide that are not taken into account in those identity systems we use

<Zakim> m4nu, you wanted to mention loyalty cards being credential-like.

manu: We are going to have to walk a fine line
... a loyalty card - is it a payment instrument or is it a credential?
... there are different ways to model the things we are talking about

<Zakim> steph, you wanted to ask whether this is only on users?

steph: Does creds CG look at merchant side in addition to user side?

Manu: Yes. It's a way of verifying entities, whatever they are
... Related to this is Mozilla badge alliance initiative
... to enable students to verify classes they've taken
... there are hundreds of institutions who are part of that alliance, and those people are part of the CG
... we are also getting big health care companies in the group

<wseltzer> [meeting resumes after lunch]

<wseltzer> [Vinay Gupta joins]

<m4nu> scribenick: m4nu

<wseltzer> [pay-your-own dinner, 7:30 at Borobudur]

Key Principles and Desired Outcomes

dezell: This is a part of our segue into our deeper dive into use cases.
... There are use cases that we've thought of, and use cases that we need to discuss.
... We need to go through and talk about what people want to do in this group.

Ian: Send this to the mailing list - we need to collate the key points.
... We want to build stronger messaging to go along with that.

dezell: What do we want this group's position to be? In our roadmap, we need to figure out what we want the message to be.
... A lot of work is driven by the members of this group. A number of people that drive outcomes will see those become the stuff that ends up being accepted.
... With that, let's talk about key principles and outcomes.
... I'm not sure if I have any key ones in my mind.

<Ian> Manu reading from goals on -> http://www.w3.org/Payments/IG/wiki/2014-02-02_Meeting_Page#Morning_1

<wseltzer> manu: [https://www.w3.org/Payments/IG/wiki/2014-02-02_Meeting_Page#Day_1_.28Monday_-_Start_10:00_Local_Time.29 reading from bullets]

steph: I'm happy with these points - I think we should add one more point - this is part of a level playing field. I think interoperability is key.
... As a wallet provider you shouldn't have to convince every merchant.

erik: We should adopt technologies that exist, and create only when necessary.

<chaals> [+1 to Erik - minimal creation of new technology

pat: I think +1 to steph - payment participants need to have a more level playing field. The more we can do to improve interoperability through standards, we want to have more stuff that looks like the Web.

dezell: If you want to make sure something gets into the minutes - be specific about what you want in there.

evan: The biggest goal we're interested in speaks to interoperability, but not just interoperability of browsers and phones. People store value in many places today. It's difficult to move value from one network to another.

<padler> participants include all players in the space... not just payment technologies providers, but also individuals, networks, etc..

<steph> +1 to evan

<padler> +1

evan: Interoperability - not just with wallet and phone, "You accept this type of value on your payment network, I store value in a different currency on a different network" - how do I do that?

Laurent: One key principle we want to maintain - we want to be as agnostic wrt. payment technology.

<steph> +1 to be payment instrument agnostic

Laurent: We should be independent as possible - we don't need to become the 15th payment technology - big pain point we can solve - how do you bridge gap between merchant and customer.

<Erik> +1 about ripple. Remittances is a big selling point for W3C Web Payments. For that to be successful you need to be able to move value between payment types, networks, etc

Laurent: Interoperability of the payment ecosystem - that's not solved today.

<Zakim> dezell, you wanted to talk about ui consistency and to

dezell: One of the important bits here is to have a consistent UI experience - accessibility. We want payments to be easy for people that can't see - that are cognitively impaired. We don't want to only target top 3% of the world.
... There are a lot of people that can take advantage of this that may not have access.
... Getting that right is going to be hard, but it's important.

Joerg: I support the general pattern that we need to harmonize all of this into a framework. It has a lot to do with user control.
... How can we put the user in control of all of these things. Hundreds of payment mechanisms. This has a lot to do with transparency and automation.

<padler> Interesting that if we want to stay agnostic of specific payment processes... that we may need to bring the merchant use cases up a level... in other words... instead of using the terms like consumer pays merchant... we should move towards payer pays payee...

Joerg: There are a lot of things that need to work automatically, where does that automation take place?
... Pre-configure credit card with Amazon, pre-configure payment instrument with others. When it comes to things that are sensitive, you want to be confident that any automation will work in your favor / for you.
... The convergence between proximity / real-world and the Web world is difficult. We need a few elements to make this work.

<padler> +1 to keeping an eye on convergence of proximity and purely web scenarios..

<Zakim> steph, you wanted to ask to prioritize bullet points

Joerg: Not only should this be nice from a technological perspective, but we want the social aspect of this to be good as well. We want merchants to be happy, or make their businesses better as a result of this technology.

<mario_de_armas> +1 to joerg, make it easy for consumers to change/update credentials as they need to

steph: I think it's important, when you present the work of the group - we should communicate this well to the outside world.

<padler> +1 to steph on consistent messaging for the group..

steph: Having a flat structure is ok, but we should be clear about what's important and not important.

<steph> steph: above all, what is our first priority vs what may come later

<padler> +1 to data portablility...

floris: There are many other types of transaction domains. We need to make sure data is portable on other services.
... Make the data useful to many different domains.

erik: It costs a lot of money to add delay to payments, let's make sure what we do is performant.

<padler> <erik> efficiency is key... this needs to be fast!!

erik: W3C is the only organization in the world that is capable of getting this stuff into the browser, mobile, etc. Integrated everywhere. W3C has the ability to reach all these devices (and people).

dezell: The desired outcome is ubiquity?

erik: Yes, full market penetration.

<Zakim> chaals, you wanted to say "anyone can effectively use a payment, and understand what they are doing, to move (money/value/…) to another person"

<mario_de_armas> "Every one additional second at POS costs us $12 million." Bill Simon, President Walmart US

chaals: "Anybody can effectively use a payment" - a successful system is one where you can take your money out of the system.
... Exchanging currency as a service, but getting your money and moving it elsewhere is important.
... One of the things we want to come out with is some clarity of where people can add value. For example, exchanging money.
... We want to be clear about where people can add value. You shouldn't need 5 middle-men to exchange money.

<padler> +1 to minimizing the number of "hops" to faciltate a payment...

chaals: If we do our work right, it'll become clear about where the value is created.
... We will get in the way of services - some services will become more or less irrelevant. If things are going away - if things are put into the Web, it might be difficult to unseat that (the Web).

<padler> As the number of hops increase... so does the risk and the inefficiency of the payment..

Katie: One of the important principles - value is from perspective of various stakeholders. Nobody should be top dog here. All stakeholders should have same opportunity.
... This has to have value to the organizations / companies / financial institutions / individuals to be involved in it. Usability, portability, responsibility.

<chaals> [As the number of hops increase, so does the opportunity to charge for them - which at one level is seen as "the value of the financial services industry"…]

dezell: Our charter only mentions two stakeholders - payers and payees. One of the value adds of this group - we'll be able to represent other stakeholders.
... Part of value add of this group is to specify how each one of the current players justify their place in the ecosystem.

Katie: The value here is for everyone.

dezell: This is about membership - we need the right balance.

wseltzer: From a W3C perspective - bringing secure, convenient payments into the Web Platform. Web platform has demonstrated that it's good at easy communication, easy publishing. We need to take next step - easy to participate in a transaction. Let's make payments another aspect of Web development.

dezell: That is an educational challenge - we need this group to help us get that message out.

<Zakim> padler, you wanted to discuss the idea that the payer or payee may not be people ... especially in the IOT (ex. payee pays vending platform)...

dezell: You believe W3C is important in this space because you came here - important to get that message out to the public.

pat: As things move toward Internet of Things - maybe the payer isn't a "he" or "she"... but a thing, a car paying for a parking spot.
... We need to make sure we're forward compatible as well as backwards compatible. We need to also pay attention to 'hops' - minimize the hops a payment has to go through.

dezell: The W3C has it's own activity - Web of Things.

dsr: We do have a Web of Things IG.

pat: Payee and payer may not be the entirety of the actor - machine-to-machine payments.

dezell: We already have some use cases - the ability to sanction payments on your behalf when you're not present.

<Ian> [In W3C parlance this is called the Principle of Least Power]

evan: As a principle - standardize as little as possible. For this group, it's useful to layout everything in scope in this group. Some of this stuff is "boiling the ocean". For example, commercial interaction about product is a big endeavor.

<evert> +1 tot evan

evan: That is separate from one person trying to send money to someone else.

<Ian> +1 to having this group clearly say what it considers out of scope

<Laurent_> +1 to focus and standardize as little as possible

evan: Another piece is messaging around compliance - could be in scope, could be difficult.
... Another example - the payment agent - how do you authenticate with the payment agent? If I just need to talk to my agent, that doesn't talk about anyone else. The level of security is something I need decide w/ my payment processor, not something that needs to standardize.
... Standardize as little as possible, is important to focus on - helps prevent us from getting wrapped around the axle.

pat: There is some basic level that needs to be accounted for, it's a delicate balance.

dezell: We want to come back to this. It's 80/20 - the problem is one person's 80 is another's 20.

<chaals> [Picking how much is worth standardising is the whole art of the work we are doing]

<padler> +1

Vinay_Gupta_E: Good to remember that these things exist: repudiable vs. non-repudiable payments. This has implications on payment mechanisms.

<padler> to repudiatable/non-repudiatable payments..

<mario_de_armas> +1 on repudiable vs. non-repudiable

Vinay_Gupta_E: Legally binding digital signatures - identity / authorization / signatures - keypair management.
... Also important - transitive trust. How do you express different types of trust mechanisms. It becomes very important in an IoT concepts. For example, how does a washing machine authorize payments? How is my identity transferred through the system?

mario_de_armas: Touching on a couple of comments. Making sure stakeholders have a level paying field.
... The customer and the merchant are the people you have to have in the payment process. I'd be concerned about being too focused on keeping existing players that don't bring value. We want this stuff to be efficient.

<Vinay_Gupta_E> On the transitivity question "ode to the granovetter diagram" and "confused deputy" are your search terms

mario_de_armas: We want the middlemen/stakeholders to bring value.

dezell: If you give all stakeholders an equal footing, how do you know which ones are the right ones.

<Zakim> chaals, you wanted to suggest that "A successful web payment meets applicable regulatory requirements across the globe"

chaals: What are the things that define a successful payment? Standardizing too much makes it too complicated, no adoption.
... Providing too many players on the field may lead to bad things.
... We go back every few weeks/months - we need to tie down the details, ensure we're focusing on the right things.

<mario_de_armas> technology is leading regulatory requirements

dezell: Different regulations apply in different places.

mario_de_armas: Technology leads regulations.

erik: A friendly web interface doesn't mean you'll meet regulatory requirements.

Martin: Another way to say it is that the system should not prevent people from meeting regulatory requirements.

<padler> Is it regulatory requirements? or moreso legal/jurisdictional requirements..

<padler> just because it is not regulated does not mean that it is legal...

erik: If you're in China, they don't care about things that don't leave the country. Tiers of regulatory requirements are out of scope wrt. W3C initiative.

wseltzer: Our goal is to not interfere w/ regulatory requirements. Maybe the standards should meet regulatory requirements through a hook.

Vinay_Gupta_E: We record metadata to meet regulatory requirements, we don't say it meets it or not.

chaals: We're trying not to interfere. if we know we can't meet regulatory requirements, it's a non-starter, we known that.

dezell: This is something we should talk about. We will not knowingly violate regulatory requirements, that's about as good as we can do.

<wseltzer> [also distinguish between spec and implementers; the implementers and users should be able to meet regulatory requirements when following our specs]

Nick: Echo the language of 'payer' and 'payee' - right now we have 'card' in the language.

<evanschwartz_> +1 on moving away from the language of cards

Nick: About incumbents - we need stuff we can implement. We want actionable vs. aspirational.

<padler> +1 on moving away from a particular payment scheme (eg. cards)

Nick: Actionability is what we want.

<evanschwartz_> actionability + standards that entities actually have _incentives_ to adopt

<chaals> ACTION: Chaals to pull out a new list of requirements from the starting list plus this session. [recorded in http://www.w3.org/2015/02/02-wpay-minutes.html#action01]

<trackbot> Created ACTION-51 - Pull out a new list of requirements from the starting list plus this session. [on Charles McCathie Nevile - due 2015-02-09].

Cyril: There are other transactions that lead to a credential - one of the major confirmation point - we have seen a lot of payment systems. push-payments push fraud outside for later. It's more than just 'stolen cards' - it's about fraud.

<chaals> [+1 to Cyril's point on transparency of cost - which I think is tied into the idea that people understand what they are doing when they make a payment]

Cyril: We need transparency on the fees. We talk about value that we bring, but transparency of fees - fairness of competition. Often, person-to-person payment is fine, except for the person that receives the money (remittance fees are very high).
... Sometimes, some transparency is needed - payment should be something you buy.

Katie: I agree
... This is a standards body - long-term you have to have something that countries can build. Ultimate goal is to have something that is generally agreed wrt. good way to go.

evan: There are a lot of different pieces to the process - only some of them are worth standardizing.

<Zakim> dsr, you wanted to enable value added services on behalf of end users, e.g. based upon access to standardized receipts, or facilitating user preferences relating to discount

dsr: Value-added services for end users - if a user wants to buy something, they want a 3rd party to help them with that.
... You want what you want, not what someone else wants for you.
... What do the end users expect? What value do they want?

Joerg: We want to make things more efficient than they are now. Worked with someone that worked at cashless for Aldi. The biggest thing in their world was a big clock on how much time it would consume.
... If we reduce the time in the queue, at the payment terminal, they could make use of that. They don't do loyalty cards because it takes too much time. Loss of time, new opportunities if we can make things more efficient.
... Rather than minimize things, if there is half a second we can save - there would be new ways of making things more efficient.

Ian: This is very helpful for me as a new person - pasting something into IRC.

<Ian> ===

<Ian> Goals

<Ian> * Increased security, privacy

<Ian> * Cross platform interoperability

<Ian> * Data Portability

<Ian> * Opportunities to add value

<Ian> * Reduce hops

<Ian> * Faster payments

<Ian> * Convergence of online and in-store

<Ian> Constraints on the system

<Ian> * Repudiable

<Ian> * Support for legally binding digital services

<Ian> * Enables people to meet regulatory requirements

<Ian> * Payment technology agnostic

<Ian> Scope (and out of scope / principle of least power)

<Ian> * Focus on payer / payee (abstractions) and not other parties (as much)

<Ian> * Exchange of value between parties

<Ian> ...but not focused on, e.g., local interactions between myself and my agenda

Ian: I want to help all of us communicate our work - we want data security, privacy, faster payments... things we want.
... I also started to hear actual restrictions on the system - what properties the system should have.
... I also started hearing stuff about scope...
... Let's not dive into the needs of every other party - focus on exchange of value between parties - what goes over the wire and it is interoperable.
... What we produce will conform to the constraints, here's what we're trying to do - we don't want to boil the ocean.

dezell: One landmine - in financial services business - this is a renegade position - focus on payer / payee - it's okay to have this position, but we need clear communication on why that's ok.

pat: Going back to regulatory aspect - payments will happen in certain jurisdictions - say sending payment from US to Europe, you have to support super-set of what you need on both sides to meet regulatory.
... Those that need to know need to be able to audit payments. Payee wants a log of everything they've been buying.

Katie: What 25 things did I sign up for over the last few months?

<Ian> [IJ heard form use cases that there are audibility of payments....e.g., pseudo-anonymous payments]

Vinay_Gupta_E: What about saying "We won't do payments that are evil?" (joke)

Laughing in the group.

Laurent: Mostly I'm hearing about two trends - people that want to standardize payers/payees (the exchange) - support all payment instruments in a harmless way.

<padler> correction... not to meet regulatory requirements.. more important to meet jurisdictional requirements...

Laurent: Then there are people that want to standardize universal payment instrument - those are the two trends I'm hearing - they're independent.
... I like the first one, it's the best place to get results quickly - trigger a payment in a universal way - easier than trying to define a single universal payment instrument.

<padler> for example if the payee's jurisdiction requires more data than the payers, then the payer would need to provide more data than normally they might..

Laurent: Payment processor, payment provider, trying to standardize universal payment instrument would be very difficult
... Standardize stuff between merchant / customer - biggest bang for buck.

dezell: Non-goal - we don't want one standard way of making payments - we're not going to say "Tokenization is the way to go"
... We're going to say "here's how you do tokenization." if you disagree, send it to the email list.

<padler> would that be standardizing stuff between payer/payee? vs. between merchant/customer?

dezell: End of queue, here's what we want from the group: Send what you want to the mailing list.
... Please repeat yourself - put it in something actionable.
... We want to put this on future agendas.

Joerg: Easier to understand some of this with a demo - if you want a demo, let me know.

dezell: Let's go through your demo tomorrow.

<chaals> scribe: chaals

Review of essential goals

DE: For the rest of the meeting we are trying to address the essential goals. If you think we are going off-track any time is a good time to say so.

… First: Use cases. That's what we are doing now.

… You should be thinking of what use cases are missing. High level overview, then deeper into what we have done.

… Tomorrow we will look at what payment agent tf has done. A series of processes and potential APIs - a model that helps inform use cases and relationship t o the open web platform.

… on wednesday we look to creating a document that will be an IG Note published at W3C, describing what we are doing.

… The use cases, after the discussion and refinement, should become a Public Working Draft in the near future.

… That requires Group Consensus. And we want to have an outline or editors' draft for the roadmap.

… We'll also talk on teh last day about gaps in the group - what sort of people we need to get into the discussion.

Use cases.

<wseltzer> Use Cases TF wiki

-> https://www.w3.org/Payments/IG/wiki/Use_Cases_Task_Force use cases page

MS: At the first workshop there was a use case scribe - specifically trying to pick use cases out of the conversation,

… in the Web Payments CG, we refined and developed these (and dropped some that seemed way out of scope)

… and then put them back into the Task Force doc.

… There are 4 approved to go in the FPWD.

… (By the Task Force - i.e. we as a whole group could push back on the decision, which is ours to make finally)

… There are a number that are ready to go - have examples, requirements, etc. Those are the ones we should start with today.

… And then there are some in the middle that are only half-done so far.

… Does the structure make sense?

[nodding]

MS: I have a number I think are critical…

… there are others that are high priority but not done. Digital receipts and all that goes with it is pretty important - should we try to get as many in, or focus on key phases of payment.

DE: Does any of the content cause pain or suffering?

Laurent: On some we have to review the wording…

… you have to provide a choice of payment instrument, but not all use cases reflect that.

… e.g. purcahse request discusses payment processor.

MS: CHoice of payment instrument is in there…

Laurent: Yeah, but others that should use purchase instrument talk instead about buyer's payment processor.

MS: They are intended to say that, so we should discuss the issue.

… How strongly do we push the idea of you choosing payment process, vs merchant, or …

… We've been promoting push-based payment and not looked carefully at 4-corner payments. I suspect card companies won't love that approach.

… Push-based model is that you register your card with you provider, and that info doesn't get passed directly to the merchant.

<Zakim> wseltzer, you wanted to ask how you prefer input

WS: What is the process to add to the use cases?

MS: Write into the Wiki. There is a feedback section, where you can raise issues...

… it is better to get stuff into the wiki so it doesn't get lost.

DE: Hoping for a rubber stamp for those 4, but it's good that we see the issues.

[Ian shows 2+2=5

Steph: Comments on choice fo payment instrument. Is this highlighting the interoperability of a wallet - you can negotiate different instruments if your wallet isn't the one the merchant supports, or is it at a higher level?

… Covering both, or only the case where you pay with visa/MC/Paypal?

DE: Will q to answer

IJ: I don't object to extensibility but it doesn't explain what the value of making things extensible is.

… i.e. why do that work?

… (appears in various places)

IJ: Please use RFC2119 terms consistently.
... Choice of payment instrument… I circled the box "registered" - what does it mean in this context?

… where is the registry?

MS: No central registry, your device / agent understands what instruments you have, what the merchant is willing to accept, and looks for a union.

IJ: I don't know that I understand the 1st 2 bullets yet.

… Last bullet builds list of preferred. Semi-automatic preference selection seems like a separate use case.

JH: I would take them apart. Talking about the automation isn't something W3C should be trying to standardise.

… But the ability to choose, yes.

DE: I think we will have achieved success if we leave maximum ability to implementors to do things well.

IJ: We can say "our minimum thing is: 'you have to allow people to choose'".

… scope notes might be helpful like that.

IJ: Would be nice to note security / privacy implications in each use case.

<jheuer> Second the idea to not get involved with automation of payment instrument choice - it's going to be a matter for business models and much interest in the ecosystem

Laurent: We should look at both 3- and 4-corner payment model.

<wseltzer> [I added some questions to the push-based feedback]

… the use case has only one 3-corner case, we could add a 4-corner case.

… choice of instrument is 3- and 4- corner. The others are 3-corner. Maybe we can specify different cases for each model...

<scribe> ACTION: Laurent to review purchase request use case [recorded in http://www.w3.org/2015/02/02-wpay-minutes.html#action02]

<trackbot> Created ACTION-52 - Review purchase request use case [on Laurent Castillo - due 2015-02-09].

MS: There are two things to do here. One is determine whether the use case is in scope, the other is to look at the use cases in detail.

Laurent: Is 3- and 4-corner in the glossary yet?

<Ian> (+1 to putting 3- 4- corner in the glossary)

[No, but there is a diagram that can go in the glossary]

MS: Do we want to support teh 4-corner model at all?

Laurent: Yes. Impact of moving evertything to 3-corner model is a massive amount of work, so will delay us significantly at best.

MS: Sure. But then we are standardising an inherently insecure model...

… unless we have tokenisation

Laurent: Not necessarily, there are other ways to do it securely.

… does have good property of separating user and merchant sides, so you don't depend on a central processor.

… has some advantages. Not so insecure, if…

<Ian> Laurent: W3C should not choose the payment method...there are too many choices available

… You need a strong credential to make it work. But W3C shouldn't try to make this choice for the industry, be agnostic

JH: Would it be OK to say we are targeting solutions that make 3-corner models possible but doesn't exclude 4-corner models?

KHS: Yep.

JH: We should not exclude 4-corner models

MS: Agree. Concern is making it easy to transmit card nmbers and having emrchants store them. If we succeed in 4-corner we can fully-automate that really dumb model.

… You are arguing that we shouldn't automate that process, but we need to be really clear about the distinction in the use case.

Laurent: Can come with omplementation constraints.

IJ: If it is in scope to do both, it is helpful to call out implementers.

Mario: There is a principle of merchant not storing credentials.

MS: We provide mechanism so merchants don't need ot store credentials

CV: If we look at what there is, how many 3-corner models, how many 4-corners are out there today?

…at the end of the dayt we have to think about where is the money.

<Ian> IJ: I like the idea of staying at a high level "Improved security/privacy" and then we say there are some pieces to this like not storing user credentials on merchant side. And then what are the constraints that derive from that. And then what solutions satisfy those constraints.

… we cannot just invent initiation of payment, at the end of the day we have to move funds.

… Push payment is more like credit transfer.

… We have to cope with credit transfer, direct debit, and others. If we say we always want 3-corner model, we cannot just put the payment in because the funds have to be tranferred. And that doesn't work yet.

… I don't know what is a payment processor today.

… Payment processor is written by acquirer. That's not the only way. In the use case we have to figure out when the clearing and settlement happens.

… If we send to a payment processor, they need to take information and do stuff, and this should be covered. We cannot just stop at initiation.

… (because it won't be implementable)

… For me payment processor is important. There are few push-based systems.

DE: Is that something that should be entered as a comment in the use case wiki?

MS: When things are in the FPWD doc, questions should be clearly outlined as issues in the document.

… it isn't clear how we express need for 3- and 4-corner models. So to publish FPWD we have to label it as an issue. And we need 3-corner and 4-corner model in the glossary

DE: We were supposed to talk about Glossary. We'll do that some time.

<Vinay_Gupta_E> +q

Steph: My question is whether you want to mix payment instrument and wallet, or you have a system with sets of instruments in a wallet, and you look for matches of one of the instruments in your wallet.

DE: It's a matching of what payeres and payees are willing to do. In simplest, merchant says what they accept, you decide what you offer.

… there needs to be an exchange of information, and that's I think what the use case says.

<Ian> +1 to another use case

SB: Think we should create another use case on wallet interop or include it here, but I think that is part of the bullet we discussed this morning so it is important to highlight that explicitly.

MS: I think what we have is merchant says "I accept A,B,C". client says "I have B and C" and picks one.

SB: Today you go to a site, and can choose between payment instrument and wallter. Either that is one use case, or there is a narrow version - instruments, but not wallet. That's how you make interop between wallets.

DE: I would say that is between payment agent and merchant. Which choices line up, which is best (without distinguishing wallets and payment instruments as different)

SB: E.g. example - I have iufyb wallet that supports visa and mastercard, and merchant doesn't know lufyb but happily accepts visa or mastercard.

Laurent: SO in this case you display to user that there is a match on the visa/mastercards

<scribe> ACTION: Laurent clarify use case for choice of payment instruments. [recorded in http://www.w3.org/2015/02/02-wpay-minutes.html#action03]

<trackbot> Created ACTION-53 - Clarify use case for choice of payment instruments. [on Laurent Castillo - due 2015-02-09].

MS: Best approach is to send it to the mailing list as review comments. Please be very specific about exact text changes.

DE: Start your email subject with "[use case]"

VG: ANyone worked with XML??I from 15 years ago? Maybe we can salvage some of that stuff, and bring it to a modern format

<scribe> ACTION: Vinay check whether there is salvageable stuff on XML-EDI for us [recorded in http://www.w3.org/2015/02/02-wpay-minutes.html#action04]

<trackbot> Error finding 'Vinay'. You can review and register nicknames at <http://www.w3.org/Payments/IG/track/users>.

<Vinay_Gupta_E> https://en.wikipedia.org/wiki/XML/EDIFACT

NM: Apologies. There is a lot of heat in 3- / 4- corner debate. You can decouple credentials from payment. I think 3-corner is a special case of 4-corner. Heart of this is to define the actors properly, and I don't think we have done that yet and this is leading to confusion in the discussion.

<Ian> +1 to understanding the roles really clearly

Laurent: Agree that diff between 3- and 4- is who is pushing the request. In 3 it is the customer, in 4- it is the merchant.

Nick: Zap is a 4-corner push model launching in the UK.

<Ian> (QUESTION: Is "double blind" a constraint anywhere?)

… we need to deal with credentials flow, 3- and 4- corner. But we need to decompose what all the roles are.

DE: We took a stab at that in the initial glossary. If we normalise the glossary, can we agree that the first 4 use cases should be there?

MS: I am concerned now, more than I was. Not being able to get through the 4 that we approved, the glossary discussion could kill us.

… We can have faith in the group to get the glossary right, look at use cases roughly, and go with it, or we can go headlong into the glossary now.

DE: Maybe others will get the fear of going forever, and will try not to be too long-winded. I suggest we start with approval of the 4 use cases, and then do glossary.

EA: Or we can adopt ISO-20022 glossary.

<Zakim> jheuer, you wanted to comment on naming

<Zakim> chaals, you wanted to suggest we revice merchant detail storage.

JH: WOuld like to see us take a look at the payment process from the user side, payer side, and checking up with the standards and models. I think we can do that with the expertise here. I would be scared to do it the other way around.

… If we start by unifying the experience from user side, we will come to a model…

… if we don't need something, I would be happy to hear that it isn't useful.

[scribe doesn't think the last line captures well what was said]

… start with the user view. I think the purchase request is a bit misleading. Purchase implies receving something in return, that might be wrong.

DE: In proposed FPWD draft it says "payment"

<m4nu> Here's the FPWD draft: https://dvcs.w3.org/hg/webpayments/raw-file/default/latest/use-cases/index.html

<Ian> scribenick: Ian

chaals: We may want to revise the "remove storage of the details from the merchant" to making something that is "enabled". In other words, we want to enable, not require

<m4nu> chaals: We may want to revise the remove storage of payment details from the merchant.

<scribe> scribenick: chaos

<chaals> CMN: We should rvise the "remove credentials from the merchant" to simply enable that (with security/privacy notes on why)

<chaals> scribnick: chaals.

<chaals> scribenick: chaals

KHS: If we agree that each use case should address 3- and 4- corner models, maybe we can avoid glossary discussion in advance. And do we want to split use cases to give examples of each.

… The wallet is our vehicle for payment instruments.

VG: Lot of mechanisms we are discussing are parallel things that exist inside cryptocurrency instruments.

… so there is something odd about the pushing of notifications vs the formal mechanism of payment. I wonderif the fuzziness there is generating some of the confusion.

<Ian> VG: Pushing around messages v. actual payment v. choreography of user consent

… There are elements that look like a tangle.

… messaging without transitive trust is different from doing it with it.

… Wonder if we should spearate generic messaging stuff from payment-specific pieces

PA: That's important. the point where the execution happens is different.

… in cryptocurrencies it is from the payer, in current systems it comes from the payee.

… there are 3 actors (at elast). Each of them can execute overlapping parts of the use cases.

IJ: I started to draw these and they are helpful to understand.

PA: That is where this is going. You have 3 actors, and you see how they are done.

IJ: I wanted to see the use cases as specialisations of the core use cases.

DE: We have some candidate diagrams - they may or may not suit.

<Zakim> chaals, you wanted to prpose a straw poll

<m4nu> chaals: I suggest a straw poll - "We will accept these items in the FPWD, you can still raise issues on them."

<m4nu> chaals: Diagrams are helpful - also write down the description below the diagram.

<Zakim> Ian, you wanted to mention point of order on publishing

IJ: A First draft can be edited…

<Ian> PROPOSED: Accept purchase_request, push-based, choose of payment, pre-authorization for FPWD

RESOLUTION: The FPWD will include the 4 use cases included.

[10 minute break]

<m4nu> scribenick: m4nu

Glossary

dezell: We need to look at glossary now. It's not necessary that we agree to everything - it's important that we agree to use the terms in a definite way.
... We can say "not everyone understands this term". Any one in here can defeat us utterly in what we're going to try and do here.
... Let's try and start with the roles.
... We have a 40 minute time box.

evert: A couple of slides - putting the roles into context - three and four corner models.
... Payment Scheme - everything is optional except for consumer and merchant.
... a payment scheme is required to make sure that everyone is keeping to the roles.
... Disputes are being settled, etc. From a legislative approach.
... Clearing and settlement - card schemes usually do that - but recently unbundling of scheme and processor happens.
... There is a issuing processor, acquiring processor and a switch processor.
... There is a thin line between acquiring processor and payment service provider.
... Value Added Services - those are where everyone makes the money (joke).
... EMV definitions - let's see if there are multiple interpretations on those roles. This is the cards model, but it's flexible enough for a realtime payments model.

Cyril: Does iDeaL work on t his model?

evert: iDeal does work on this model. It doesn't use the card networks - it has a proprietary clearing system. Credit transfer is moved to acquirer to merchant.
... IDeal in itself is a four-party model - but the transaction is a credit model, not a card model.
... This is important - push vs. pull payments - whether we define the payment as a whole - including initiation/authorization phases, or just the moving of money.
... PayPal - is it a scheme or not? They started their business with their own accounts - consumers found it hard to put money into multiple wallets.
... you can still have a balance at paypal - if you pay via PayPal in the Netherlands, you use credit transfer. It's a very flexible model because of a 3 party model.
... This approach has a price - it's a 7 party model. The agility that the 3 party model, with the reach of the 4 party model - but it has costs and fees associated with it. Looking forward with Web Payments, these are fairly straightforward models - but neither 3 party or 4 party will work for all payment scenarios.
... Before going into glossary, last slide - phases of an economic transaction.
... If you look to economic transaction - the buying process, payment initiation, purchase request/payment request.
... First step is to do identification/authentication. What token is being used? Account that must be debited? Is the owner of the token complying with the transaction?
... Does the payment provider agree with the transaction? In my day to day retail activities, you get a long sheet of paper. Order lines, optional step. It can be a part of the data that we exchange.
... You can't leak this data.
... There can also be a contract - if I pay at point of sale, I might get into a contract - you send a payment instruction to the bank. Direct debit, the money can be pulled back. If you have a smart contract that can describe what was bought, at what time, that can be pushed to an agent that fulfills the financial act when required.
... When you've bought something, you have an amount due. Then the next step - value added services. If these are food stamps, you can't buy alcohol with it. Coupons expire, etc.
... order lines are required input for value-added services.
... could be rebate, could be partial payments, payment instruments and technology - you could initiate the processing of the contract.
... Depending on the scheme model, clearing happens after that.

<Ian> Evert: This can be used to organize use cases

<Vinay_Gupta_E> I think you might find this all a lot easier with smart contracts. Ahem.

evert: I wanted to organize use cases w/ examples on major steps. The phases of the payment transaction.

Katie: Where is records management? How do you have an audit trail?

evert: Everywhere, pretty much.
... We must be clear that order lines are not payment related. They are input for value added services.
... The middle column is out of the payment scope - value added services.

Katie: VAS is a part of the privacy discussion.

evert: I have put this diagram in the glossary.
... The glossary work was supposed to be on mailing list interactions.
... In the work I envisage on the glossary, I'd like to structure it w/ elements of these diagrams.

dezell: This is a three step diagram?

evert: it's meant as a scoping discussion.

Cyril: We don't see the actors in this group.

s/this group/this/diagram/

dezell: The actors exist in the other document - in the glossary.

Cyril: The diagram is misleading - all the steps are not exactly the same. Based on clearing mechanism, authentication method, etc. Authentication process at this step is important.

<Zakim> m4nu, you wanted to speak in favor of terms for glossary

<Ian> scribenick: Ian

Manu: I thought that the diagram is great...we should have it in the glossary and use the diagram as the basis
... Same thing as the "phases"
... I didn't see anything controversial there
... Suggest a simple question put to the group to accept the diagram as shape of glossary

<Zakim> dezell, you wanted to ask about accuracy of 3-party model

Nick: Like the diagram....maybe call out the "accounts"
... there might be a processor facilitating movement of funds among accounts

<m4nu> Nick: I like the first diagram - the movement of money is done by additional actors in that space. The consumer has a bank account, the merchant has a bank account, the acquirer and issuer does. So there are two more towers - but, I like this diagram.

Nick: apart from adding those on the wings, I like the diagram

<m4nu> dezell: We need a better discussion on the payment steps - some or all of them may apply.

dezell: We need a better description of the payment steps; manu has an alternative

<scribe> scribenick: m4nu

Ian: When we have a verb like 'authentication' and 'authorization', it's nice to know who does those verbs from the roles.
... We should have a nice glossary - nice set of roles/verbs, we need that - how they interrelate.
... In some cases, the use cases might straddle bits of this. Can we carve out use cases so they don't overlap. We could make them simpler that way.

evert: We have to see how this works out - still unknown territory.

padler: A couple of quick thoughts - diagram is great. Certain parts of use cases are symmetrical. The part of the diagram that we react to - issuer and acquirer - maybe we can simplify them to 'payers financial institution' and 'payees financial institution'.

<stefanthomas> +1

padler: What about the forgotten phone use case? I don't personally have anything - the payee enters all information by themselves. Payee is entering information at point of sale.
... Are we supporting a bi-modal set of use cases - part of the transaction is digital, part of it isn't.

evert: It depends on the risk - designed to work anywhere, but it's about risk management.
... A keyed transaction - account data has been typed in - a higher risk transaction.
... Enter data proven to be entered into your passport. If you look to scoping, that shouldn't be in the standard. Extra services provided b y the different schemes.

<Vinay_Gupta_E> q

evert: if you look to 3D Secure, each issuing financial institution may decide on its own model. Some banks choose different authentication mechanisms.
... The standard in itself allows for variations.

padler: Does the entire transaction need to be on the Web, or not? I'm presenting cash at POS, it's being recorded in the event that I need a refund at a later date.

evert: We should be very careful here - if we want to facilitate payments, we need to know the attributes of price, whether we need to send price, etc.
... non-repudiable transactions - you have to prove that a payer was with a transaction, everything in the middle (value-added services) is unnecessary.

padler: Are these steps here required? Require that the payer enter their data? Use Case where we invoice and product comes 30 days later?

evert: Are we enabling economic transactions or economic payments?

padler: Are we allowing payer to enter 100% of the information, even when there are people involved.

<Ian> +1 (again) to clarifying scope in the work of the group (through use cases to start)

Vinay: Those include some chain of manual entry. It feels like there is an implicit set of changes here - are we doing something simple here, or are we in something so complex that we might as well do all of this stuff with smart contracts?
... Do we want to solve for the general case? or solve for all these other complex cases?
... What would it take to do smart contracts in Javascript? As long as you have keypair management and good crypto primitives - sign the javascript from payment processor and have it executed in the browser.

dezell: We have some general principles that have come out of this discussion. You need to be activists wrt. what you don't like.

nick: How do you want us to make these changes?

evert: I'll try to find time in the next few days to work on this. We need to scrutinize more - let's try to implement a couple of things - how to put this terminology in. Can we identify where we can focus discussion.

<Ian> +1 to lovely integration of diagram(s), use cases, glossary

evert: This needs a bit of cleaning up.

<dezell> ACTION: Evert to revise the glossary per the discussion at the f2f, and let us know when season opens on comments. [recorded in http://www.w3.org/2015/02/02-wpay-minutes.html#action05]

<trackbot> Created ACTION-54 - Revise the glossary per the discussion at the f2f, and let us know when season opens on comments. [on Evert Fekkes - due 2015-02-09].

dezell: Let us know when it's time to comment on the glossary again.

steph: I like the diagram, comment on privacy and how we fit privacy in this?
... Based on the discussion we had in Santa Clara - how do we fit this privacy in diagram - who has access to what?

evert: There's nothing in the diagram that addresses that now - maybe that should be in the use case description. Interactions on diagrams should be expressed in use cases.
... This data is considered private - I don't think they should go in the glossary.

steph: Items in the bill vs. amount.

evert: I've bought a car, milk, etc. The amount is a different element. order lines are sent to value-added services. it doesn't know value-added services portion.

Laurent: I like the diagrams - couldn't find anything to add/remove - perfect (joke)

Laughing from the group.

Laurent: Since we're trying to build a complete picture - what the merchant really needs is an account reference. The real one, what you need to authentication - customer is the issuer in that model. Add identification box in that model.

evert: my initial goal with the diagram was to discuss with people - order lines are not in there. We need to think about how we model that.

chaals: I like first diagram, it would be useful to show where the money goes in the diagram. Cash is a three-corner system - third corner is the central government.
... Helpful in glossary to explain the flow of cash - cash is a payment scheme.
... I don't like the second diagram - shouldn't be in glossary.
... You should take a couple of the example transactions - here is a transaction, here's another one, invoice and payment, value added scheme changing currency - show that.
... Lay those diagrams out first.

dezell: We have these alternative payment steps that Manu did a while ago.

chaals: Let's start putting those diagrams together.

Joerg: I like the first diagram - wouldn't like it to be the basis for the glossary - it's a specialization of a generic vocabulary. This is the monetary part of the payment thing. it's not for the presentment of the loyalty card, etc. My basis, looking at things, what's the user experience.
... If I provide something to a clerk or a web shop - it's something that could be out of order, how it's processed later on - positive effect of layering something. How are the payment instruments being layered?
... If I want something, as a customer, I put it on the table and pay for it. In terms of vocabulary, I'd like to come up with generic terms where we need them, I'd rather go for generic terms and use them instead of the specific ones.
... We have terms like 'agent' and so on - some of the models might appear in the glossary - they should create one picture?

<CyrilV> this is not "payment vocabulary", it is "card payment vocabulary"

Joerg: if I look into loyalty stuff, or tickets - it's a three-corner model.
... There are also loyalty schemes that work in the four corner model. No one would say 'acquirer' there.

dezell: Could we just call it an industry standard - what people call it today?

Joerg: It think the only thing that creates an issue is the acquierer.

evert: If both acquirer and issuer are the same, then it's a 3 party model.

mario_de_armas: The examples of the models vary by country, but this definition captures it.

<Ian> Mario: +1 to the diagram

Katie: Document-specific, glossary is something we add? Specific to documentation that we use. We want to identify where each term comes from - ISO20022, etc. Have we defined it? Have we gotten it from elsewhere?
... The references to each and every one - where did they come from?

evert: I've already done that - said where things came from

<Ian> +1 to good documentation of origins when stolen from other places

evert: Definition, references - we need to refer to official definitions.

Vinay: It's complicated, maybe we should make it generally programmable.

Ian: I like small diagrams to illustrate each use case. When you see them side-by-side, it helps to make you understand. It helps make the content concrete.
... We may want to identify the things that are handed off from one item to another...
... Privacy was cited as a value-added service at some point.

Katie: I think privacy concerns would be most interesting to discuss.

Ian: Privacy and security considerations are good - potential value-adds would be good to discuss as well.
... Industry might want potential value-adds.

- DRAFT -

Web Payments Interest Group F2F
02 Feb 2015

Attendees

Contents

Administrivia

Getting up to speed

Key Principles and Desired Outcomes

Review of essential goals

Use cases.

Glossary

Summary of Action Items

Scribe.perl diagnostic output

- DRAFT -

Web Payments Interest Group F2F 02 Feb 2015

Attendees

Contents

Administrivia

Getting up to speed

Key Principles and Desired Outcomes

Review of essential goals

Use cases.

Glossary

Summary of Action Items

Scribe.perl diagnostic output

Web Payments Interest Group F2F
02 Feb 2015