Re: New Web Payments Architecture document proposal

On 06/20/2016 09:41 AM, Adrian Hope-Bailie wrote:
> 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.

To be clear, this document is meant to provide a summary. Some people
may call that an architectural summary, others call it a systems
overview, others call it an ecosystems document. We should change the
title to whatever suits the group.

What it isn't:

* a detailed software architecture document
* a detailed systems architecture document
* a formal model of anything

> If we're going for a software architecture

I agree that's important, but it seems like the group just wants to
implement and not do too much architecture/design before diving in.

This document is an attempt to summarize the architecture that we have
as we go (not create a software architecture document).

The title has been changed to reflect that it's supposed to be a summary:

https://github.com/w3c/webpayments/commit/319deaa505c6c27c3e9e1eb290cba62aa39d201f

> 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?

Yes, unfortunately, that's where I think we are too. I think it helps to
summarize the goals of the architecture, but not go too deeply into them.

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

Maybe. I feel like what's down there are architectural goals, and I did
steal them from the WPIG vision document, but they felt like a good
setup for folks reading about our work for the first time.

> * Payment Instruction
> 
> Not sure where this term comes from?

>From Kris and Vincent's suggestions... it's ISO20022 terminology and
feels like it gives future WGs more breathing room than just PaymentRequest.

> The group seems pretty settled on payment request so I'd like to 
> understand why you've changed that.

The group can continue to use PaymentRequest. For example, look at
"type" in the Core Messages spec:

https://w3c.github.io/webpayments-core-messages/#paymentinstruction

We should trying to make sure we have a bit of leeway for other types of
requests in the future, especially use cases like SubscriptionRequests
(which are in our use cases for v1, btw):

https://www.w3.org/TR/web-payments-use-cases/#uc-subscription

> If your intent is to change from payment request to payment 
> instruction then I think that warrants some discussion before we 
> adopt the change.

Agreed, this is a way of raising that question.

> 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.

I'd like Kris and Vincent to weigh in on this as it was their suggestion
to change it (and I agree with their suggestion).

> * 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.

When did we resolve to do that?

I agree that we resolved that credit card refunds are payment method
specific, but I don't think we resolved that we are only ever going to
push payment requests through these procotols that we're building here.

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

Fixed.

https://github.com/w3c/webpayments/commit/61edb85dcea37e47ac914e5f5144eb5a361e5a23

> * 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.

What language do you suggest?

> 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.

Hmm, you seem to have a specific definition of "transaction" that you're
using. Let me know what you'd rather use and we should focus the
discussion on that.

Transaction Details are meant to hold the stuff in the Browser API -
PaymentItems and the like.

> * Response Details - "processing the payment"
> 
> As above I'd emphasize that we are not standardizing anything to do 
> with payment processing.

Response Details are meant to hold things like payment method specific
data, requested email address, etc. What is the generic name for this stuff?

> * 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.

+1

> * 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.

Agreed.

> * 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.

It's meant to be an overview, not a "complete picture". I don't think
the Web Payments WG has demonstrated that it has enough patience to get
there. Some of that impatience is for good reasons, some of it isn't.

It's imperfect, but I think it's as good as we're going to get at this
point in time. It's also helpful to point folks to this document as a
way of quickly understanding what we're trying to do here.

-- manu

-- 
Manu Sporny (skype: msporny, twitter: manusporny, G+: +Manu Sporny)
Founder/CEO - Digital Bazaar, Inc.
JSON-LD Best Practice: Context Caching
https://manu.sporny.org/2016/json-ld-context-caching/

Received on Wednesday, 22 June 2016 02:05:54 UTC