<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
<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
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.
dezell: This session is on perspectives from merchants, primarily around digital offers
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: 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: 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
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: 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]
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
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
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
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
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.
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.
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
<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