Subject: HTTP Payments - draft-hope-bailie-http-payments-00

From: Adrian Hope-Bailie <[email-masked]>
Date: Tue, 31 Oct 2017 01:57:21 +0200

Hi HTTPbis,

I'd like a few minutes of your time in Singapore to solicit interest in
pursuing something along the lines of what I have in
draft-hope-bailie-http-payments-00
[1]. As you may or may not be aware, all major browsers are shipping, or
close to shipping new payment APIs based on the specifications [2][3]
developed in the W3C Web Payments working group.

In the Interledger community group we have been experimenting with paid
HTTP requests for some time. We have defined some behaviours, primarily
through the use of some new headers, for clients and servers to exchange
the required information for the client to make a payment (in response to a
402 Payment Required HTTP response) and then retry the request with a
payment token.

This ID takes these ideas and merges them with the W3C Web Payments idea if
payment method identifiers to offer a more generic version of the system
that could support any payment method.

Adrian

[1] https://datatracker.ietf.org/doc/draft-hope-bailie-http-payments/
[2] https://www.w3.org/TR/payment-request/
[3] https://www.w3.org/TR/payment-method-id/

---

From: Loïc Hoguin <[email-masked]>
Date: Tue, 31 Oct 2017 13:57:44 +0000

> Hi HTTPbis,

Hello,

> pursuing something along the lines of what I have 
> in draft-hope-bailie-http-payments-00 [1]. As you may or may not be 
> aware, all major browsers are shipping, or close to shipping new payment 
> APIs based on the specifications [2][3] developed in the W3C Web 
> Payments working group.

I've noticed a small issue in the draft.

 > 4.1.  The "Pay" Header
 >
 >    The body of the "Pay" header is defined as follows:
 >
 > Pay: <payment-method-identifier> <amount> <address> <payment-method-data>
 >
 >    Multiple "Pay" headers MAY be present in an HTTP 402 response.

RFC7230 3.2.2 says this:

    A sender MUST NOT generate multiple header fields with the same field
    name in a message unless either the entire field value for that
    header field is defined as a comma-separated list [i.e., #(values)]
    or the header field is a well-known exception (as noted below).

    A recipient MAY combine multiple header fields with the same field
    name into one "field-name: field-value" pair, without changing the
    semantics of the message, by appending each subsequent field value to
    the combined field value in order, separated by a comma.

The only exception to that is the Set-cookie header.

The draft does not seem to say whether the Pay header is a comma 
separated list of payment methods and if it's not then the generic 
behavior above cannot apply. It would be great to avoid another exception.

Cheers,

-- 
Loïc Hoguin
https://ninenines.eu