Security/Reviews/navigator.pay

Item Reviewed

   

     Full Query    

   

     Full Query    

Introduce the Feature

Goal of Feature, what is trying to be achieved (problem solved, use cases, etc)

The goal of the Web Payments architecture is to allow Open Web Apps to initiate a payment (or a refund) from the user for a virtual good via the navigator.mozPay function.

The normal usage is as follows:

• The app initiates a payment by signing a JWT request and calling navigator.mozPay().
• This starts the buyflow in a content iframe inside a trusted dialog ("chrome dialog").
• A purchasing flow is served from the Payment Provider's server as an HTML5 document inside the trusted dialog.
• The buyer is authenticated by the Payment Provider (via the network (radio) or BrowserID assertion in the B2G scenario).
• The buyer completes or cancels the purchase. (Note that the Payment Provider might require an authorization step).
• The app receives a Javascript callback when the buyer accepts or cancels the purchase.
• The app serser receives a signed POST request with a Payment Provider transaction identifier indicating that the purchase was completed successfully.

See the following pages for further detail:

• https://wiki.mozilla.org/WebAPI/WebPayment
• https://docs.google.com/document/d/1NLKbHVPQXa9uvDBC3cfgOD7sIrtIxi0qDoXMQrxcCsI/edit

What solutions/approaches were considered other than the proposed solution?

• marketplace to proxy other payment providers

Why was this solution chosen?

• Transfer risk to payment providers, rather than in the client or Mozilla managed services.

Any security threats already considered in the design and why?

• Threat Model: https://docs.google.com/document/d/1EBkzFye6DqCQkMEkXkjLjMvaYYCqvCGJrYhyG38R4DU/edit#

Threat Brainstorming

• Threat Model: https://docs.google.com/document/d/1EBkzFye6DqCQkMEkXkjLjMvaYYCqvCGJrYhyG38R4DU/edit#

Action Items

Status

Team

Open issues/risks

Stage 1: Definition

Introduction

Include brief summary of feature/project, and link back to core feature/product pages. Links:

• <a href="https://docs.google.com/document/d/1NLKbHVPQXa9uvDBC3cfgOD7sIrtIxi0qDoXMQrxcCsI/edit">Draft Specification</a>

Use Cases

See specification document above.

Data Types

Data Flows

• <a href="">Developer registration flow</a>
• <a href="">High level data flows</a>
• [todo add detailed data flows]

Diagram

Architecture Diagram

Stage 2: Design

Threat Model

https://docs.google.com/document/d/1EBkzFye6DqCQkMEkXkjLjMvaYYCqvCGJrYhyG38R4DU/edit

Security Recommendations / Open Issues