Re: New Web Payments Architecture document proposal

Hi Manu,

Thanks for this. I think the diagrams are certainly useful additions.

I think one of the problems we have in producing this document is that we
are not all aligned in terms of it's purpose or what viewpoint the document
is intended to be taking[1].

I suggest we try to get alignment on these things before we continue making
attempts to write the actual document.

I'm not actually sure if we are trying to define a software architecture or
if we're actually just looking for an overview of the other work pulled
into some kind of summary.

If we're going for a software architecture then it needs to be something
that we can refer back to and ensure we are maintaining that integrity as
we develop our other specs. To date that have failed dismally because I
don't think everyone in the group considers a software architecture
important.

So, as much as you an I may want to define one, perhaps a simple summary of
the ecosystem is enough without lofty sections like goals or visions?

A few comments on the document:

* Goals

These read as design goals/assumptions not goals of the architecture
itself? A lot of this feels like it's IG material.

* Payment Instruction

Not sure where this term comes from? The group seems pretty settled on
payment request so I'd like to understand why you've changed that. If your
intent is to change from payment request to payment instruction then I
think that warrants some discussion before we adopt the change.

In fact, I'd consider the messages from the Payment App -> Payment Network
and Payee -> Payment Network in the diagram in section 4 to be payment
instructions. These are distinct from the payment requests which are simply
used to initiate the process.

* Instruction/Request type

I don't think this should be in the architecture. We resolved that this
data is payment method specific so it sits within the payment method data
not at the level of the request. Support for repeat payments, refunds etc
is entirely payment method specific.

* Payment Method

A payment request has many of these. Your description sounds a like there
is only one?

* Transaction

I would not use this term anywhere in our documentation unless it is
warranted. We are not defining anything to do with transactions (or payment
processing). This gets very confusing when talking about message processing
too.

We are working on standards for "handling payment requests". The only
output from handling a payment request is a payment response but there is
no guarantee that there is any "transaction" (payments or otherwise) or
that a payment is even processed.

* Response Details - "processing the payment"

As above I'd emphasize that we are not standardizing anything to do with
payment processing.

* Roles

This is a very useful summary of the roles and for me the key concept
(which is why I changed my document title accordingly) that needs to be
understood to properly understand the design decisions behind other specs.

* Register Payment App

I suspect this will need to be reviewed when we have consensus on a
proposal for payment apps ion the browser and have reviewed the way payment
apps etc will work with other mediators.

* General

While I appreciate the brevity I think we need to decide if this is just an
overview of the architecture or something we consider a complete picture of
the software architecture.

I'm not convinced the group is aligned on this.

[1] - https://en.wikipedia.org/wiki/4%2B1_architectural_view_model

On 19 June 2016 at 03:34, Katie Haritos-Shea <ryladog@gmail.com> wrote:

> Short and sweet. I like it!
>
> Katie Haritos-Shea
> 703-371-5545
> On Jun 18, 2016 2:04 PM, "Manu Sporny" <msporny@digitalbazaar.com> wrote:
>
>> On 06/18/2016 01:32 PM, Rouslan Solomakhin wrote:
>> > Great document. Everything seems right, but I cannot comment on the
>> > "Payer Registers Payment App" section, because that's not implemented
>> > anywhere yet, AFAIK.
>>
>> Great, thanks Rouslan. :)
>>
>> The "Payer Registers Payment App" section presumes that the Payment App
>> spec will eventually define this (and showcase how that works).
>>
>> https://w3c.github.io/webpayments/proposals/paymentapps/payment-apps.html
>>
>> -- manu
>>
>> --
>> Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
>> Founder/CEO - Digital Bazaar, Inc.
>> blog: The Web Browser API Incubation Anti-Pattern
>> http://manu.sporny.org/2016/browser-api-incubation-antipattern/
>>
>>