W3C

Web Commerce Interest Group

9-10 Nov 2017

Agenda

Attendees

Present
dezell, Ian, ltoth, alyver, Ken, gildas, rodrigo, max, jason, mattsaxon, mohammed, dom, cyril, vkuntz, Amber, Takashi, AdamCrofts, Katie, CyrilV, andre, mdadas, vincentK, lin, wuyaohua, Mark_Tiggas, Bob_Burke, phila, Katie_Haritos-Shea, Manu, GrayTaylor, Tomoyuki_Shimizu, shigeya, Jean-Yves_Rossi, wonsuk, Magda, MarkTiggas, Haritos-Shea, wseltzer, Matt_Stone, Liam_Quin
Chair
David Ezell
Scribe
Ian Jacobs, Ian

Contents


Introduction and Welcome

<Ian> David's Welcome slides.

<Ian> dezell: Welcome to the first meeting of the Web Commerce Interest Group. Co Chairs are David Ezell, Ken Mealey, Dapeng (Max) Liu

<Ian> [David reviews IG activities from the charter]

<Ian> [David reviews IG topics in scope]

<Ian> [Review of goals for the meeting]

<Ian> Scribe: Ian Jacobs

<Ian> [Introductions around the table]

<Ian> [Chairs introduce themselves]

<Ian> Ken: Goal is to set the vision for payments in the organization and establish a roadmap

<Ian> ...I invite you to participate in the meetings today and tomorrow

<Ian> ...we want to hear from you what is interesting, what you can contribute to, what your organization prioritizes

<Ian> Max: I hope also to help bring use cases from China into the IG

Automotive and Web Payments

<Ian> Rodrigo's slides for Automotive and Web Payments

<Ian> Rodrigo: We have started with an automotive payments task force; see the agenda for today's discussion.
... Regulations differ in different places around pay at the pump (e.g., in some places there is a requirement that a person put fuel in the car; tied to job security)
... Our activities in the task force start with building a shared understanding

<Ian> ...then describe use cases (one of them on today's agenda)

<Ian> ...and do a gap analysis to figure out where there is a possibility for the Web to add value (but it might need additional capability)

<Ian> ...note that implementation work is out of scope of this task force

<Ian> [Illustrations of use cases]

<Ian> Use cases in scope include: pay at the pump, tolls, parking, retail point of sale

<Ian> ....some issues to take into account include driver safety, shared vehicles, connectivity challenges

<Ian> ...shared vehicles

<Ian> [Participation]

<Ian> Rodrigo: We are looking across the industry, and also at expertise in different regions to participate

<Ian> Ted: In the Automotive WG we are looking to build a platform for rich experiences in the car, which includes data available from the car

<Ian> ...the car is a LAN

<Ian> ...we expect there to be notifications (e.g., to the user)

<Ian> ...market is split between HTML5 and QT, so we are defining "services" that might be used from other platform

<Ian> [Use cases]

<Ian> Rodrigo: The sense we have from the first calls is to develop use cases around pay at the pump, retail point of sale, and parking. Not all vehicles will have browsers

<ted> scribenick: ted

Ian: we started to dig down on the pay at the pump use case. we intend to work on others but chose this as a priority
... I am not sure if the automotive people in the room are familiar with the W3C Payments API
... it streamlines checkout, securely and this should be applicable for automotive use cases as well
... when you arrive at a gas station, you will be prompted if you want to get gas and go through the same streamlined checkout process (of being presented with payment apps, choosing one, and paying).
... so the use case description asks the question: how do we quickly get the user to a Web site to pay, after which the user will just follow the ordinary Web checkout process. The 'getting the user to the Web page' could happen through a variety of input methods, including QR codes, Bluetooth, NFC, or others. (Right away the question is: are new Web standards needed so that Web apps support these input methods?>)
... the user's system already having the data for a given gas station that can help prevent fraud (eg rogue BT beacon)
... your car can recognize where you are.
... the second initiation flow we looked at started with user location rather than a station-owned device.
... there are some fueling specific components such as preauth before fueling
... to summarize there are two parts: (1) initiate getting the vehicle or phone to a Web site and (2) using Payment Request API from there to pre-auth and the server activates the pump.
... perhaps Dom can elaborate on the Web Bluetooth and Web NFC work taking place at W3C

Dom: we have some experimental APIs available in chrome that are being discussed in CG and we covered them during breakout sessions yesterday
... the other browser vendors were asking for use cases. I think you can provide them

<Ian> dezell: I'd like to express support for the bluetooth/nfc work. Some recent work by a big gas company is to put node.js in every device

jheuer: Pay at the pump is not a use case in Germany according to Deutsche Telekom; money is made from things purchased in the shop

<dom> [in France, most stations offer to credit-card pay at the pump; even those that want you to go the shop]

Ryladog: I am wondering whether you have any idea about whether the proximity is still required for NFC/Bluetooth

Dom: Yes. You only want to trigger the user experience once you are at the pump

jheuer: Bluetooth can be parameterized for longer ranges

Ted: In addition to bluetooth and NFC already being in vehicles there is v2x (vehicle to X *anything, other cars, traffic lights...) work going on ... digital short range comms (DSRC spec work taking place as Society of Automotive Engineers SAE)
... work coming out of NITSA
... I am going to a US DOE & DOT workshop this month and will hear more about what's they will be recommending for EV charging

Ryladog: Can we look at driverless car use cases?

Ted: These use cases are likely to be the same from payments perspective

AdrianHB: I noticed in the use case list that non-interactive payments are not a priority yet.
... is there some reason?

Ian: Nobody has spoken up yet

AdrianHB: There could be a number of non-interactive use cases related to cars

Dom: How does payment request work for non-interactive payments?

AdrianHB: That's under investigation ... using, for example, HTTP with the same data model (for a payment request)

Dom: When does user consent in non-interactive?

AdrianHB: That would be preconfigured, e.g., a budget for parking

Dom: And bound to a specific origin?

AdrianHB: Rules might be outside the scope of the API

Ted: E.g., if you run over your parking, your car could make another payment before you have gotten a ticket.

Matt: We pushed tolls down in the prioritization list...they are largely driven by municipalities...if we have people with payment methods, we can have that conversation
... Parking is consumer intent
... you can have an open-ended purchase model with parking to achieve Ted's goal

<ted> Ian: there are also various toll use cases where promises would be acceptable, you can be identified based on your license plate or have one of several NFC solutions

dezell: 2-second distraction window is a part of automotive interaction

Patrick Kettner Where is the work for the http rest payment api to be found?

Patrick Kettner: Will work of HTTP based payment be at IETF?

AdrianHB: HTTP Bis would be responsible for approving a binding to HTTP
... The payment request data format would be a deliverable of the WPWG
... other protocol bindings might happen in other venues

Ted: I agree that automated payments via HTTP will be useful

MattS: I am looking through the flows....when you pay for fuel in the UK, you pre-auth

Ian: the reason the flows don't represent preauth yet is I am not sure yet how it is different In the card swipe approach there is only the one user interaction. they payment provider handles the rest.

MattS: Pre-auth is handled by card networks, but other payment methods may not function the same

Ian: I welcome your help in adjusting the flow description

jgipson: In the US, there are scenarios where, depending on the type of card (e.g., debit) you need to authorize via zip code. and that creates a hold on the account...that hold is temporary.

Matt: This assumes stations would accept other forms of payment
... if you want an alternative form of payment, you need the merchant entity to acquire

MattS: Presumably you want the standard to enable tht

dezell: While the initiation of payment may be automatic, there will be pushback where there is a need for more information.
... that will have to be handled.
... and those roles change from time to time

Ted: We thus need to be careful because the rules might change following our design.

Ken: I wanted to offer up a separate point of view regarding rules
... Brands can make rule adjustments that are use case-specific

jgipson: +1 to what Ken said. We are participating in sessions like this in order to understand what business models are enabled and figure out how to support them
... how is payments landscape getting in the way of innovation? We'd like to address those.

Matt: We'd like to also understand in more detail how the user's device can help them with things like authentication

Ted: I understand and appreciate the payment provider position on this, having just suffered from a card skimming recently

dezell: One word about mobile payments in the petro industry - we do have some success stories, but they have been in closed systems. We are also interested in the role of loyalty in automotive payments

ltoth: Connexxus has a white paper about payments in petroleum
... that might explain the flows

Ted This also emphasizes the need for this joint task force and we would understand if a new widespread fraud practice necessitates breaking this temporarily until a revised solution is made

<ted> Ian: next steps

<ted> … we will continue to hold our weekly teleconferences and will adjust our flow based on today's feedback

<ted> … we especially want implementers involved and giving us their input

<ted> calls are weekly, Thursday at 9EDT

IOT Payments

Michael McCool slides and minutes from yesterday's breakout session on IOT.

McCool: IOT is a big space, where different industries have different requirements
... how can W3C contribute to IOT without adding to the confusion of IOT standards?
... WOT is about interop across IOT silos (that is: different standardization stacks)
... to enable applications that can use IOT services from different stacks
... WOT standardizes on metadata
... the Web of Things WG approach is to use Web semantics via JSON-LD, so it can be used by those who want to do more semantics or less semantics
... for IOT payments, one question is then: what metadata does a device need to communicate in order for a party to be able to pay that device?

magda: When is this going to CR?

McCool: Charter says end of 2018...I think this might be a bit ambitious but we will see. Our repo has more information aobut the WOT Architecture and WOT Security. See also Web of Things (WoT) Security and Privacy Considerations.

AdrianHB: WOT is defining metadata descriptions. One of those things could be "this is how you pay this service" and "this is what you get after"
... There are two aspects: (a) advertising a service (b) data model
... want secure transactions for both
... another thing that came up in discussion yesterday: what assumptions have we (in the Web Payments WG) made so far around payments, and what does not hold in IOT space?
... e.g., payment may be automatic, without a user logging in to some user experience

McCool: Regarding notification - one thing we are looking at a lot is event-driven notifications
... this is a common theme in IOT where we are struggling with the HTTP model.
... another idea is to use a link; follow the link to get more information
... so you may not have all the metadata up front but rather follow a link for more information
... need to continue to look at other scenarios and see what we need to adjust (if anything)
... we should reuse standards as much as possible and only do new work if needed

Ken: Thank you for the update. What level of activity do you see in the industry? Momentum level?

McCool: IOT generally is not taking off as fast as people thought (though still exponential growth)
... it's quite healthy just not exploding as anticipated.
... one of the inhibitors to that growth is lack of interop
... so standards can help
... in terms of W3C's role, I think we have to do more work to get more engagement with W3C in this space
... WOT is not as mature as other standards in this space
... other groups are in their 2nd or 3rd iteration...but even the larger bodies (e.g., OCF) do not have a lot of shipping devices yet
... so it's still early days
... some of what we do see shipping has bad design and security
... we are going to face the fact that people are not going to want to remove installed devices
... we need to bridge them into more secure systems
... we do see some consolidation among standards, which is good
... but we won't see complete consolidation because there are too many areas or types of requirements.
... factories have real-time requirements, health has regulatory requirements and privacy, home requires ease of use, etc.
... so because the space is diverse, we're going to see some silos, but you will also see a desire to integrate devices from diverse spaces
... e.g., in a hotel you may want to control the temp of your room from your TV...how do you do that?

Magda: Who is complaining about lack of standards and who would benefit the most in your opinion?

McCool: System integrators
... also vendors who cannot sell products because it's too hard to install / integrate systems

dezell: Beyond payments, are there commerce use cases you have considered?

McCool: One is physical commerce - I push a button and get something (e.g., vending machine)
... there's also informational type things (e.g., I order an ebook)...for these use cases I can use the Web
... there are also services (e.g., I may be in a mall and want to know where my children are...I could sign up for a service to help me with that)

kaz: We discussed choreography yesterday
... the main use case so far is interconnection of devices that have been provided by diverse companies
... one use case that came up was around transportation (bus)

McCool: Authentication is another topic
... I want to be able to discover things and connect with authorizations
... ideally I would not get metadata of things I do not have the right to use
... there's another topic - onboarding/provisioning
... we did a plug-fest yesterday (see slides) ... but we have yet to deeply tackle the authentication and authorization issues.

[Presentation by Tara from Amex]

Tara: Within the Amex network group we are interested in emerging technologies such as IoT
... I wanted to share with you how the payments industry is thinking about how these technologies
... By 2020, 50B connected devices anticipated
... when we think about IoT we think about anything, anywhere, anyone, and any network
... our first question is "do consumers want this?"
... at a high level consumers want to simplify parts of their life, and see IOT as a way to facilitate that...but fraud is a big worry
... What does WoT mean for payments? Anything can be used to initiate a payment, anywhere (in the home, at the store, at the playground, etc.)
... we need to empower acceptance, both online and offline
... How will we pay tomorrow? Invisible payments
... where should payment conversation appear or be invisible?
... times where conversation interesting include loyalty or lending
... Topics we need to consider:

Tara: How do we ensure a device is the device we expect (and hasn't been compromised)?
... We need standards to avoid silos
... Some questions - how do we create digital identity?
... is that standardized or proprietary?
... How do we eliminate friction except where it's desired?
... what is the total value proposition to customers?
... Where is standardization useful?
... E.g., there may be valuable in standard payment APIs or SDKs

nicktr: Thank you for the presentation. One of the research topics at Worldpay is how to you make a payment when there is no human proximate to the device. (See Worldpay-commissioned report: Are consumers ready for the Internet of Things (IoT)?)
... are you looking at use cases where there's not a human being within a few steps of a machine?
... how do machines make payments autonomously among themselves?

Tara: You can have a discussion about AI...another area is "card on file"
... where payments are treated as a form of recurring payment

NickTR: The autonomous machine work is interesting....one issue we wrestle with is when machines become REALLY autonomous and something goes wrong...who bears the liability in such a case?

Tara: There is a question of policy and how we create our risk algorithms
... a lot of the networks are investing in machine learning to help with updates
... I expect we will get to a point where there are predictive capabilities to prevent the sort of scenario you describe.

<McCool> McCool: an example of the above could be very simple: a rental device where charges are by use

Ken: For a company like Amex, one of the things that is important has been service to cardholders. We wrestle with how to address the sort of scenario Nick described in terms of customer impact

Max: Thank you for the presentation. Some thoughts on the future...
... one goal is to make payment easier (e.g., Uber). You don't need to authenticate during the ride
... another example in China is mobile payment....very convenient...
...new payment scenarios will also include virtual reality payments

Young: If I store certain payment credentials on a device and I move or sell a device...what happens? You need to think about those from a customer service perspective.

Tara: You could have a card on file with your device
... token deactivation is a direction we are thinking through

matt_Miller: Two use cases: (1) you give your card to someone (2) card on file
... I think we are not reinventing the wheel on payments; it's an issue of permissions
... we can be more explicit about permissions
... another challenge of IOT is micropayments
... I think a standard in that gap would be valuable

Tara: I think fraud becomes an important component of this conversation
... how much standardization is appropriate around fraud?
... each issuer or network is likely to have proprietary algorithms, but standards for getting data could be valuable.
... another area of interest is a use case like a one time payment from somebody to a device (e.g., mom sends cash to my car at the pump)

AdrianHB: What are the next steps?
... in the previous session we talked about non-interactive payments
... my personal opinion is that when I am at the IETF next week I would like to see "join the following list for the conversation"

McCool: I think we won't look closely at payments in the WOT WG until we've advanced the existing specs further
... so perhaps a better home for payments and IOT is the IG...and I'm happy to participate in the task force

AdrianHB: I'd like to propose that we create a task force non-interactive payments in the IG
... I suggest we start with a mailing list in the IG and if there is sufficient interest we start to meet by phone

<scribe> ACTION: Ian to create a mailing list for ongoing discussion of IOT payments

<nicktr> Participants might also be interested in this - it's a prototype SDK for payments and IOT. It's available under the MIT licence.

Merchant Perpective on Digital Offers

dezell: This session is on perspectives from merchants, primarily around digital offers

Linda Toth Presentation

Linda Toth Slides

ltoth: Historically convenience stores have not done coupons well...
... coupons are more about planned events than impulse purchases
... and POS don't typically have capabilities to get databases to validate coupons
... but what we have done well is promotions (e.g., "buy 1 get 1 free")
... and we have been successful with loyalty (e.g., partnerships)
... we also sell age-restricted products
... Our merchants have embraced mobile apps, but not web
... we typically use closed-loop systems
... convenience store interfaces with loyalty host and also payment host
... Conexxus has standards for loyalty interactions, payment interactions, and mobile access
... how can W3C help?

[Background on digital offer community group]

Gray Taylor Presentation

Gray Taylor slides

gray: we live in the age of consumer technology
... our clients are "time-starved and mobile"
... powerfully automated
... always connected
... believe in knowledge on demand
... seeking simplicity in a complex world
... the consumer now "owns" our technology
... consistency of UI is important
... samsung pay, apple pay, google pay have been disappointing, which we'll talk about
... we have to play in modern technology but connect to legacy technologies; standards help
... convenience is the absence of friction

[Moving toward the future]

Gray: people only have 2 merchant apps on their phone on avg...web gives way to reach customers through browser
... Mobile payments have not taken off
... only 5% are frequent mobile payment users
... number one user is that it's easier to pay with a card

[Promotional confusion]

Gray: complexity of spending points (need card in hand)
... we have created "inconvenient stores"
... cool stuff but that you can't use.

[Technologies that will make a difference]

nicktr: I'm skeptical that 5G will make fixed landline go away.
... I think in the UK it will be enabled by meshing
... regarding the accuracy of GPS, I think we are a long way from that level of indoor GPS accuracy

Gray: Indoors it may not be as accurate.....

NickTR: telco providers can do 6" resolution

Gray: Foursquare is doing predictive resolution

jheuer: I think fixed lines will continue for a while longer

[Customer commerce environment slide]

Ryladog: In-home GPS has been available for years

Gray: Customers have preferences, history, and identity
... Merchants have coupons, POS link, and loyalty program
... Payment providers have: accounts, promotions
... CPGs have coupons, loyalty

Amber Walls (GS1) Presentation

Amber Walls Slides

Amber: users should be able to obtain an offer through any channel and redeem in store or online without issue. Systems need to be able to capture info needed to properly validate and track savings transactions across platforms
... minimize fraud

[Use case: consumer discovers offer in a magazine and associates it with an app/mobile wallet]

Amber: JICC current focus is brick and mortar, but keeping in mind other channels

Phila: I joined GS1 in July (former W3C staff)
... GS1 as an organization is well-aware of these trends and the importance of being online
... we don't have a single database where you can look up any bar code and tell what it is yet - but we're working on it
... some directions:

PhilA: However, backwards compatibility with legacy systems is still necessary

Laura Townsend (MAG) Presentation

Laura Townsend Slides

LauraT: We have about 130 merchants who are MAG Members
... our focus is on payments matters
... we work closely with Conexxus.
... anywhere there is a valuable to sharing our perspective, we are happy to do so
... some use cases:
... in talking with some of the merchants, the way currently that manufacturer coupons (in digital space) is "1-to-1"
... Take Target...they can clip a coupon in the Target app but that coupon may not be usable at another merchant
... what we would like is interop so that consumers can use coupons of manufacturers at multiple retailers
... the JICC is still working to align on topics like controls and best practices

[Review of potential workflow]

Laura: Some validation in the flow
... The standard would mean merchants don't have to adopt multiple formats

Amber: The Bureau will store info and push to the retailer....offers will be real-time and can be controlled to reduce fraud

jheuer: Are semantics visible to customers or opaque within the system?

Laura: Those details have not been defined. The merchant would definitely want to have some capability to access data to help drive adoption

Amber: The details for an offer we plan to store in the bureau
... but merchants will be able to enact existing coupon validation on top of that

ltoth: How do you envision the bureau being provisioned? Is it an aggregator or a broker, or will it be a new entity?

Amber: Likely to be a new entity.

IJ: Why a central repository? And perhaps more importantly: if there's a central repository, what role does a standards body play since the central authority will determine how to interact with it?

Amber: Allow to be real-time and integrate with existing retailer technologies

Laura: As a merchant, when you look at how you interact, to me this looks like I will communicate with a bureau..is that a value add as well?
... One challenge merchants face today is the ability to provide an offer based on payment type
... merchants may want to partner with payment company and include offers when that payment method is used
... but in checkout flows today, the last thing you do is select a payment method
... is there a way to highlight promotional opportunities available after selection of a payment type?
... merchants also want to foster relationship with customer

[Offer/disount bureau system use case slide]

Laura: Merchants want to "get credit" for different opportunities they provide to their customers
... so we want to enhance the customer relationship

Hubert Williams (Maverick) Presentation

Hubert Williams Slides

Hubert: Maverick digital offers wishlist
... We would like to see a set of standards by which manufacturer, third-party, or company one-time-use coupons or other digital offers can be issued and redeemed.
... We see trigger events as the key to usage
... we would like to be able to issue one-time-use coupons via a trigger: loyalty account use, or promotion, or date-based event, or based on market basket analysis to modify buying behavior
... we also need rules in place to be able to exempt a customer from a coupon or offer.

dezell: One of the most important issues to us may be one-time use restriction
... this is a difficult-to-achieve goal

Hubert: For us to be able to get use out of a coupon, we need to be able to identify who used it.
... regarding constraints and restrictions: age, customer opt-out, customer preferences, local ordinances

[rules enforcement]

[Hubert has to leave meeting]

Bob Burke (KouponMedia) Presentation

Bob Burke Slides

Proposed approach:

Bob: Closed loop - issuer and clearing agenda are the same

dezell: Use cases for discussion:

Phila: I am willing to explore joint GS1/W3C effort in this space

Manu: A lot of the offer flow we saw today maps cleanly to the verifiable claims WG flow
... people can experiment with polyfill
... we need help from the industry on what the data model would look like
... we can start prototyping

Blockchain CG update

Mountie Lee Slides

Mountie: Several topics that have been discussed in the Blockchain CG. One is QR codes.
...encoding is not a problem.
... decoding is the challenge
... Web does not support QR code....QR codes are used for bitcoin payments
... some use cases - construct a payment request with QR code
... another one is "desktop support for QR code"

IJ: What does it mean that the Web does not support QR codes?
... web page can use camera and JS library to decode
... also, regarding native browser support for QR code decoding, when I last asked some browser vendors there was not much interest due to the ability to do this in javascript libraries. Perhaps that has changed; I don't know.

[Next topic: formatting small numbers]

Mountie: The blockchain CG is talking about formatting for small numbers.
... formatting bitcoin numbers which are long would be valuable

Patrick Kettner: ECMA has been looking at some new number types

IJ: Not sure there are any places for CSS to hook into either

[Bitcoin payments]

IJ: We can do bitcoin for ecommerce with PR API. Harder is P2P.

Patrick Kettner: One idea is for user A to show QR code to user B and then payment happens via a server
... if we want true p2p, browsers would have to have built-in knowledge of blockchains, and we would communicate that way

Telcos and Payments

Meeting resumes 10 November

Ian Jacobs Slides on Telcos and Web Payments

Ian: Dom Hazael-Massieux is W3C's Mobile Web person
... has been looking at how the Web platform can be used on mobile devices
... with web payments arriving there, we're looking at opportunities for telcos
... we'll review the payment request API flow and identify possible opportunities today in that flow
... and look into possible future opportunities
... this is a high level view of the payment request API: the user initiates this browser-based experience
... some of the ways Dom and I have understood through discussions with telcos telcos play a role in this flow:
... a merchant might, for example, declare they accept a mobile money payment method, or a carrier billing payment method
... another piece later in the flow is at time of authentication where e.g. mobile connect might be used
... We'll be diving into these 2 types of opportunities
... because of what we've heard about requirements emerging from e.g. PSD2, the requirements for strong auth are increasing
... operators have led systems in this field e.g. bankId, Verimi, Mobile Connect, etc
... This leds us to raise questions on the relationship of these systems with W3C
... we would be interested to understand the take of operators on FIDO and by extension WebAuthN

Mohammed: we're very interested in authentication.
... mobile connect is what we're deploying today
... and what we would like to see addressed in W3C
... we gave a presentation on the topic last year at TPAC
... this gives a strong use case for mobile connect
... we have already for Orange deployed payment services on mobile money
... it's interesting for us to see how to re-use or at least align with what W3C is providing

Qitao: before mobile connect, I can reflect on BankId
... BankId is almost close to a failure story, but ended up with a success
... the promise is strong authentication with ease of use
... we should always have the user in mind - what is adding value to the user
... On Mobile Connect is one standard for telcos
... in some conditions, Mobile Connect can be used as a payment solution
... Mobile Connect is one API common to all telcos
... The goal is to get it deployed globally to all operators in GSMA
... depending on operators, it may be easier or harder to deploy
... the integration cost to the end user need to be kept in mind
... some users only need a mobile phone to make a payment

Ian: what's the alignment between FIDO and mobile connect? complementary? in competition?

Mohammed: they're complementing each other; the market will determine the winner

Ian: in the payment workflow, where the user as a payment app
... do telcos have a business driver to provide payment apps?
... is that something for telcos or other parties?

Mohammed: Orange is present in many countries; depending on the country we can operate in different manners depending on the license
... sometimes only network access, sometimes only services, sometimes both
... also, depending on the countries, the level of infrastructure varies a lot
... so we can't have a uniform deployment of services
... in some places, we need to provide everything, in other case we need to align with the specific circumstances
... we have in-house solutions for payments on mobile, fixed, TV
... but we also rely on other providers depending on the market
... the key question is interop

Qitao: agree with Mohammed
... different markets are very different
... e.g., Asia is very different from Europe
... and Eastern Europe is different from Northern Europe

Jean-Yves: we are often facing 2 issues: PSD2 and interop
... re PSD2, we can't expect the so-called regulatory technical standards to be known before mid 2019 - quite long from now
... the current situation in Europe is that specific solutions are mainly brought by national banks and their organizations
... in some countries, very efficient authentication systems have been established
... but they lack cross-country interop
... we really need to be able to mix 2 different periods: the upcoming period will be driven by the adoption of common standards - but not before 2 years from now
... we need to have the design of the payment request API able to open ways to design a kind of interop - e.g. to make federation possible for authentication
... going back to the UML diagram
... one of my questions is how could we design something to be able to get from the very beginning of the process some kind of user authentication and to keep it along the process
... this could be very useful in use cases in which identity could be checked early in the process and be kept along the process

Ian: today, you authenticate to different parties - to the merchant if you have an account (e.g., for loyalty)
... and you'll authenticate to the payment app provider for the payment
... each relationship is authenticated and data flows when you make the payment
... what needs to change in that picture?

jean-yves: the entities you are describing are payment service providers
... you have also use cases where the merchant has established relationships with existing payment service providers
... in such cases, to offer seamless UX, it could be very useful to be able to create some kind of federation of identity / authentication from the very beginning of the session
... and use this kind of initial auth at the final step of payment in the flow

mohammed: the idea is to avoid a new authentication step via federation
... I suggest that using your mobile phone is a good approach to this

Ian: in September, I heard FIDO indicate they're working on caching authentication tokens
... Moving on the next topic
... Peer-to-peer payments
... they have a growing popularity
... we had discussed Mobile Money payment method with GSMA
... Right now PaymentRequest assumes a client/server model with a traditional use of browser to submit data to a server
... WebRTC may make it possible to create browser-to-browser payments
... that would move us away from the client/server payment request model
... I wanted to hear the sense of the room on the important of P2P payments; hear about Mobile Money

Dom: WebRTC can provide a transport layer for browser-to-browser exchange of payment payloads. I assume the payment mechanism itself would live in the browser, but as you said it's a very different model than the client-server ecosystem

Adrian: for me, PaymentRequest API is a payment initiation tool, not a payment processing tool
... so it applies to any use case where a payment is requested
... the traditional Web model is client/server, so that's how payment request naturally applies
... but RTC changes this
... P2P payments could also be mediated by a server
... I agree it's a use case worth exploring
... if we explore this, we're likely to find shortfalls, e.g. user gesture requirements might bring subtleties
... I think a proof of concept would teach us what these are

Ian: I have been discussing a QR code-based demo with Samsung
... Anyone has input on how W3C can help support some of these payments without apps?

<Ian> [No response to questions about P2P]

Adrian: As Payment Request API becomes more ubiquitous, and P2P payment methods emerge, this will become clearer
... e.g. integration of P2P payments in chats - e.g. SlackPay

Mohammed: today, we have already some network APIs that enable P2P payments
... it is a good thing for us - bringing this to W3C as Web APIs it would be interesting
... the main worry is if there is divergence

Adrian: Payment Request doesn't bring new payment methods, it also initiates these

Ian: we haven't had discussion around using WebRTC as transport to payment requests
... Moving on to Carrier billing
... Providing a method for carrier billing: does that make sense?

Mohammed: any payment method should be possible included in the payment request API
... this is a payment method we have been running for years
... depending on the carriers, they may not want to be reachable from outside their environment

Dom: how do we make it happen? How do you see it emerging? Should that happen in W3C?

Mohammed: Orange Partners has all the information on what parameters are needed
... Carrier billing is widely used today in gaming, video-on-demand, on-line services

Dom: PR API can be used today to do gaming purchases, etc.
... that's why I'm asking - Payment Request is being deployed with basic card but other payment methods are in development
...when and where should the carrier billing payment method be developed?
...if carrier billing is not an option to users, it won't be used by users

Mohammed: Extending in other areas will depend on market pull. Let's chat more via GSMA

Dom: Do you see an opportunity?

Mohammed: Yes.

Qitao: I agree this is best taken up with GSMA

Ian: we've covered topics grounded in Payment Request related to telcos
... There are other topics for future opps
... around fraud mitigation, identity services possibly supported by verifiable clims? secure hardware?

Dom: Edge computing is an illustration of how PR API enables operators to monetize service
...PR API reduces friction considerably and may make business opportunities that would be difficult or impossible today, possible tomorrow.
...there's lots of discussion in the telco industry about how to provide VAS to customers
...I was imagining for edge computing making it easier to pay for just-time-services
...this is more an illustration than a specific use case...what new opportunities for business in light of easier payments.

Ian: Would telcos also be interesting as connecors in an interlegder protocol?

Adrian: in terms of the protocol definition, there are 4 roles, incl connector (equivalent of a gateway), ledgers, senders, receivers the role of mobile operators would be more as agents of senders or receivers as we explored in our project with the Gates foundation. I can go in some more details in my session on interledger, but I see operators more into the role of agent of senders/receivers rather than connectors

Ian: this is the IG and we're looking for new opportunities
... are any of these topics appealing to telcos as next steps for W3C to look into?

Mohammed: Edge computing provisioning interesting; verifiable claims and interledgers are interesting to Orange

Qitao: I think operators have something to work with on Verifiable Claims based on their existing data; but I'm not sure how

Ken: I have ten years of payment request, but before that, was 16 years in telco
... several years ago when Amex was trying to figure out mobile payments, we were going through that cycle by storing credentials on the secure element
... Google came out with KitKat HCE specification, and that really changed the dynamics of the industry
... Telefonica was charging 8€ to store credentials in the secure element, much higher rate than anything gets paid in the payment ecosystem
... that slowed down considerably the interest of the payment industry to work with the telco industry
... there is still lots of agreement that the secure element is the best solution to store credentials securely
... so there is still an opportunity to take advantage of this
... I think Global Platform is a great place to continue that exploration
... if we could take advantage of TEE and other security platforms from Globa Platform by bringing them into W3C work for We based solution, this could be a path forward
... this could be controversial, but would like to open up that path

Mohammed: I fully agree with you - there are opportunities, esp around the secure elements including in SIM cards
... Orange is very active in Global Platform
... I would be very supportive of aligning w3c work with it if we find path toward that
... Orange is now doing banking

Qitao: Telenor is not involved in Global Platform at this point

dezell: I just wanted to add - my previous experience with Global Platform
... I think there is huge opportunity to liaise with them
... there has been some chilling effects around IP though
... but if we want to do secure elements right, we need to work with them

Ian: I'll work with Ken and Mohammed on follow up on this topic

<scribe> ACTION: Ian to work with Ken and Mohammed on furthering our discussions with Global Platform

ILP Update

Adrian Hope-Bailie Slides

AdrianHB: Interledger work is happening in a Community Group.
... the CG develops specs. The effort has spawned several other groups in hyperledger and in interledger.js. Some bits of work are IETF specs
... one of my colleagues did a presentation at Airbnb..."#weaccept" is part of the Airbnb culture, and my colleague felt this had a payments ring to it as well
... Airbnb accepts a lot of different payment methods globally (cards, PayPal, alipoay, postpay, soft, ideal, boleto, payu, etc.)
... but some challenges in e.g., developing economies
... one particular person in Tanzania has only two available payment methods, and they are not optimal for that person's needs
... (only) 2% of Tanzanians have a bank account .... but 32% of Tanzanians have a mobile money account
... you have fragmentation in the market of mobile money providers...so that makes life harder for a company like Airbnb, who would have to integrate three times instead of having a standard.
... in short, the payment space is highly fragmented...and ILP seeks to alleviate that
... by connecting disparate networks.
... e.g., pay from an Alipay account to a bitcoin wallet....or for someone to pay in the US via a credit card and for money to be received as mobile money
... blockchain does not address this:

AdrianHB: ILP is a glue, just as the internet is a collection of networks.
... challenge is how to facilitate payment between networks...via a CONNECTOR
... our inspiration is Internet architecture
... key design tenet is simplicity
... a protocol can't be too opinionated in order for it to be usable in a variety of applications.
... the Internet stack is therefore an hourglass: simple and general IP+TCP/UDP, with more protocols both above and below
... the ILP stack has evolved similarly:

[How ILP works]

[Two-phase execution]

[Key ILP concepts: Condition, Expiry, Destination, Data]

AdrianHB: for interop you need a standard for what each of things looks like
... e.g,. amount is a unitless integer
... destination addressing scheme (influenced by IP addressing)
... dot-separated, but not size-limited.
... we are not operating at the same low-level as IP and so we can afford more bytes
... it's also expressed in ascii rather than numbers or bits. For example: g.crypto.xrp.r123
...you can build a test net easily, and we've built a test net of test nets

[On connectors]

[How to get adoption?]

AdrianHB: We have pretty good ideas on ILP protocol.
... what we have struggled with is how do we persuade the world this is a good idea
... we've tested our ideas by building on top of digital assets (e.g., XRP, Ethereum)
... the other ledger type we are looking at is blockchain (e.g., hyperledger quilt)
... mobile money (e.g., mojaloop)
... in conjunction with the Gates Foundation
... mojaloop offers clearing house services (e.g., fraud monitoring, directory service)
... and there's a clearing system that uses ILP
... as a clearing house operator, you deploy mojaloop...payments between operators happen via ILP
... we are working with Huawei, Ericsson, Conviva, and @@ to build interledger into their platforms
... banks
... central banks
... Over the past six months we've focused on "How to use this stuff"
... one of the first things we've looked at is micropayments
... I think the closest people have come is to think that bitcoin would be good for micropayments, but I think that has been shown not to be the case.
... some projects that depend on micropayments are Unhash, Codius
... they need to support micropayments between those systems and other systems, a good application of ILP
... We are also doing work in the WPWG on using ILP for web payments
... another area we are just starting to explore is marketplaces
... the ability to use ILP to make efficient trades between different entities where the assets being traded are potentially different

Magda: What's the current status of the CG? Participation? What moves to a WG?

AdrianHB: We imagine a payment method specification in the Web Payments Working Group. There's no obvious other piece of work where we think a new W3C Working Group is necessary
... also some interest from IOT people where we could work together
... as far as participation, there are a few hundred people in the CG...a few organizations are now allocating people full time to the project

Ian: Any browser vendors participating?

AdrianHB: People from those companies are participating, but not from the browser team
... I think the payment method is the important next step there..and get acceptance by parties like Stripe
... we think there's a value proposition for, for example, people who want to accept cryptocurrency payments
... "I accept ILP" and push specifics down the stack

dezell: When you are talking about P2P, is there a role in ensuring standard UI?

Ian: What's the best way to see demos?

AdrianHB: We recorded Weds demos; I will share a link when available

Security

Jason Dominicak Slides

Jason: As of Nov last year, InAuth is wholly-owned subsidiary of Amex

[InAuth at a glance]

[Fraudster Tactics]

Jason: we solve for various attacks from a DEVICE-lEVEL
... from a platform standpoint, whether from a mobile app or browser, we collect data about the device.
... if, after risk analysis, we are confident, we let data through without step-up
... we collect about 2000 attributes for a mobile app
... about 900 attributes for browser
... we compute a score and pass through to our clients
... we use location and malware detection as well.
... For discussion...some of what I've begun to discuss is how to make it easier to do authentication on the web
... privacy controls ... we see bad guys taking advantage of browser deficiencies and privacy controls....repeated attacks w/o recognized as returning
... difficult for a business to detect good v. bad
... one idea is for browsers to allow business to identify "good users" --- user prompted acceptance

Ian: I am hearing one question - what can we do from a web standards perspective re: fraud mitigation (linked to data collection)?

wseltzer: Good question about data and privacy.
... in the privacy interest group we've had some discussion of device fingerprinting as a concern, especially when used against the user's expectations.
... they don't want to be told they have privacy options and then have data used to correlate behavior
... is the solution more signaling to the user ("by participating you are permitting your behavior to be monitored")?
... is the role for multiple browser profiles (e.g., a commercial profile when willing to be engaged, or a more anonymized profile when they don't want data to become part of their permanent record....)?
... As an end user I like relative anonymity.

Jason: Is the question about the capability of turning on and off sharing modes?

wseltzer: I would be concerned about an environment where, by default, we gathered information and created shadowed profiles of people online, EVEN when presumably for the purpose of protecting them against fraud.

KenNovak: Regarding what data is personally identifiable
... we feel that the attributes we are collecting are not personally identifying
... when it might be we ask for consent

Jason: We are not collecting PII data.
... we are collecting information on the device instead of information about a person

KenNovak: When you log in to bank, browser is fingerprinted.
... there are other attributes related to user behavior, e.g., related to typing, or how navigation occurs.
...This helps determine whether human or bot
... we are not personally identifying a person

Wseltzer: It's probably useful her to distinguish "PII" and "linking information" and I'm not sure from this whether there is information from this that could be used to link behavior to a person
... that's an area the privacy IG is looking at
... One mitigation might be to do information analysis on the device and sending back only an aggregate or conclusion rather than sending back all the fingerprinting information.
... that could be shielding more of that within the user-controlled environment

Jason: We have that option of sending a score back

Wseltzer: Even for yes/no to work you would want some attestation about the state of device in which it was generated, but that too can generate privacy concerns

Ian: my vision of this conversation is that Jason & KenNovak are bringing one way people can reduce fraud. In what ways might W3C work?
... Is there something that would help you to do this work in a browser?
... Now, W3C might say "this is terrible from a privacy perspective." Or not.
... Web Commerce IG interest is finding ways to make your project easier and more effective, while not running afoul of privacy issues.
... Wendy, this perhaps sounds something like the FIDO model.

KenNovak: What we would find useful from a browser:

KenNovak: we don't have access to the same information from a browser...if we could get the two closer together in terms of data availability that would be great.
... anything that would enable us to get more data about the device would be extremely helpful
... today there are companies that can do some of that through plug-ins or other software packages...but that impinges on the user experience

dezell: It sounds like there is a desire for an API to gather data about the device.

KenNovak: Javascript is the most unobtrusive way today ... but the browser sandbox prevents access to some information

wseltzer: Some of the capabilities for persistent user identifiers are also of great interest to advertisers
... our Web and Advertiser IG is going to be talking about that
... would users opt for a browser id if it meant there was less JS covertly gathering the same information?
... and we could have a mechanism to "clear" the identifier
... you can do so on a mobile device, should you be able to clear other identifiers created for you or about you, and establish a clean slate...even if that means more authentication to get back into sensitive transactions.
... W3C's technical architecture has given some guidance around cookies and persistent identifiers (see Unsanctioned Tracking finding). We are also looking to organize a workshop on permissions and capabilities

IJ: what is latest on that workshop?

Wendy: We are looking for early 2018
... W3C staff member Sam Weiler is leading that

IJ: where else are these conversations happening within W3C?

Wendy: Privacy Interest Group would be interested in this
... they have a Note on Fingerprinting Guidance for Web Specification Authors (Draft)
... There's a policy conversation as well about using that information for user benefit or ecosystem benefit

Jason: Thank you for your time!

<shigeya> At the very end of the permissions breakout on Wed, we discussed the where and when of the permissions workshop. Co-location of Internet Identity Workshop was an idea. (April, San Carlos, CA)

Ryladog: (Aside) Are we still relying on secure element?

Ian: Web app developers don't have access to secure element from the Web today.

Virtual Reality Payments

Max: We have two use cases and two demos from Worldpay and Alipay. User is using VR to make a product selection
... at a moment in the demo, it's possible to authenticate (via password) to make a payment
... but it's not very convenient in a VR environment....it's not easy to input numbers or characters.
... so we are wondering whether there are any better auth solutions in a VR environment.
... we have some initial ideas.
... for example, if we were to use biometric auth in a VR environment, if the browser is the tool for the VR content, then there would need to be interfaces between sensors and glasses
... e.g., the fingerprint sensor would need to have an interface with the cell phone browser.

IJ: Could you use FIDO / Web Authentication?

Max: It's relevant but in the VR environment, there are unique requirements
... so WebAuth may not address some of them.
... in the future there might be other forms of biometric auth like retina scan

[Worldpay demo]

[EMV-style payments in VR]

Max: demo shows game-style environment where user picks up objects and pays for them
... strong auth done by selecting digits from numbers in 3D space.
... In the first case, it seems you have a virtual phone card touching a machine...how does that work?

MattS: I don't know exactly but I suspect pre-registration...my suspicion is host card emulation

Max: Don't you need a physical POS machine

MattS: I imagine so

<wseltzer> [demo included paintball-style PIN entry]

MattS: the credential will be in the VR device...if the VR has NFC in it, then NFC can be used to transmit the credential (e.g., to a POS)

AdrianHB: What is the connection to web work?
... is it WebVR?

Max: The technology behind our demo could be the same if the browser were to support VR

dezell: Accessibility is important

Max: Any thoughts on standardization opportunities?

MattS: Is part of accessibility providing diverse experiences...you don't need the same experience available to every person, but rather access to everyone

wseltzer: Our accessibility goal is to make an experience available to people of all abilities, to the extent possible
... the other piece of guidance that we get form our accessibility groups...designing accessibility in from the beginning often gives advantages to all users

Ryladog: Multiple input methods to accomplish the same task can help lots of people

Ian: what can W3C do? WebVR WG proposal failed (too early), so it stays in a CG. Payment Request API should integrate seemlessly into the experience.
... also FIDO. You could use Web Authentication to establish security.
... I think the pieces are WebVR, Payment Request API, and Web AuthN
... ensuring that PR API can be applied in WebVR seems important; suggest talking to the WebVR CG

Max: I agree with Ian about ensuring PR API can be used in WebVR environment
... we might benefit from writeup of use of those technologies in a VR environment and identifying any gaps in how they work together

dezell: The demo shows a shopping experience, a purchasing experience, payment experience (PR API + FIDO). I favor focussing on the purchasing experience.

Verifiable Claims Update

stonematt: One of the co-chairs of the VCWG; I work with Pearson
... we have an open badge compliant product in this space
... have done credential management for 20 years

[Refresher about VCWG]

stonematt: VC is about chain of trust. We published a FPWD. We want to let people express claims, protect privacy, ensure claims have not been tampered with

[Demo of credentials. Roles include issuer, holder, verifier]

mattstone: Today we can talk about use cases and relation to payments?

dezell: Can you redact part of passport information when shared?

Manu: The group is discussing redaction, but probably what's better is if the site only asks for (and receives) the information it needs, such as a passport number and not all the information about you.

christopher: The initial focus is data minimization, but all these architectures consider a future with selective disclosure with zero-knowledge proofs that enable good privacy decisions...but low hanging fruit is data minimization

Ryladog: Please be sure to have a use case about citizen access to government services

dezell: Another is electronic bank transfer
... Here are some additional commerce use cases.
... online prescription drug purchase

[Matt Stone walks through the connection between the claims, one from the state (driver's license) and one from the doctor (prescription).]

[Pharmacist seeks two credentials - identity (driver's license suffices) and prescription (a one-time credential ]

Manu: Another credential might be that the doctor's credentials are necessary for the transaction

richard: Credential + real time checks
... I think credentials for payments and for other types of transactions are similar
... we are talking about packaging / associating credentials

[Discussion of credential classes]

mattstone: One thing we are trying to be careful about : what is part of the credential? And what is part of the business process of the verifier?

Magda: For the purpose of this discussion, what are we focused on? What is the IG's role? What is the use case? What do you want to get out of this discussion?

Manu: We should also keep an eye out for the possible convergence of topics such as payments and credential
... do claims move through PR API, or another API, or both?

Ryladog: don't forget value to user

AdrianHB: It sounds like online card purchases are moving to a risk-based assessment model
... it sounds to me like there's a lot of potential for that to include verifiable claims, since that could reduce risk profile. Any conversations happening there?

<Magda> * +1 to Adrian's comments on risk based assessment*

Manu: No conversation is happening in VCWG on 3DS.
... maybe IG helps 3DS people talk to VCWG folks.

AdrianHB: 3DS appears to be standardizing a way to pass data back to the issuer for authorization
... it feels a lot like the 3DS standard should be aware of verifiable claims

IJ: When do you expect the specifiation to advance to CR?

Dan: No sooner than 6 months from now.

IJ: What is implementation status?

Manu: Evernym doing some. At ETS we have deployed a credential internally; that is a deployment ... we are looking at using blockchain next

IJ: How are multiple parties experimenting to play together?

Mattstone: Pearson has a product that is OBI-compliant and an internal product that turns OBI into claims.
... we're running into the limit of our charter since we are encountering the need of an API

Christopher: Blockstack (formerly OneName) has 75K people registered; they have done some implementation of DIDs or VC...they are architecturally compatible.
... Evernym
... BTCR (small)
... we are moving rapidly

jean-yves: This is brilliant.
... thanks W3C for launching the WG and to Manu for pushing it
... Another topic of importance is onboarding
... I think these are important VC use cases.
... AML for exaple
... Because this is about privacy/identity, there is relevance to payments

richard: I was at the 3DS session.

AdrianHB: The goal was to do risk assessment and avoid step-up

richard: Agree there is a good match of using credentials to avoid step-up
... Sometimes enrollment is not high quality, so I think are likely to rely on a variety of credentials more than strength of onboarding (at least for a while)

Ryladog: Use case - somebody authorized to collect money on someone else's behalf

Nathan: Some of the use cases we have seen...escalating disclosure, or having assurances about what info is going through a system
... there's a pilot and canada where parties can evaluate claims and escalate at times
... user provides info as needed.
... keys let us have confident about parties and triangulate to increase trust.
... e.g., mutual authentication (you know bank and bank knows you...so you know you are not giving up data to wrong party)
... can help avoid people being phished.

dezell: I am hearing two ways we could help re: use cases (1) 3DS sounds interesting (2) purchase gated on credential

AdrianHB: The experience I am envisioning and where W3C could be relevant - if browser has the ability to pull out credentials with user consent and share with a site, that seems like a valuable part of a 3DS flow.
... part of a payment method could be to declare information that will help payee do risk management
... verifiable claims more solid than random data; browser could play a role.
... need 3DS community to be aware of VC work

Manu: one of the driving use cases of VC is coupons
... that's still in the set of use cases we are working on.

Christopher: Something that has come up in the bitcoin community is the "second purchase"
... there's a lot that happens when establishing that one party knows the other
... payment has happened, receipt has happened, and both parties are satisfied.
... at second transaction, I want to (1) reduce friction and (2) be sure I am talking to the same person I was talking to the last time

Richard: expansion of use cases to commerce is interesting...and there are connections to education credentials
... git economy - I am not "buying" something; I am being paid for something

Web Commerce IG next steps

Ian Slides on Operations

<dezell> scribeNick: dezell

ian: we've been discussing "how do we reboot the interest group."
...: It's hard to understand industry trends through the lens of web evolution.
... we've just had a reorganization. But it's not clear we're doing what we should be doing.
... pushing insights about the web to IG participants is important.
... obstacles to participation are another issue (as we discuss in the slides)
... how do we understand our participants better?
... ideas for consideration
... periodic updates on the W3C - less one-on-one handholding required.
... revise deliverables: vision, use cases, (new) industry analyses.
... industry analyses are "white papers" that help express how the IG frames the problem, and motivates other work.
... Q: are white papers really useful? Some disagreement on this point.
... another point, maybe we don't need to force regular telcons. Task forces or CGs could meet.
... on the other hand, face to face meetings seem valuable.

<Ian> Ryladog: We need to understand industry use cases, but also user needs. We need to combine user needs + industry needs + web knowledge

<Ian> AdrianHB: I think that switching to a quarterly call schedule is a good idea.
...where the purpose is updates from various task forces
...I think the IG has a broad scope....people zone in and out as topics come under discussion that interest them (or not).
...I think we ned to accept that people want to participate when work is relevant to them
...breaking into focused task forces is a good way of doing that.
...I see the IG as an incubator of ideas
...task force unites like-minded people; goal should bring succinct proposals back to IG
...with info about standardization opportunities
...you need to work to get partners within W3C

<Magda> +1 on Call frequency and updates schedule

<Ian> ltoth: +1 to quarterly meetings ... but if you miss one you've missed out a lot

<dom> [might be worth considering recording the quarterly meetings for those that can't make it ]

<Ian> dezell: +1 to focus within smaller groups, especially interesting to me is the technology updates

<Ian> AdrianHB: What would make for a better use of time is "what you need to report back to the IG in order to be appreciated". Task forces need to have a clear sense of deliverables

<Ian> See the IG Champion process, which describes how people take ownership of topics and drive them forward within the IG.

<Ian> AdrianHB: People need to be succinct about their ask to the group

<Ian> Magda: How do we get people to re-engage after being out of the loop or dropping in and out
...I have a suggestion...do a relaunch
...reach out to people
...in the update, give an update and rope them in

<Ian> dezell: Network effect -people learn from each other.

<Ian> ltoth: An issue with standards bodies is that there are many of them

<Ian> Ian: Let's pick one topic and focus. Sometimes it's serendipity

<Ian> AdrianHB: It's important to understand the purpose of a liaison. Could just be mutual understanding, or could be standardization opportunity
...for newcomers it's not always clear what standardizing something at W3C means
...digital offers is an interesting example
...the first thing that two orgs should discuss is "what should be done at W3C" and what should not
...helping to identify standardization opportunities early is important

<Ian:> Ian: Next steps for digital offers - Linda/David/Ian devise a plan and convene the IG when we have something to discuss

<Ian> AdrianHB: The leg work is going out to get individuals interested in the work

<Ian> Ian: Illustration from this week - WOT WG chair signed up for IOT Payments task force

Summary of Action Items

[NEW] ACTION: Ian to create a mailing list for ongoing discussion of IOT payments
[NEW] ACTION: Ian to work with Ken and Mohammed on furthering our discussions with Global Platform
 

Minutes formatted by David Booth's scribe.perl version 1.152 (CVS log)
$Date: 2018/01/29 20:52:39 $