Web Payments Interest Group Meeting
27 Oct 2015

Accessibility Input

presenter: Katie Haritos-Shea and Charles McCathieNevile

(slide 1)

Katie: The challenge is to make information available to all people who should have it (including with disabilities) and protect it from people who should not have it.
... We need to find a balance between transparency/privacy, etc.
... Roughly, 1 in 5 people has a disability

Charles: If you reduce friction in payments in a way that causes people to not understand, it will have a material impact on people's lives.
... it's important to get right (Charles cites example of curb cuts leading to injuries for people with blindness).
... so you can't make it so easy that some people make payments without realizing they are doing so.
... so early implementations should set the right example.
... note that accessibility regulations vary (and the US is sort of "in the middle")
... please keep in mind that this work will affect lots and lots of people.

Katie: We want users to keep control

Here's what would make Web payments great:

• security (a state free from Danger). In the bank where I work there is a requirement to double check data moving money ... financial and legal commitments can put people in grave danger if they don't understand it.
• privacy
• accessible

dezell: What should we do in the near term to ensure that we are meeting these goals?

katie: We need additional use cases
... we will be meeting with the Web Protocols and Formats Working Group later in the week.
... we will discuss guidelines for spec authors to keep in mind

jheuer: How can we assess the value of new things we come up compared to dangers of the old ways?
... Charles' example of curb cuts was compelling

jheuer: I am thinking of things like ABS in cars
... shifting liability
... I would like to learn how to assess the value of the new inventions that we have

Katie: the requirements that interfaces have to use are outcome-based
... those are the sorts of guidelines we will suggest to spec authors

Erik: Increasing velocity of money raises security / privacy issues. My question is how does an API enforce work flow?
... how can we, as a group enforce a work flow ?

<kasar> Kasar Masood, VIACOM, Observer

Katie: One organization in Spain (cf video) .... users set preferences their own preferences on how they would receive data.
... we are not suggesting preventing multiple clicks, but rather doing things accessibly (e.g., related to biometrics and accessibility). it's more about "don't prevent this" rather than "do this"

ShaneM: The charter we have now doesn't talk about user interfaces
... are there particular accessibility concerns we should be looking at at the low level so they don't manifest themselves at the high level.

Automotive use cases

Kevin Gavigan presentation on Automotive Use Cases (and other notes on automotive use cases)

(Kevin Gavigan, Jaguar presents: Web Payments use cases to enhance the automotive experience)

scribe: the Auto and Web Platform BG created two APIs (vehicle data API and Vehicle Information API)
... those handed to the Automotive WG
... the BG is now looking at other opportunities, e.g., media tuner, location based services
... we also are interested in security
... lots of car hacks recently...people in the industry recognize that cars are rich targets for hackers

Lots of participation from industry in the BG: auto makers, tier 1, government bodies

(Specifications)

Vehicle information Api is a starting point

scribe: goal is to enable vehicle signals to be exposed to applications ... information like speed, fuel, window state, sunroof state, etc.
... expose data in an open way to apps running on phones, on the web, etc.

scribe: various ways automotive information can be accessed (e.g., for maintenance) such a bluetooth
... the Auto WG is moving in the direction of a Recommendation for the vehicle data API

(Kevin shows example of use of API)

(USE CASES)

Use case: vehicle leaving car park uses web payment to pay parking fee

Kevin: Assumed here - discovery
... note that the preconditions are general across the use cases
... we assume that the owner has a digital wallet and has registered at least one digital payment instruments
... car can talk to car park charging system
... instrument is accepted by that system
... we need to know how much to charge

(More details on use case #1)

Use case 2: Car pays toll

(Scribe does not capture all the details that are in the slides)

Use case 3: Car pays for fuel

Note that in use case 3 there is likely a pre-authorization phase

scribe: (pre-approved limit approved by gas station charging system)

Kevin: Those are three simple and fairly obvious (and we hope indicative) use cases

<Zakim> m4nu, you wanted to ask if the use cases could be submitted to the group mailing list. and to mention that toll booth use case may need subscription-based payments? and to ask if

m4nu: Thanks for the effort to align the use case expression in our terms!
... please send us the use cases to public-webpayments-ig@w3.org
... once we integrate them into the document, it would be great to know the priorities for the automotive WG
... regarding the toll booth use cases, there are a couple of ways to do it; one option is subscription based
... it would be good to understand in detail how the automotive wg sees that - if it's integrated into the system, how do you see it working?

Kevin: There are also places (like London) with congestion charging
... and people could subscribe so that they preauthorize payments when they enter the "congestion" zone
... driver distraction is a big issue in automotive use cases
... limits to what you can display
... simple prompts (e.g., one message yes/no to make a payment) probably falls on the safe side

Erik: Privacy is a big issue; don't want people to track speed.
... would be good for use cases to include privacy heads-up

<ted> [in response to m4nu: parking could be subscription based if it is a garage you frequent and want to streamline the transaction process. doing as comment instead of using time in q]

dezell: Is a VIN a credential? (question to the IG)
... While you have a fueling model, do you have a model for a more complex purchase, such as "car wash" or "bring me a diet coke" to the car
... Another use cases is resource bidding.
... e.g., I might be willing to pay to get to work faster ... real-time bidding on lights being green
... could be interesting to consider

<Zakim> ShaneM, you wanted to ask about credentials and whether a car / truck credential would be useful for a toll booth and to also comment about privacy model, permission grants, etc.

ShaneM: I agree with Erik's point on privacy. If you can build in from "day 1" to do privacy / permission grants that would be great
... when something asks my car of information I want to be able to preprogram my answer (and not be distracted by driving)
... I want to be able to say "No you can't have my license number."
... in your toll booth use case, you said tolls are vehicle type sensitive
... we talk about credentials in a community group; one of the credentials that your vehicle has available is a certified credential about what it is

Kevin: I didn't touch on it but we've had the same thought and discussions.
... we've got sets of use cases that have to do with security, and strongly authenticating and authorizing entities to access data
... one of the issues with our vehicle spec is that you have to be very careful about what can be said, for safety reasons
... but in some situations you might allow some signals to be sent
... we have some assistive driving use cases
... suppose you implemented our spec on as well as off the car
... you've got power steering, power breaks, etc.
... the issue is how to ensure that the steering wheel, brakes, and accelerator only accept signals from credentialed parties
... to avoid dangerous hacks
... so the whole question of access control is key to our success

Judy: People likely to use their phones to pay tolls, etc.
... will you look at credentials of car or person?

Kevin: it's implied that a particular person will have logged in

Judy: what about car rentals?

<Karen> +1 Judy's comment; using another vehicle

Judy: I need to enter my personal information?

Kevin: Good question; we've not discussed it yet (I believe)
... we want the driver experience to be smooth...maybe there could be cloud-based profiles

<mshore> Delegation

Kevin: the off board cloud would have details of your digital wallet

<ShaneM> when talking about rental cars, or indeed any car, a way to register a profile with a vehicle; authenticate with my mobile to the car.

Judy: My second comment - what should we do for coordination between the auto wg and the payments ig

(There is also another loyalty program opportunity with rental cars and credentials for the car)

Kevin: we are in the early days of thinking about how automotive and web payments work together

(Some discussion of ongoing collaboration between the two groups)

Kevin: Although we think vehicles are special ... but we acknowledge in this context that the car is just a device...and you need a seamless experience when people transition contexts
... should "just work" for users

jheuer: One idea is for a car key to be a wallet

Kevin: in practice you would not likely unregister the ability of the car to use your wallet on your behalf.
... as I see it, the wallet is "you" and the car is a mechanism through which you use your wallet

jheuer: the need for authentication is probably the same as we see from the payment world
... on the other hand, the vehicle might be the target of a delegation act
... in case of rental car, for example, gas might be included in price
... or my employer pays for the gas
... so there are a lot of interesting combinations including delegations

mountie: Does the vehicle information API generate data when the car is parked?

Kevin: yes, potentially.

<ted> [there are different actors in use case matrix for payments. who pays? car or fleet owner, driver in one of the various kinds of shared cars scenarios, a passenger. is this a personal or business trip that should cover expenses for miles, gas, tolls]

Kevin: the main issue for automotive, is battery life
... there's a need to keep some systems alive
... even when the car is turned off

mountie: streaming payment is another use case, e.g., pay by minute or by mile

<ted> [parking was seen as one off expense, it could be a subscription if you regularly visit that garage. for fueling it might be a mix of parking and charging fees]

<Erik> IMO, the car should be able to delegate payment authorization to the mobile device. The future of Identity is the mobile device, not the car. The embedded web interface inside the car should be able to delegate authority for the transaction to the trusted authority for the user (ie mobile device)

mountie: if we add pre-authorization (before entering car park, or fuel, etc.) with a combination of streaming payments there are some interesting use cases.

Kevin: Another possible use case is "data plans on cars"

<abramski> @Erik so do you think all WOT's devices the center of the universe is the mobile phone?

<ted> [regarding bidding that was brought up. location based services is something the BG is taking up and we already see nav apps giving drivers gas pricing data nearby]

<Zakim> padler, you wanted to ask if there are plans to add social navigation features for inter-automobile communication?

Kevin: Assisted driving is a rich set of use cases

(Discussion of subscription to event information about what's happening on the road ahead)

Kevin: A long hangs on strong identity
... and you get into trust issues
... can you trust other cars (e.g., in a convoy)
... what trust models will we need?

<Erik> Realtime bidding has been on Wall Street for the last 200 years and in human race for a few thousand years.

<ted> [re license # - publicly visible information - it is being collected in more places than you know** banks/credit card companies are going to want this to back up receipts. we might not be able to control that]

Katie: From an accessibility perspective, user needs and preferences, and the relationship to assisted driving is important

<Erik> @abramski The future of identity is the user's mobile device. Users have already adopted their phone as their source of identity. The mobile should unlock access to other services/devices. I have seen lots of mobile technologies with behavior analysis so the phone knows its user.

Jurgen: For automated driving, the role of "owner" may be replaced to "user".
... could be possible to expand your automotive use cases to broader contexts like public transport

Kevin: Agreed

Nicktr: Binding individual/user to the car....
... we are doing a lot of research on this...
... but there is no regulatory environment currently about a thing being able to make a payment without an associated person
... e.g., things making payments with bitcoin
... exciting but the legal framework is not defined

Capabilities Strategic Reset

Pat Adler presentation on Capabilities Reset

Pat: Payments are like bridges...there's no one answer for building a bridge
... though different they share some features
... Why are capabilities important?
... want to avoid misalignment (cf bridge photo)
... if there are multiple disparate uncoordinated areas

Capabilities important:

• improve communication
• provide context and environmental conditions
• illustrates key principles
• helps IG and broader WG coordinate work
• like the Web Architecture document

(Progress to date)

• IG began work earlier this year
• first draft discussed in June
• work began to formalize it, but in June we began to focus on the charter

scribe: now that the WG is chartered we can return attention to this

(Five types of capabilities)

(Slide: what we want to capture in the capabilities)

Pat: Building blocks

Pat: One goal is to reuse existing blocks

(What's needed to move capabilities forward?)

- validate approach

scribe: if valid...etc.

DavidE: You said you have a space for key deliverables
... one thing that I have labored under...we have a roadmap and capabilities document
... we need to assess how they point to each other

pat: Roadmap is a picture of what work is happening or will happen (who is doing what and when)
... part of IG work is awareness of things in other domains

<Zakim> m4nu, you wanted to mention that most important thing is to get people writing spec text

m4nu: +1 to the approach of the capabilities doc.
... I think the main reason that it stalled was that many of the people who were working on it needed to focus energies elsewhere
... I think the main reason is that we don't have enough resources
... I think a priority of the group should be to wrap up the capabilities doc.

(IJ notes that the capabilities doc, like the use cases, is not likely to be "done" ever)

nicktr: I would like to be able to clearly see which bits of the capabilities are addressed by the WG

<dezell> +1 to ij

dezell: Are we satisfied with capabilities alignment with use cases?

IJ: I am personally ok with rough alignment with use cases...but not with the document overall (e.g., graphics)

pat: We are not married to visual presentation of the concepts
... am happy to hear suggested improvements
... but the key concept is that there are discrete atomic steps that happen
... it becomes simpler if we can talk about interactions between two parties, and chain those together

Erik: I want to underline that there is much more to do.

Pat: the document is more a tool than a reference manual

<nicktr> +1 to padler's comments - the capabilities doc and the use cases doc should be our framework for understanding the state of web payments development

AdrianHB: It would be valuable to understand where the current WG fits into the capabilities picture
... I think there may not be consensus in how it fits into the capabilities

Pat: Agreed. The WG cuts across different domains

Adrian: Assume next work will also cut across domains

Pat: Maybe, or maybe a WG is the primary driver for a domain

Adrian: Do we need another domain for the work of the WG, e.g., "User interactions"

<Zakim> AdrianHB, you wanted to ask where the group sees the current WG domain within these capability domains?

dezell: I think we have a vague feeling that this document is a good thing, but I'm not seeing passion for it.

jheuer: I would add a user-facing block to the model

Erik: Our IG scope is large, perhaps too large
... but the problem is that if we do too many things at once we won't have forward momentum

pat: One of the goals of capabilities is to break the topics into smaller pieces
... I like the idea of patterns...

AdrianHB: If we think about how we got here, we started with use cases and wanted to get to requirements
... this tool is supposed to understand requirements for a payments architecture
... perhaps part of the ambivalence is not that it's not useful, but that it's hard to do properly
... it's a big problem domain and we have more than 100 use cases.
... condensing it into a nice useful set of requirements it's a difficult problem
... it's hard to get passionate about that amount of work

Pat: agree that it's hard to do requirements since there is so much; one goal of the document was to give us a framework for discussions

Adrian: Let's thrash out how we get use cases into the capabilities
... we do need to go through every single use case

Pat, Adrian: Agreed

scribe: and that's a lot of work

(Strong head nodding)

<Zakim> ShaneM, you wanted to continue to volunteer to work on the document. But the group needs to care about it.

ShaneM: I am happy to keep working on it
... but if nobody references it, or we don't keep it fresh, it's not that useful
... if we are to have a public-facing document that is easy to consume, then we need to keep that fresh

<Zakim> m4nu, you wanted to mention how the identity / credentials section got done.

m4nu: I filled out the part on credentials
... I think it's important to have a document in which we can plug in our content

dezell: In our discussion later today I will propose that we need to take a fresh approach to the document.
... if we can come up with a core of people

AdrianHB: Perhaps this is a basis for looking at our task forces
... in some cases we may have CGs, in others we may have task forces within the IG

<Laurent> +1 for Adrian's comment

<padler> +1 to the idea of task force leads as well..

How a Web-based payment system could leverage ISO20022

Kris Ketels Presentation on ISO20022 and the Web

Kris: Goal here is to inform, and to see whether ISO20022 can be useful to w3c

(Slide: The ISO 20022 specification)

scribe: part 1 is a metamodel; how the thing is organized
... then part 3 has modeling guidelines
... part 4 is how you generate XML
... part 6 on message transport characteristics
... part 7 is registration with the ISO20022 RA
... you have to pay if you want to download the 8 parts.
... what the ISO20022 RA has done is create a tool to create messages
... the messages are royalty-free
... for the purposes of this group and submitters, you can use and download the messages and tools free of charge

(Slide: What is ISO20022)

scribe: modeling to reach interop
... ISO 20022 standardizes common objects
... and groups them in syntax-neutral message models
... that can be serialized in a variety of ways (xml and in the future son)

Three layers:

• business / concept
• Logical (message patterns)
• Physical (serialization)

The business process means "the things that are happening in real life...what's a securities payment, how is it settled, etc."

scribe: we don't yet know in detail who is sending what to whom..the business layer is just about what's going on.

The logical layer is about messages so that different parties can execute the business process

Erik: See a href= "https://www.w3.org/2014/09/ISO20022_fordummies.pdf">ISO20022 for Dummies.

Kris: In the repository one finds:

• Business models
• Data dictionary
• Catalog of messages

(Slide: Advantages of ISO20022)

• designed to accommodate new technologies (e.g., new syntaxes)
• global standard to meet local needs

scribe: it's true that if you look at an ISO message, they are by default really long
... you may not need all of that
... each party typically wants to have their say, and that makes messages potentially large
... but in practice the messages use very little information
... ISO20022 has "market practices" that let you refine the messages
... let's you specialize with private data
... ISO 20022 registration process
... anyone may submit to ISO20022....but you need approval from your national body as a submitter
... you can be a standards body
... once you submit a business justification that is approved by the RMG (made up senior people from financial institutions)
... they look at relevance to ISO20022, whether the material exists already

NickTR: Is it a simple majority?
... or can anyone in the RMG veto?

Kris: You cannot veto...simple majority approves submissions

(Slide: Who is using ISO20022)

Kris: there's an app you can download (currently only on iPad but that will change) that shows you the adoption rate.
... how many financial institutions, vendors have adopted sets.
... today more than 60 banks in 27 countries receiving payment initiation messages (close to what we are doing in this WG)

(Slide: ISO20022 in practice...a working example)

(Kris on "domains/business processes")

(Obligation concept)

(transactions and payments)

Kris: Terminology can be a challenge...in ISO20022 terms can have synonyms

(Slide 40 is similar to the Web Payments API draft diagram from the CG)

(Card authorization and completion through an intermediary and agent)

(United States)?

Rouslan: If W3C proposes a change to ISO20022, then which national standards authority would approve it (1st step)? Is it NIST (United States)?

Kris: To become a submitter, you need to be approved by your national standards org.

Rouslan: What would be the national standards body?

Kris: In the US it would be X9.
... but W3C has hosts in different countries

DavidE: There are different avenues potentially available to W3C (e.g., PAS submitter; class D liaison)

Erik: I tried to document payment initiation end-to-end
... ISO had not documented end-to-end
... we need access to areas beyond payments
... ISO20022 when you were protecting pipes themselves
... but on the Internet, we have different data security requirements
... I don't think we can reuse ISO20022 message structure

Kris; I agree. It think this is where ISO ends and other standards begin

scribe: ISO only describes the data exchanged.
... it does not describe the mechanisms that wrap the business methods
... ISO itself only provide the payload; does not specific the security aspect

Erik: We need to add differential controls on a message

Kris: Understood. We have a concept of a business application header
... you can add the header to each bit information including signature (uses W3C DSIG in fact)

scribe: you can sign portions of a document or an entire document
... encryption and encoding not part of ISO20022

nick_s: I know we talked about suggesting additions to the standard.
... do national bodies have the right of veto to a proposed change to message
... how are they voted upon?

Kris; If you submit a business justification, you get to start working on on them.

scribe: they are approved by a standards evaluation group (SEG)
... there are 5 SEGs in ISO20022
... each SEG includes domain experts and determine whether they meet the technical ISO20022 criteria
... whether they are within the realm of ISO20022
... you can become part of the SEGs as well.
... they approve or disapprove the set of messages...they can disapprove with suggestions for changes

Kris: the national body's role is approving you as a submitter; not your submission

nick_s: One concern I have wrt ISO standards .... in the past there have been issues of government bodies and people in the WGs having disagreements and the standards becoming corrupted. I would not want that to happen; it may be less relevant for this group
... It was alleged that NIST weakened a crypto standard. There is therefore wariness in some circles therefore
... but it sounds in this case that there is a different flow.

Kevin: Note the difference between processes for changing ISO20022 itself and changing the data created under ISO20022

Mountie: How long is registration process?

Kris: Typically from inception to deployment can take as much as 1 year
... but in the case of API specifications (e.g., between PSPs and customers) we are planning to shorten the process to a small number of months

Mountie: What is the percentage of acceptance?

Kris: 6000 banks on SWIFT are using ISO20022

<Zakim> dezell, you wanted to ask how to work with "acceptor"

Dezell: We are hoping you can help us get documentation.

Kris: I wanted to conclude with a slide on "how can we collaborate"
... ISO20022 has not been in the space yet you are in.
... but a lot of what you are doing is already in ISO20022...it's a pot of gold that you can use to create whatever you need
... most of what you need is already in there
... but what is not there, I think this group should submit to ISO
... also the TSG is working to extend ISO20022 spec to contain API calls
... we don't have yet JSON or RESTful design
... we don't have all the expertise in our group, but I think W3C has it
... if we can collaborate, that will ensure that a Web payment if submitted to ISO20022 we can ensure that it's compliant with whatever ISO20022 is doing
... and that will improve interoperability for all
... this IG can influence how these APIs calls could look

Adrian: The opportunity for us in the WG is not to try to figure out how to use ISO20022 messages, but rather how to produce messages that are easy for PSPs to turn into ISO20022 messages

scribe: when we built our messages, those are likely to end up at PSP and we can make their lives easier by considering ISO20022 in how we structure messages

scribe: also, as Kris alluded, I think we can play a rule in webifying ISO20022 messages
... e.g., JSON creation, advising on API best practices
... I think the latter is more of IG work

Interledger Community Group

Evan Schwartz and Stefan Thomas presentation on Interledger (ILP)

<zkoch> +1 to cat videos

<Ian> "Relaying and routing"

"Ledgers Track Accounts and Balances"

Moving money within a system works very well... within a single "ledger"

You need a system in the middle - a connector - to connect different ledgers.

"Connectors Correlate Transfers on 2+ Ledgers"

"What happens if the connector drops it?"

Today each transfer in a sequence is a blind transfer. There is no insight.

Today there is no guarantee that the money will make it to the other end.

"We need Atomicity"

Either everything happens or nothing happens.

"We use escrow and notaries to provide the atomicity"

Use "two-phase commit". And you need a transaction leader...

"Atomic Payments"

Payment initiator puts their funds on hold - in "escrow"

Receiver puts corresponding funds on hold.

Once everything is in escrow, receiver sends a receipt and we have done our payment.

"And without Notaries?"

Notaries have to be trusted by all parties. That might be a challenge.

"Universal mode"

instead of using Notaries, use a reverse execution order.

Everyone escrows money. When everyone agrees, it goes through. Otherwise it rolls back.

When the recipient says "I have the money" via a receipt, they get the money.

<Ian> Aha, incentives

Bank tells senders bank they have the receipt from the recipient.

Sender's bank then delivers the money to senders bank.

Then the receipt gets put into the sender's ledger.

"This enables money to be securely relayed"

<Ian> Q, Is it possible to send a receipt and not get money?

<Ian> A. No. Receipt means "I got money"

scribe: it means it will happen as soon as the recipient issues a receipt.

As long as there is some path of connection, we can make it happen

Risk free for the sender and the recipient.

<Ian> Would enable Micropayments

Scalable to any volume of payments. You can just add more connections between systems.

Can connect very different systems. Even fundamentally very very different systems. Minimal requirements to make secure transfers across them.

<Ian> Minimum functionality needed is cryptographic escrow functionality

(graphical demo)

<Ian> Three phases: (1) proposed (2) prepared (3) executed [in reverse order]

Demo was universal mode

None of the participants in Universal mode trusts anyone other than their own ledger

You don't need to trust anyone else in the chain (to do anything except securely transact)

The demo was an actual implementation.

kris: With the notaries, do the notaries need to act with each other?

Stefan: Yes. There is a protocol and they need to use to get to yes or no.

<Ian> (Binary protocol)

kris: Once everyone has agreed, why do we go in reverse order?

Evan: If we do it in reverse order we use the incentive of the connectors to ensure the receipt gets passed all the way back. In reverse order the party that stands to lose has to pass on the message.

Ian: There are two modes. What are the scenarios in which the trusted mode will be used?

Evan: Trusted mode there is a cost of hiring the notaries. And you might not find enough.

scribe: in Universal mode, the cost will be on the connector implementation because the Recipient will have gotten their money and the Sender will not have lost their money. The connector will be out money.

Ian: So when will we use Atomic mode?

Evan: consider banks. Banks might want to do this because it is more like their traditional models.

scribe: in the more open web environment, there might be insufficient overlap of notaries. So in that mode Universal would still work.

The innovation of Universal mode is that the connector is taking the risk.

Universal aligns the risk / mitigation of the risk with who stands to lose. There is no need for piles of money on hold at correspondent banks.

If ledgers function well, no network connectivity problems, there is little risk.

Assume that most players in the system have a ledger is realtime.

If any party is a slow ledger bank then there are ways to build that into the exchange.

Laurent: realtime transaction system between two parties. e.g., TCP/IP. Does the protocol know how to route through the connections when there is no direct link.

<Ian> "iterative deepening depth-first search"

Could look at how routing on the internet works for inspiration.

Routing is one of the things that will be talked about in the community group.

<Ian> (Join the inter ledger CG)

Start with something, improve over time

Laurent: Who is the actor who handles regulatory constraints?

Answer - there is some standardization on that side. But corresponding banks already deal with this today.

scribe: there are compliance rules for third party routing of money that will allow implementation within a country.

<kris> kris whispers to zakim that he should open the queue again ;)

Today the system has no way to prevent a component of the chain from sending money somewhere that is prohibited.

This system has an inbuilt way to have each bank looking at the path to ensure that the money goes through only places it can.

Laurent: How is the exchange of currencies handled?

Answer - Connectors will offer rates.

scribe: there will be competition.

<Zakim> m4nu, you wanted to ask about what this group would need to change to support Interledger. and to ask if there are plans to create a standard ledger format

m4nu: What does the WPWG need to do in phase I so that this can be integrated quickly?
... currently we need to match payment instruments? Is ILP going to show up as another instrument? Or is this in the background?

Answer - We already distinguish between types of instruments. From WP perspective don't need to change much, but keep the distinction between domain and non domain based.

scribe: also anticipate schemes where maybe things are more instantaneous in the future.
... Some other way to pay for web requests.

m4nu: are you trying to create a standard ledger format?
... some people have asked when W3C is going to do this?

Answer - We have a ledger that uses some API. It is not the best that it could be. If it not really our purpose. It might be explored in the community group.

scribe: some others might find it useful.
... it isn't required to make it work.

<Ian> Evan: Minimal thing that's necessary for this is crypto for receipt signature to unlock escrow

Erik: Where does XRP play a role?

Evan: It doesn't. Or is not required. We have demoed through it.

Erik: There are difficulties about situations where trust is not transitive. Also, you will need to support smart contracts.

<Zakim> padler, you wanted to ask about what information needs to be provided to payer to identify payment address of payee...

Stefan: A crypotgraphic signature is the simplest form of smart contract.

padler: What information needs to be shared from the recipient to the sender in order to initiate the transaction?
... Second question: Does this also work with debit pull scenarios?

<Erik> Erik: Trust isn't transitive across different networks. Where does XRP fall into the scheme of things?

Stefan: What the recipient needs to share what they would consider as payment? This amount on this ledger, or this amount or another ledger. Either way I will consider the invoice paid.

<Erik> Erik: I have been talking about cryptographic escrow services with Ethereum for a couple years now, but I believe you need smart contracts to make this successful. This means you need trusted oracles, such as pricing feeds, exchange rates, even USPS confirmation of delivery of packages. A lot of manual KYC/AML issues as value transitions across different networks. This will increase fees. Bad actors in the chain really increases risk.

Stefan: The recipient then verifies that their request was satisfied.

Evan: The difference between debit pull and this is just who initiates.

Gan: Intermediaries might charge fees. Are those fees known?

Evan: Yes.

<Melinda> This is where multisig comes into play. Can’t really do escrow without it.

Katie: That was my question. Do we know what the fees are up front.

jheuer: Every operator and every bank has started their TSM to avoid the man in the middle issue.

Stefan: We have started working with banks. When they want to have their own Connector, then set up a connector directly to the banks they want to talk with.
... more connectors are better.

AdrianHB: The details of joining the CG are on the CG page. There are lots of questions are already on there.

Stefan: We can dive as deep as we want in the CG.

<AdrianHB> Details of joining the CG are on https://interledger.org

<AdrianHB> If you want to do a deeper technical dive on ILP with Stefan and Evan while they are here let me know

Strategic Direction for the IG - Part II

Ian: This is the part where I wanted to wrap up and figure out what we should be doing next.
... distill data about what is in the charter, and what other groups have told us about. The WG may draw off some of the energy from the IG.

Katie: How are we going to communicate the complete set of needs for all stakeholders to the various spin off groups?

Ian: That's the job of the IG.

m4nu: is the IG doing everything that is on the board? Because ILP is already a community group

Ian: Well - even if they are we need to continue working with stakeholders or do higher level architecture work. They can concentrate on the technical stuff.

nicktr: Remember to sign up to the working group.
... love to see you on thursday / friday (instructions on joining)

katie: are we assuming the information about what a CG should do is laid out in the capabilities document?

Ian: The IG is the big picture group for payments. We should develop that information.

padler: ... scribe didn't grok what he was getting at :(
... it cant be everyone's job to look at everything that might be related to web payments.

<padler> to clarify... the suggestion i was making was to have the IG re-visit and reform task forces around capability domains..

ShaneM: Thanks!

<padler> 1 task force per domain..

(Potential tasks on the board; see the Photo of whiteboard)

dezell: Pat was asking how do all these things fit together?
... for example when we worked on charters, we did it at the expense of everything.

Ian: Yes - so let's figure out what we should do.

<Zakim> dezell, you wanted to open a question on staging through capabilities?

Ian: if we focus on charters for 3 other activities, we won't have time to work on Capabilities. For example.

m4nu: PSP may feel threatened by what we are doing. Can we find time to work with them?

Ian: We had a comms activity about this.

Ian: we don't have infinite resources. If everyone said they would help one day a week, we could do everything.

padler: I was suggesting task forces regardless of how much work we are doing. If we organize first, then maybe we can support multiple working groups and CGs.
... that's where the capabilities stuff helps. Have 5 domains, have responsible parties, know to whom to go for specific information.
... does that make sense?

Ian: I like a model of responsibility and ownership. But looking at the WG they have indicated they don't want any task forces. They want some organic growth of the tasks.

padler: I don't think we had any discussion about responsibilities before.

Ian: The task forces were all constituted with leads. Some didn't get off the ground. That might happen again.
... we need to prioritize and to see how much resource we have.

padler: the problem with the charter stuff is that they all look like they could move forward in an incremental way. We could identify champions.

Ian: let's say that we come out of this meeting with tasks. Identify leads. Set milestones over 3 months.
... if after 3 months we are not keeping up with the milestones, we need to revisit.
... let leads do the work and report back. Don't dedicate IG time to tasks we can't fit into the time we have available.

padler: If we decided to do things and asked for a show of hands on who would help... maybe we get people. Identify a lead.

Ian: We can't just say "go off and come back when you are done". We need to set milestones and systematic ways.

kris: What is the scope of the charters?

Ian: No idea. Whoever goes off to do the work needs to come back with that.

kris: is the result of a charter that there is a working group?

Ian: yes.

m4nu: Can we get to prioritization

Katie: We had a phase I and a phase II at the last f2f. Whats up with that?

Ian: the roadmap is out of date. After we reach some conclusions the roadmap will get updated.

dezell: prioritize the charters. ILP is incubating. There's not much we can do. We shouldn't amp up our effort too much. We've been alive for a year and have done some things.
... if we accept more incremental steps people will be able to stay with the program longer. Not get burned out.

Ian: the best way to not burn out is to do the things you care about.
... doing the charter work is not glamorous.
... naturally we are going to have a mix of the mundane and the cool.

Erik: What is the W3C's role on payments?
... we can't standardize the whole universe.

Ian: We decide what W3C should be doing.

Erik: Does ILP fall within W3C's scope?

Ian: Whatever the members bring in and want to work on, we will work on.
... we may push up against a border.

<Zakim> AdrianHB, you wanted to propose a priority for charter prep and discuss scope

AdrianHB: ILP is definitely not ready to start thinking about its charter yet.
... Ecommerce might be a its own thing. Or might be a rechartering of the WPWG.

<padler> + 1 to identity and credential being the #1 scope

AdrianHB: ID&C might not be ready for chartering. Might only be ready for an IG.

Ian: How long until ILP is ready?

AdrianHB: Depends. Maybe six months?

Ian: remember it took us 9 months to get a charter to the AC. We might get better at it.

AdrianHB: ID charter seems like it should be the first priority. ILP might need to start sooner than later. ECommerce could be a follow on to the current WG work.

dezell: How does capabilities fit in?

Ian: We don't know yet. We haven't had the discussion.
... Would anyone want to work on the use cases?

Jurgen: Not all of them. But we need some for ID.

Erik: Someone should own the use cases for each area.

<padler> if identity is the first charter we are interested in, then let's focus on all aspects of identity as a domain...

<high level discussion of what the various candidate tasks might be>

<identifying people to take on tasks>

ISO 20022 liaison work - Kris

Ian: I will work with the responsible party to identify milestones for each task and report those back to the IG

padler: ISO 20022 and ILP feel like big tasks. They might need to by CGs or task forces.
... other things might be smaller tasks that individuals can do.

Ian: I don't know what is going to happen. We don't know what the scope is.

Erik: We need to give each task a set of goals.

Ian: No - let the task lead set up the goals and then the IG can review and approve them.

padler: ISO 20022 is a specific message exchange format. It is an implementation like FIDO is an implementation of ID & C

Ian: But we don't know what will come back from the concerned parties.

m4nu: Pat is saying "I know what the categories are". I am saying "I have no idea".

<Zakim> m4nu, you wanted to make another proposal about identity and credentials.

dezell: I want to make a statement of what I have heard so far:
... we want to do the use cases
... we want to do charters about interledger and ecommerce. Maybe ID&C but with a different name.
... if we ignore comms we are dead. So we need to keep doing that.
... other IG Functions are soft.

Manu volunteered to run Capabilities and ID &C

padler: I would like to coordinate the capabilities document with people who will lead a domain. Rather than Manu deal with all of the capabilities document.

Laurent: Concentrate on charters because the other work will fall out of that (market research, comms)

Ian: There are other tasks that we could be doing outside of the charters. Talking with other groups, reviewing documents, sending comments to other bodies.
... We can't tell a champion what they should do initially. They should suggest the scope.

ECommerce - dezell from capabilities to use cases to beginning the charter work

dezell: I would also keep doing reviews from other groups

Ian: that's not an interest group thing.

Erik: It is if we say it is.

Ian: But we don't issue formal opinions to / for those tasks.
... someone should be monitoring the external activities (ecosystem) and will help the IG understand the technology space.

dezell: We do have a role of commenting in our liaison to WG10
... It is partly about making sure that weird stuff doesn't happen out from under us.

Ian: These things are important but they are resource consuming activities. Like Comms.
... Is there anything else

<Zakim> padler, you wanted to recommend prioritizing domain and charter together...

Erik: The WG is not working on stuff that will add value to core finance. The only things up there that are related to finance are Identity and Security

<Ian> ADJOURNED