Trusted UI/SE/TEE. Was: Minutes for Web Payments Workshop - Session 2

Dear List,

Since trusted payment UIs were mentioned by several of the speakers, it may be
worth repeating that although not acknowledged by the W3C, there is actually a
fairly complete trusted web UI proposal designed with payments in mind:

http://webpki.org/papers/PKI/pki-webcrypto.pdf#page=2

The proposal does neither depend on white-lists nor on the installation of
specific trusted applications.

It is effectively also a web-based "SE API" although only intended for *consumption*
of SE resources; management and provisioning of SEs presume a dedicated system.

For completeness, the following approach taken by Intel (and GlobalPlatform)
represents an alternative path to trusted UIs:
https://communities.intel.com/community/itpeernetwork/vproexpert/blog/2012/05/18/intel-ipt-with-embedded-pki-and-protected-transaction-display

The Intel scheme indeed takes security one step further but at the expense of
flexibility, platform independence, and maybe (we'll see...) market acceptance.

FWIW, I have (very slowly) begun to "look" into the implementation of
https://bugzilla.mozilla.org/show_bug.cgi?id=978867
for making W3C's WebCrypto compatible with existing smart card technology
including X.509 certificates and PIN-codes (de-facto standard for payment
operations in the EU), which seems like a useful intermediate step.

Anders

On 2014-03-31 02:49, Manu Sporny wrote:
> Thanks to Evan Schwartz and Charles McCathie Nevile for scribing
> "Session 2: Toward an Ideal Web Payments Experience" of the Web Payments
> Workshop. The minutes are now available:
> 
> https://web-payments.org/minutes/2014-03-24-s2/
> 
> Note: These are minutes for an official W3C Workshop event that have
> been cleaned up and reformatted by the Web Payments CG. The Web Payments
> CG and the W3C are two different organizations, and it is the W3C that
> put on this event. These minutes may be handed over to the W3C to become
> the official minutes for the event, but that has not happened yet (and
> may not happen at all). Readers should understand that there is a
> difference between officially sanctioned W3C work, and the work done by
> this community (which is not officially sanctioned by W3C's membership).
> 
> ----------------------------------------------------------------
> Web Payments Workshop - Session 2 Minutes for 2014-03-24
> 
> Agenda:
>   http://www.w3.org/2013/10/payments/agenda.html
> Topics:
>   1. Toward an Ideal Web Payments Experience
>   2. The Inputs to the Payments Standardization Process
>   3. Lessons Learned from the Mozilla Marketplace
>   4. General Discussion on the Ideal Payment Experiences
> Chair:
>   Daniel Appelquist
> Scribe:
>   Evan Schwartz and Charles McCathie Nevile
> Present:
>   Daniel Appelquist, Evan Schwartz, Natasha Rooney, Manu Sporny,
>   Kumar McMillan, Martin Hepp, Stéphane Boyera, Bryan Sullivan,
>   Ernesto Jimenez, Dave Birch, David Ezell, Virginie Galindo,
>   Ricardo Varela, Prakash Hariramani, Jeremy King, Giridhar
>   Mandyam, Hannes Tschofenig, Jeff Jaffe, Erik Anderson, Charles
>   McCathie Nevile, Jörg Heuer, Wendy Seltzer, Stan Stalnaker, Ori
>   Eisen, Tobie Langel, Mountie Lee, Dave Raggett, and 78 others for
>   a total of 103+ people
> 
> Evan Schwartz is scribing.
> 
> Topic: Toward an Ideal Web Payments Experience
> 
> Natasha Rooney:  In this session, we're going to look at use
>   cases for web payments, analyzing issues and questions
>   associated. By the end we should have some guidelines on how to
>   move forward with these issues
> 
> Topic: The Inputs to the Payments Standardization Process
> 
> Slides for this presentation are here -
>   https://web-payments.org/slides/2014/web-payments-workshop/
> Manu Sporny:  "Cat Herding 101", everyone has a different idea of
>   what to standardize
> Manu Sporny:  W3C creates standards through consensus, "ideal"
>   payments experience is subjective and there are many, we can only
>   realistically standardize parts of the experience
> Manu Sporny:  Don't want to beat innovation out in the process
> Manu Sporny:  3 Main inputs to standardization: position papers,
>   input from Web Payments Community Group, attendees of this
>   workshop
> Manu Sporny:  Survey of papers, common themes: no verified
>   identity / trust mechanism (72%), outdated security tech (50%),
>   no payment request standard (38%), no proof of purchase standard
>   (38%)
> 
> USE CASE: Verify identity or assess trust of partners in a
>   transaction.
> 
> Manu Sporny:  Didn't think identity was going to be such a common
>   issue but it was the #1 issue cited amongst the papers
> 
> USE CASE: Initiate / request payment.
> 
> USE CASE: Issue, transmit, validate proof-of-purchase / digital
>   receipt.
> 
> USE CASE: Find and compare payment options for transaction.
> 
> Manu Sporny:  Other themes: bad payment provider competition and
>   lock-in (38%), expensive for vendors to integrate with payment
>   providers (31%), mobile payments are fragmented (31%), payment
>   provider lock-in (28%), poor rate of extensibility
> Manu Sporny:  Web Payments CG - 146 members -- not an official
>   group at the W3C, existed for ~3 years, creating space where open
>   payment technologies can incubate
> Manu Sporny:  Currently working on 14 technologies that can be
>   applied to payment problems, these are designed to be taken W3C
>   standards track if we get consensus on them. Almost all of them
>   apply to the problems raised by the attendees of this workshop.
>   Very much aligned in "what's wrong, and how to fix it".
> Manu Sporny:  Machine-readable products and offers, initiating
>   transactions, digital receipts, identity, web security upgrades
> 
> USE CASE: Create a common digital receipt format.
> 
> Manu Sporny:  (Types of tech being worked on)
> Manu Sporny:  Workshop attendee input: looking to determine
>   problems, constraints, use cases, goals, and actions for the W3C
> Manu Sporny:  If you are interested in following up with this
>   work, please join the Web Payments CG, it's not official but
>   there will be a lot of post-workshop work and that's where most
>   of this work is happening now: https://web-payments.org/join
> 
> Topic: Lessons Learned from the Mozilla Marketplace
> 
> Slides for thsi presentation are here:
>   http://kumar303.github.io/w3c-payments
> Kumar McMillan:  For the past several years Mozilla has been
>   building mobile OS called Firefox OS
> Kumar McMillan:  Looked at HTML5 and available APIs, tried to
>   create APIs that did not already exist
> Kumar McMillan:  Wanted to have commerce as part of the mobile
>   operating system, for developers to sell apps
> 
> USE CASE: App Stores - selling apps in mobile scenarios.
> 
> Kumar McMillan:  Navigator.mozPay() is not on the standards track
> Kumar McMillan:  Talk will focus on what can be standardized
>   based on mozilla's experience
> Kumar McMillan:  Web payments work today
> Kumar McMillan:  When presented with a choice between credit card
>   and paypal, I'll almost always choose paypal. This works on the
>   web, we have secure HTTP. There's also Stripe and Square in the
>   US. Lots of startups disrupting the space
> Kumar McMillan:  There are some problems
> Kumar McMillan:  Credit card numbers are insecure, mobile billing
>   is broken in some major ways, new customer info, no standard for
>   asset ownership
> 
> USE CASE: Prove ownership over a particular asset (proof of
>   purchase / ownership).
> 
> Kumar McMillan:  Credit card numbers are totally insecure. Target
>   got hacked and I had to cancel my card, get a new one, and update
>   all of the accounts
> Kumar McMillan:  Why are we giving people credit cards when all
>   they want to do is make a specific payment
> Kumar McMillan:  Payment tokens for merchants: merchants could
>   give token that requests specific amount of money and token
>   expires
> 
> USE CASE: Temporary payment tokens for merchants. If token is
>   stolen, thief does not get access to financial account.
> 
> Kumar McMillan:  Payment processor needs to move money from
>   customer's account to merchant account -- merchant doesn't care
>   how payment is executed
> Kumar McMillan:  PayPal hosted flow works with tokens, mozPay
>   JSON web token works the same way, as well as Stripe and Square
> Kumar McMillan:  Merchant never receives credit card number
> 
> USE CASE: Billing through mobile operator (mobile billing)
>   without hacks to HTTP.
> 
> Kumar McMillan:  Mobile billing is broken, it's a nice way to pay
>   and works on the web, but there is HTTP header injection, every
>   operator is different, and there are SMS hacks
> Kumar McMillan:  Don't know how to fix this, operators need to
>   step up and fix this
> Kumar McMillan:  At mozilla, introduced silent SMS API, they'd
>   like to extract that from mozPay -- still just a better hack
> Kumar McMillan:  Apple's facetime has published how they do
>   silent SMS
> 
> USE CASE: Make it simple to register as a new customer (get rid
>   of the registration step, if possible, or make it transparent).
> 
> Kumar McMillan:  Becoming a new customer is hard, you have to
>   fill in home address, billing address, credit card number, and
>   you need to do it all over again for each payment provider
> Kumar McMillan:  Request Autocomplete was developed by Google,
>   shipping in Chrome, web page can request and autocompletion by
>   the device and the info will be stored securely on the device
> Kumar McMillan:  Standard web identity could be one solution but
>   it's pretty ambitious, there are strongholds around identity so
>   it might be harder to use that
> Kumar McMillan:  How do you prove you own an item? FirefoxOS is
>   trying to embrace fragmentation, they want firefox marketplace to
>   sell app but other marketplaces can also sell that app -- to make
>   this work they made a digital receipt format that is portable,
>   decentralized, and verifiable
> Kumar McMillan:  Digital receipts could be standardized to help
>   payments
> Kumar McMillan:  Payments work well, it's important to focus on
>   things that are real problems
> Kumar McMillan:  Also important to think about what are the
>   payment primitives? the basic, low-level building blocks like the
>   token idea
> 
> Topic: General Discussion on the Ideal Payment Experiences
> 
> Denis: looking at the spec for web payments provider, it asks
>   providers to be in a whitelist, what does it take to get in
>   there?
> Kumar McMillan:  Whitelist of payment providers may end up being
>   deprecated, need low-level building blocks for accessible APIs
> Martin Hepp:  How is the idea of digital receipts related to the
>   work on schema.org? -- could be applied to JSON-LD representation
> Kumar McMillan:  No plan right now to align this with JSON-LD but
>    it's a better idea than Mozilla's free-form JSON
> Stéphane Boyera:  MozPay seems like an interesting abstraction
>   across other payment provider APIs
> Kumar McMillan:  It's an abstraction but anyone could make an
>   abstraction, all the building blocks are on there on the web with
>   HTML forms that have a submit button. I don't think we need to
>   standardize an end-to-end flow, only focus on things that are
>   missing like tokens. Stripe has its own abstraction
> Daniel Appelquist:  Working at Telefonica I agree with what Kumar
>   said, but I don't agree that SMS is a hack
> Daniel Appelquist:  Using SMS is becoming pretty well cemented as
>   mechanism for verification -- silent SMS may be useful in some
>   cases but in others it might make the customer feel more secure
> Daniel Appelquist:  Is there really an ideal payment experience?
>   Micropayments have long been needed. HTTP status code 402 was
>   intended to support micro-payments. There were people in the
>   mid-1990s trying to implement micropayments but there is plenty
>   of room for innovation, shouldn't just focus on an ideal
>   scenario. Need to focus on security and convenience
> Daniel Appelquist:  There are issues with the current security
>   aspect, chromeless webapps or native applications, how can you
>   determine if you're in a secure application
> Daniel Appelquist:  Certificate model of web security is broken
>   because people don't pay attention to it, people click through
>   even on old certificates
> Daniel Appelquist:  Innovations in payment UI like using camera
>   to recognize credit card, but then there's a privacy issue
> Daniel Appelquist:  Loyalty cards have interesting developments
> Daniel Appelquist:  Mobile ticketing is also part of payments
> Daniel Appelquist:  Not currently convinced that we need payments
>   as part of the core architecture of the web. we should
>   incrementally strengthen existing work
> Bryan Sullivan:  ATT has operated as payment broker since 2002,
>   APIs have improved over the years, also mobile wallet in the US.
>   There isn't an ideal experience
> 
> USE CASE: Application of loyalty cards to purchases.
> 
> Bryan Sullivan:  People should look at the push API he's working
>   on with Telefonica
> Bryan Sullivan:  Payment is personal, enabling user choice in
>   everything regarded to payment is a key aspect of the UI
> Bryan Sullivan:  W3C doesn't have to address entire industry but
>   it should look at key use cases and requirements
> Bryan Sullivan:  UI for web on moblie is very diverse, all of
>   contexts should be supported. Don't want a fragmented web UX
> Bryan Sullivan:  UX is going to be driven by how consistently the
>   APIs are implemented, not so much about the UI -- you can set
>   expectations but mandating a particular UX leads to narrowing
>   scope of problem too much
> Bryan Sullivan:  Transfer of funds as an exercise is a really
>   good place to start but we need to think of payments as an aspect
>   of transaction processing in general, need to be able to exchange
>   all types of value
> Ernesto Jimenez:  Used to work for Telefonica and Mozilla,
>   background on what mozPay offered them -- it was good because
>   everything is web-based, needed a way to verify trusted UI for
>   entering details, the only problem was that there wasn't an
>   option to open it up to every type of payment provider
> Kumar McMillan:  In mozPay there's a trusted UI, but it is still
>   spoofable. That's not a payment-specific problem, it's a problem
>   for all mobile. There's no way to trust that a site is connected
>   to the right URL, all of mobile needs that
> Dave Birch:  If you assume payment token is the invoice signed by
>   the provider, that's completely feasible. The client is going to
>   pass the token to the payment service provider so they need to
>   manage providers. They'll also resolve certificate chains
> David Ezell:  Digitally signed invoice can act as the receipts
> David Ezell:  If we assume most of this is going to move onto
>   mobile, Trusted Execution Environments might add some optimism
>   even if it's not ideal right now
> Virginie Galindo: +1 To Dave Birch point on TEE optimism
> Kumar McMillan:  Maybe the token doesn't need the W3C but I want
>   to see sites stop using credit card numbers
> Kumar McMillan:  With the receipts there's also the ownership
>   part, like a cookie that lives on device so you could give it
>   back to the website
> Bryan Sullivan:  People should look at global platform for TEE,
>   this is a problem that's been around since feature phones
> Bryan Sullivan:  It's a general problem of the web that things
>   can pop up and take over the screen
> Virginie Galindo: Note : light explanation of Trusted Execution
>   Environment technology there :
> 
> http://poulpita.com/2014/02/18/trusted-execution-environment-do-you-have-yours/
> Ricardo Varela:  The moment we start getting into trusted
>   elements, we're getting into manufacturers and browsers, etc.
>   we'll need to decide if we want to involve those. Payments are
>   not just a form, the actual payment is done later. The open
>   question is whether payments should be a more integral part of
>   the web. Similar to geolocation where you say I want your
>   location, a merchant could say I want $10
> Natasha Rooney:  Many position papers separate UI and intent to
>   pay, questioning whether UI should be standardized. What do
>   people want from standards?
> Kumar McMillan:  Dangerous to standardize things that don't need
>   to be standardized -- UI is easy to build on existing web
>   technology. Risky to introduce APIs that are not useful. A 402
>   response is not as useful as a 301 redirect that redirects to a
>   page saying you haven't purchased this option
> Manu Sporny:  I agree completely. It's dangerous to say this is
>   exactly how payments look on the web, it's more about the intent
>   to pay. Whitelists and digital receipts have been raised a number
>   of times but if we say there will be a whitelist on payment
>   provider signatures we'll continue having the same ecosystem we
>   see today, no innovation. We could potentially put in the same
>   infrastructure that was put in for the Certificate Authorities,
>   we want a more flexible solution. Whitelists mean that we anoint
>   winners and losers of a particular service, that's bad when it
>   comes to payment, worse than what we have to Certificate
>   Authorities today. Just say "No!" to whitelists.
> 
> USE CASE: When doing a payment, need a way to assure the customer
>   he is his payment service provider  and is not subject to
>   phising. Specially problematic in mobile when browser chrome is
>   not available.
> 
> Bryan Sullivan:  Management of that type of data is the essence
>   of evil, solution needs to be more scalable
> Daniel Appelquist:  We shouldn't describe things as "evil". On
>   mobile, most apps are being used in a chromeless way, there is a
>   disparity because there isn't the same kinds of visual cues.
> Bryan Sullivan:  Trusted consent is a general problem of the web
> Prakash Hariramani:  Murkiness in terms of the standard for
>   payment tokens, what does the Fed and European Commission think
>   of the standards?
> Virginie Galindo: Note : some trusted user interface like work is
>   discussed in WebAppSec see : http://www.w3.org/TR/wsc-ui/
> Jeremy King:  The standard that Mastercard and Visa have just
>   related is taking tokenization from the issuer perspective and
>   using token to initiate transaction
> Jeremy King:  From PCI standards there is tokenization from the
>   acquirer's side
> Jeremy King:  Everyone's talking about tokenization from
>   different ends of the spectrum, so we need to get our terminology
>   straight.
> 
> USE CASE: Tokenization mechanism that protects the buyer and
>   merchant from theft of credentials.
> 
> Bryan Sullivan: Not sure how the tokenization spec relates to the
>   UX, maybe this can be clarified
> Giridhar Mandyam:  Re: mozilla telefonica paper -- why aren't
>   client technologies for geolocation good enough? How will third
>   party payment providers being included?
> Virginie Galindo: Note emvco tokenization framework :
>   https://www.emvco.com/specifications.aspx?id=263
> Kumar McMillan:  We're not sure, that's why there's a whitelist
>   right now. There are really sensitive APIs, there are privacy
>   reasons why we don't want to allow access to that
> Natasha Rooney:  Want to pull conversation away from mozPay
>   because they're not going to spec it
> Jeremy King:  Re comments about SMS, not long ago there was a
>   laptop and mobile phone, but now they've merged into one so SMS
>   is ineffective 2FA
> +Q
> Hannes Tschofenig:  There's always a reluctance to standardize UI
>   but the standardization is gone on mobile, as well as the
>   certificate validation. Is there any possibility to improve the
>   mobile experience? No one wants someone to dictate UI but it's
>   not a good state now
> Bryan Sullivan: Re SMS use in stolen phones, the solution there
>   is faster response for locking phones. And anyway in most cases
>   the thief will pull the SIM first thing, which prevents the SMS
>   from being an attack vector.
> Kumar McMillan:  Any time you're talking to any website on mobile
>   phone, need better mechanism than a lock icon for non-crypto
>   users to know they're talking to the right site
> Parslow says - there is not only stolen phones but a lot of
>   stolen OTP are due to cloned SIM issued by the operators
> Daniel Appelquist:  Security is a payments issue. per PHB, HTTPS
>   was designed for payments, i.e., to make consumers feel confident
>   enough to make payments online.
> Bryan Sullivan: Re earlier point on location, I agree it should
>   be entirely adequate (GeoLoc API) for payment purposes. Newer
>   tech and networks e.g. LTE will also support indoor location
>   soon.
> Jeff Jaffe:  Both Kumar and Manu have made strong points about
>   not standardizing UI, but if we're talking about an ideal UX for
>   payments, we have to get people to trust us with their dollars or
>   Euros, it's different than browsing the web for information
> Kumar McMillan:  There's a lot of innovation on the current web
>   with UI. Amazon payments are incredibly fast, Stripe has made it
>   super easy to pay. We'd hold people back
> Manu Sporny:  I'm hearing people say that they want to
>   standardize a UI, but does anyone even have an idea of what the
>   ideal UI would be? I've never heard a solid proposal over the
>   last several years that ended up gaining any sort of consensus
>   (and there have been a few by big companies).
> Natasha Rooney:  Too many stakeholders
> Stéphane Boyera:  I believe we are mixing ideal functional
>   interface vs ideal design
> Bryan Sullivan:  Shouldn't focus too much on UI
> Erik Anderson: UI will always be branded by the organization.
>   They will want their own particular theme.  Standardizing the UI
>   will never go anywhere.
> Chaals wanted to ask what the relation is between digital
>   receipts and EME, and to offer the counter-example of EV
>   certificates and standardisation of UI
> Bryan Sullivan: The problem is that solutions that focus on UI
>   get reduced to a solvable surface, in the case of tracking
>   protection for example limited to web browsers, and leaving all
>   other web contexts off the table.
> Charles McCathie Nevile:  When we created extended validation
>   certificate system, one of the things we did at W3C was
>   standardization of UI to show that you were on an extended
>   validated system. There's not a full spec but there are some
>   clear guidelines to help users be sure they know what they're
>   getting. You do have to dictate something about the UI to pass a
>   clear message across different UIs, need to pass minimal viable
>   set. Perhaps we should talk to the group that has done the most
>   with digital receipts... the EME folks have been dealing with
>   this stuff for a long time, we should talk to them.
> Bryan Sullivan: UI can come from many places... Web servers are
>   the most flexible source of UI, and OAuth servers have the same
>   advantage of being able to dynamically pull in content/info to
>   present to the user, and don't impact browser code bases (another
>   limiting factor).
> Charles McCathie Nevile:  Might be way to standardize receipts
> Natasha Rooney:  Who thinks it's a good idea to start looking
>   into UI elements of payments?
> Some people think it's a good idea, a few think it's an awful
>   idea
> Natasha Rooney:  Good case to start looking at it
> Virginie Galindo: Note : UI with security merits may be worth
>   looking at
> Jörg Heuer:  Need to differentiate between UI and user iteraction
>   patters, need to get into user interaction patters which blend
>   into technical transaction interactions
> Charles McCathie Nevile: [Having a digital receipt that is
>   transferable doesn't solve all of EME, but one part of what they
>   want to do is determine whether you have the right to use the
>   content]
> Bryan Sullivan: To address offline use cases, we also have
>   service workers and other new tech that can serve the same goals
>   e.g. local OAuth servers that can on the back end integrate with
>   TEE Trusted Applications or Secure Elements, which can provide a
>   truly trusted UI capability for the web.
> Daniel Appelquist: +1 To thinking about interaction (not
>   interface).
> Bryan Sullivan: Would web components provide a means to create
>   secure interactive elements?
> Natasha Rooney: Bryan, just what I was going to say!
> Jeff Jaffe: [+1 The distinction between interaction and interface
>   is a helpful distinction]
> Daniel Appelquist:  Interaction is the more accurate term than
>   interface
> Charles McCathie Nevile: [... I.e. a digital receipt. And having
>   a decentralised receipt instead of your prof-of-ownership being
>   provided as a service by a particular provider would, for
>   example, reduce the problem of your key expiring with the company
>   that made it]
> Bryan Sullivan:  What would be the role of web components? they
>   could provide secure interactive elements
> Natasha Rooney:  B2B payments haven't come up yet
> Ricardo Varela:  Bryan, I don't think so: web components at its
>   basic form are just glorified client-side template engines, they
>   don't solve anything we couldn't do already (of course they have
>   benefits like reusability but they don't add new "use cases")
> Bryan Sullivan:  Whole range of relationships beyond B2C, in
>   order to really reach scale, need to look at end-to-end
>   interaction and see all of the players. Need means of exchange
>   between providers and a market
> 
> USE CASE: Payments / digital receipts should be applicable to
>   Encrypted Media Extension authorization to show content.
> 
> Ernesto Jimenez:  2 Tracks for UI, browser or OS UI and there's
>   also UI for payment flow from payment processor. need way to show
>   customer in mobile and desktop that they're in a trusted
>   environment. shouldn't standardize how that looks but should
>   provide means for browsers to show it's in a trusted environment
> Ernesto Jimenez:  Different aspects of this could be standardized
>   separately as layers
> Bryan Sullivan: Businesses and enterprise user use cases are just
>   as important as consumer use cases. For example, the parties
>   involved in enterprise use cases might aggregate or authorize
>   payments on behalf of the enterprise, thus represent a B2B use
>   case.
> Charles McCathie Nevile is scribing.
> Manu Sporny:  Don't think anyone is arguing against a layered
>   approach
> Daniel Appelquist:  Agreed
> Stephane  wanted to talk about merchant ideal experience - adding
>   easily psps without changing a line
> Stéphane Boyera:  We talk a lot about users. I feel we need a
>   holistic approach. Think of the merchant UI. What merchants want
>   is to support more payment providers without changing the website
>   for each one... that has a huge impact.
> Kumar McMillan:  Would be nice, don't see it happening. People
>   woudn't follow a standard for an API.
>   ... the incentives are not there. Open source is a good answer
>   ... that would get traction.
> Chaals thinks a standard is a far better tool than an Open
>   Library...
> David Ezell: +1 To chaals
> Stéphane Boyera:  There is an abstraction that can be done like
>   mozpay, routing the user through the payment layer generically
>   seems a clever way to provide benefits to merchants and
>   customers.
> Bryan Sullivan: Isn't the interface between a virtual wallet and
>   payment providers valuable to standardize?
>   ... think that could be a good goal, allowing innovation where
>   it makes sense and a generic approach where it is required.
> Manu Sporny:  Big problem for merchants- if there is an open
>   mechanism, the merchant still needs to get the money.
>   ... They want to accept all payment, but don't want to make
>   individual deals with each processor. Not sure we touched on
>   that.
> Bryan Sullivan: The merchants don't need to know or use the API
>   between the wallet and payment provider, just the web API that
>   provides access to the wallet.
> Stéphane Boyera:  Think that would solve the issue. It isn't just
>   an account today, it is also writing a whole backend.
> Manu Sporny:  So where do they open the account? Without an open
>   standard, it matters where you open the account - that's a big
>   problem.
> Natasha Rooney:  Wallets might be able to handle that, giving a
>   bundle of accounts.
>   ... people innovating around there can cause issues.
> Wendy Seltzer wants to discuss privacy.
> Wendy Seltzer:  Wanted to re-emphasise Dan's quote about HTTPS -
>   giving customers confidence to make payments on the web.
>   ... shared interest is giving the customer confidence in
>   transactions.
>   ... and we have interest in making that confidence justified.
> Erik Anderson: Merchants dont want to be exposed to all of the
>   underlying payment sources or technologies. They want it to be
>   more simple.
> Stan Stalnaker: Deep thought - what would an http:// protocol
>   look like as a means of annotating a potential payment marker?
> Wendy Seltzer:  Some attention to the UX is needed. We need some
>   workto standardise and help people see they don't need to be an
>   expert in choosing providers to do business, don't need to do a
>   lot of research before knowing if payment will work on the web.
>   ... we want this to happen, where can we do the work?
> Charles McCathie Nevile:  Stan, you mean like: payto: ?
> David Ezell: Merchants want choice, but not necessarily infinite
>   choice.  Having ANY choice would be a huge improvement over
>   status quo.
> Hannes Tschofenig:  Raises an interesting question for W3C. On
>   the one hand you create building blocks, and let industry
>   innovate, but how do you ensure that these are sound for
>   security, which is the sum of, not just individual block
>   properties.
>   ... relates to whitelisting/certification.
>   ... When people meet the right criteria they get the User
>   Experience. I see layers in standardisation - some blocks at W3C,
>   but some maybe somewhere else (dunno where)
>   ... to provide a block that people get which is trustable.
>   There are examples in other sectors, like FIDO or Bluetooth.
> Bryan Sullivan: I agree that trusted UI is an important thing to
>   be considered but in general, not just for payments. And we
>   should keep a broader focus when we consider this, remembering
>   that much of the Web's UI exists outside the user agent, at least
>   in how the presentation layer is crafted.
> Natasha Rooney:  Has happened in eg WebRTC too.
> Ori Eisen:  Suggest we keep the UI and visual to the end.
>   Computers are great in shell before they had UIs. Let's fix the
>   core issue and then worry about how to signal what we are trying
>   to solve.
>   ... Think there are plenty of things W3C can and should do. BUT
>   there is no standardisation of fighting viruses. The bad guys are
>   too agile to make standards of how we fight them.
> Bryan Sullivan: APIs are the analogy of the shell
> Wendy Seltzer: [Cough Kerckhoffs's Principle, that a cryptosystem
>   should be secure even if all is disclosed but the key;
>   transparency can aid security cough]
> Ori Eisen:  Any standard we make will be so slow that bad guys
>   have a roadmap in advance.
>   ... need to figure what should and what shouldn't be
>   standardised.
>   ... who takes responsibility for paymetn security if it goes
>   bad. How do people who take responsibility for lost money fit
>   into the standardisation.
>   ... Don't forget there is an adversary watching us.
> Daniel Appelquist:  My perspective is this workshop is looking to
>   feed a process in W3C, but the thinking we are doing can have a
>   big influence too.
>   ... documented record of the meeting might produce outcomes
>   which are work items but not for W3C.
> Tobie wanted to comment on non-normative UI/UX work.
> Tobie Langel:  Following up on UX. The reason not to standardise
>   is 1: IPconcerns, 2: don't block innovation. Which are important
>   points. However, there would be value in some non-normative
>   documents on the topics.
> Jeff Jaffe: [Jeff supports Tobie's point.  We often call that
>   "Best Practices".]
> Erik Anderson:  All the merchant cares about is getting the money
>   into their bank. What is their experience going to be?
> Manu Sporny:  We are focusing on customer experience and
>   especially security issue for them, not "does their payment
>   provider match the merchant"?
>   ... When merchants accept Visa and MasterCard both them and the
>   customer doesn't care who people bank with. Unless we're building
>   on existing powers, you have to have a standard where the
>   merchant and customer can have different bank accounts, otherwise
>   we can't compete with what we already have.
> Daniel Appelquist:  Agree. E.g. Stripe's value-add is simplifying
>   life for the merchant.
>   ... Yandex proposal has some issues but the thinking behind it
>   to make it easy for merchants to integrate payment is something
>   we really need to understand how to do, and to get right as an
>   output.
> Kumar McMillan:  Why do we need to standardise? Merchant can
>   already accept bitcoin.
> Charles McCathie Nevile:  There are some governments who take a
>   dim view of merchants doing that (accepting Bitcoin).
> Stéphane Boyera:  -1 To what Kumar said.
> Bryan Sullivan:  Downside is fragmentation inhibits growth.
>   Developers always complain about the lack of standard APIs. The
>   developer experience is horrible and they don't have bandwidthto
>   track the fragmented world.
>   ... standardising at least a digital receipt might help as a
>   minimum.
> Manu Sporny:  What we want is "any merchant can integrate any
>   currency, so long as the value ends up at what they asked for".
>   Ideal is that when a vendor implements a cart, the mechanism is
>   the same across currencies and national boundaries. They just
>   want a receipt for the amount they asked for.
> Stéphane Boyera: +1 To what Manu just said.
> Daniel Appelquist:  Sometimes the vendor needs more info than the
>   credit, e.g. for regulatory requirements (reporting, etc)
> Mountie Lee:  Re certificates, a strength is that it is not yet
>   fully standardised. Problem of transport medium. Web is on the
>   application layer.
>   ... certificate has ???
>   ... 2nd point, payment can be connected to the merchant or
>   delivery or ID service providers. Have to think about integrating
>   the process from initiating, getting the receipt...
>   ... 3rd We can use recommendation systems to determine trust.
>   ... we can rent the idea from bitcoins and use users instead of
>   whitelisting, exchange w/o trust.
> Daniel Appelquist:  So learn from cryptocurrency and bring ideas
>   into mainstream payment?
> Bryan Sullivan: The third idea seems to call for vendor
>   reputation integration into the UX for payment.
> Mountie Lee:  No, we get votes from users. Accumulating votes can
>   use the bitcoin transaction history mechanism to increase trust.
> Manu Sporny:  So, you're saying that the trust of the merchant
>   based on other transactions. More people work with them, the more
>   you an trust them.
> Mountie Lee:  Also user experience reports. No trust until you
>   get "xyz" accumulated experiences
> Charles McCathie Nevile:  The problem with that is how do new
>   entrants get on board?
> Manu Sporny:  Yep, that is a problem - no clear solution to that
>   right now. Perhaps they get on board just like every other
>   merchant does on the Web today, although that's less than ideal.
>   Gives enormous power to the Amazon, Walmart, and Tescos of the
>   world.
> 
> USE CASE: Merchant and User reputation system accessible to the
>   payments mechanism.
> 
> Bryan Sullivan:  Reputation is integral. If we could integrate
>   verifiiable reputation recommendation it would be valuable
> Wendy Seltzer: I hear "two-sided market".
> Dave Raggett: Bryan, reputation is important for all the parties,
>   not just merchants
> 
> USE CASE: Reputation based selection of providers in a payment
>   transaction, or info about merchants to help the user choose
>   whether to complete the transaction.
> 
> Ricardo Varela:  Payments with cards are optimised for merchants.
>   I ahve no idea what I get charged when I make an international
>   purchase.
>   ... The same will happen here. Merchants already whitelist
>   payment providers - won't accept some card because of various
>   factors.
>   ... question is who does whitelisting.
>   ... in B2B, a merchant cannot ust receive money out of
>   everywhere, they have to justify the income.
> Parslow says - now in France you can be charged for exchange rate
>   between EUR and EUR...
> Jörg Heuer:  Important to understand that the security things are
>   about risk management, since 100% security is an illusion. We
>   need to keep that in mind and associate risk with the right
>   players.
>   ... in many cases the system holds the user free of liabilities
>   - this is a service of the payment provider.
>   ... if they can make the browser secure easily, they can make
>   things cheaper. We're not looking for *a*  security mechanism but
>   a framework that supports many. We want to give users and
>   merchants a choice.
>   ... I go to a shop and they say what they accept. I want to see
>   that on the web, and then choose the instrument of those I want.
>   two places where choices can be matched, which is a protocol
>   thing that we can work on.
> Natasha Rooney:  Seemed from position papers that stronger
>   solutions were the simple things. Is a simple solution the right
>   thing to do? What would it be?
> Kumar McMillan:  Think we need to focus on the small pieces, not
>   an end-to-end solution. Everyone has different incentives. So
>   they won't adopt a standard that doesn't match their incentive.
>   ... If we focus on e.g. receipts, someone finds that useful but
>   will want to e.g. maintain their own control over identity
>   provision. So think we can only focus on the primitives.
> Manu Sporny:  Largely agree. Important to know where we are
>   going. Would expect work to happen in phases. Primitives first,
>   then maybe higher-level concepts. Can we give anyone the ability
>   to crowdfund up to X value? Not in generation 1, but with the
>   right primitives in place it might be possible to handle that in
>   a future iteration.
>   ... A big standardization initiative will result in failure, we
>   need to start with small blocks.
> Bryan Sullivan:  Keep it simple. Don't make a thin abstraction
>   layer covering a mess of javascript that covers all the horrors.
>   ... finding the sweet spot is complex (we're going through that
>   with PushAPI)
> Hannes Tschofenig: It was interesting that all panel members
>   argued for **simple** solution
> Hannes Tschofenig: (Nobody every argues for complex solution and
>   for standards that are hard to understand. How boring is that?)
> Hannes Tschofenig: Even consultants argue for simple solutions.
>   They just add that the search for simple solutions is still
>   ongoing and requires lots of work
> 
> USE CASE: Whitelisting of parties - users, merchants, payment
>   providers without scalability / anti-compete issues.
> 
> Natasha Rooney:  Wrapping: Trust and security is a big topic.
>   ... we focused on trust and trustworthy UI. Lot of attention
>   paid to digital receipts and tokens. Whitelisting has scalability
>   issues but we want to look at what they really are.
>   ... flow from the merchant perspective is important - we are
>   all users, but not all merchants.
>   ... for standards, keep things simple and/or standardise in
>   modules.
>   ... We dabbled in stakeholders, and wallets (there is a session
>   on that tomorrow)
>   ... I'm eating your break, but while there, think of the
>   primitives to standardise around and tweet with #w3cpayment
>   hashtag
> End of session 2.
> 
> -- manu
>

Received on Monday, 31 March 2014 08:20:09 UTC