W3C home > Mailing lists > Public > public-payments-wg@w3.org > July 2016

Re: Security and Privacy Considerations

From: Erik Anderson <eanders@pobox.com>
Date: Fri, 22 Jul 2016 09:55:09 -0400
Message-Id: <1469195709.355885.673779657.5983C62C@webmail.messagingengine.com>
To: public-payments-wg@w3.org
Friends got me as much documentation as possible to the legal and
compliance issues surrounding security and privacy of users information
and payment details.

https://github.com/w3c/webpayments-ig/tree/gh-pages/digital_services_security_legal

Since, in today's digital world, Identity is the exchange of
information, I highly suggest these considerations be brought into the
API design.

The top most considerations from a Financial Services point of view:

 - Design the API These API's with malice in mind. They must be designed
 from an attackers point of view.
 - Know and protect the assets. Since systems are distributed without
 singular point-to-point communications protocol you must secure the
 assets.
  - Think of sessions, not just API's. Initial authentication is
  different than session authentication.
  - Simplify the user experience. Users dont care about identity and
  security protocols, they just want to make a payment. Unfortunately,
  the security industry has historically placed users at the center of
  the security protocol, and asked them to make intelligent (and
  technical) risk-based decisions by answering questions like, “Do you
  trust this certificate?”
  - Simplify the developer experience. APIs can unwittingly create
  vulnerabilities because they dont have sufficient knowledge. Example,s
  a developer may hit an API too many times and degrade performance, or
  they may not know why or how to protect API and session keys. These
  problems can result in Denial of Service, Privilege Escalation and
  other security issues.

Doing nothing about the security of the API & its content is not
advisable. Feel free to interpret what I have from the documentation I
put together.

Erik Anderson
Bloomberg
Received on Friday, 22 July 2016 13:56:10 UTC

This archive was generated by hypermail 2.3.1 : Friday, 22 July 2016 13:56:12 UTC