Push payments and the high level design (was Proof of Concept: Identity Credentials Login)

Hi Manu,

(I followed your lead and started a new thread)

Thanks for your responses.
Some great points and I think I'm starting to get a clearer picture of
where things are and what has happened over the last while that isn't yet
captured in the specs or obvious from the minutes of calls and meetings
that I have read.

What I think the discussion has highlighted is the need to step back and
look at what has been done so far, from the perspective of external
stakeholders.
I have the good fortune of understanding a lot of what is written in the
specs, wiki and minutes of your meetings and calls but I suspect many of
the people we want to get involved or take interest in this work don't.

To be honest, I am not surprised that the banks are confused or don't
consider this stuff relevant to them right now.
Bare in mind that the retail payments processing at most banks, processors
even retailers is done by ancient systems that are still mostly talking ISO
8583 (that's a 25 year old protocol).
In the internet world we quickly forget that most of this stuff is done on
proprietary networks that pre-date the Web and that a lot of what we see as
payments is just nice HTTP candy on top provided by payments gateways.

ATM and POS devices still "dial-up" and use protocols like SPDH, IFX or
something proprietary from some hardware vendor.
The idea of using a protocol as loose as HTTP is just plain scary to many
in that world.

I am generalising but you catch my drift?
There are two worlds we are trying to bridge, the Internet technology world
and the payments world.

Our advantage is that we are a community of people who I think have a
varied perspective from both right?
So, I suspect there is a need to provide a few things to clarify the
direction the group has taken and the direction we intend to take.

1. A high level diagram of the payments ecosystem and how all of the work
to date fits in.
I am a pictures person and I think pictures are a great way to convey a
concept especially a complex one to an audience that has varied knowledge
of the problem domain.
Today we talk about the classic four-party model in payments.
Perhaps a good place to start is take that diagram and add in the new stuff
that has been proposed.
I have started on a few of these but they are very much aligned to the
OpenPayee thinking, I will share them for discussion and we can adjust them
to incorporate the webpayments.org ideas.

2. A high level definition of the payments process including all possible
steps.
Once we have defined that we can define which are optional and focus on
standardising the essential pieces first.
By optional, I mean optional in terms of being able to complete a payment
on today's terms (i.e. as simply as I described in my last mail)
i.e. Let's get to parity with the current status quo first but knowing that
we need the ability to add the extra stuff we want to add next (identity
exchange, terms negotiation etc).

Some more discussion in-line:

On 26 June 2014 04:10, Manu Sporny <msporny@digitalbazaar.com> wrote:

> On 06/24/2014 07:03 AM, Adrian Hope-Bailie wrote:
> > As a general comment, great to see that I'm not crazy and as a whole we
> > are in agreement!
>
> Just because the group agrees doesn't mean we're not crazy. :P
>
> > Great! I see this as fundamental, push payments is the only way we can
> > ultimately migrate to a system where payments are initiated and
> > concluded on the Web (even if they are processed, cleared and settled
> > out of band).
>
> +1
>
> >     I think you're jumping in /after/ we had already come to the
> conclusion
> >     that 'push payments' were the way forward. We came to this conclusion
> >     around 3-4 years ago, so you're probably not going to get much
> pushback
> >     on that part of your idea. :)
> >
> > Again, yay!
> > That said, I haven't noticed it as prominently as I would expect in the
> > specs I have read on webpayments.org <http://webpayments.org>.
>
> Unfortunately, the specs are half-baked, poorly written, and not up to
> date with current thinking. They don't quite reflect where we are as a
> group due to lack of time to update the specs.
>

Rather than me working on OpenPayee and the webpayments.org specs being out
of date, let me know how we can combine efforts and I can help to bring the
specs up to speed with current thinking.


> > My experience in dealing with payments industry stakeholders is that
> > they have gotten so used to cards as the only way to do B2C payments
> > that they haven't even considered alternatives.
>
> For some stakeholders that's true, for others not so much. We've found
> that many know about the alternatives, but think that implementation of
> those alternatives are at least a decade or two off (this tends to be
> the common line wrt. most banks, large and small, that I've spoken with
> over the years).
>

I suspect we all have better perspectives on our different geographies. I
probably know the South African and to some extent UK model best.
I'd argue that in some countries, like the UK, push payments is already
happening but isn't standardised (and that's the problem).
However, the progress was driven from the top down onto the banks.
Innovations in payments all falter if they are not interbank solutions. We
need more than individual banks to buy into the work we are doing.

So what is the groups approach to "marketing" our standard?
Who will be the champions of this in the payments industry (assuming the
W3C is the champion amongst the "Internet community")?
My experience has been that banks standardise as a last resort because
innovation is seen as a competitive advantage so this needs to happen at a
level above (banking associations or national reserve banks) or come as
pressure from the retailers.

Some clarity of vision (as I mention above) would be required though.

Thoughts?


>
> > If what we are doing presupposes that we will use a push payments model,
> > why so much focus on protecting the payer's identity?
> > As I have said before, sharing the payer's identity or proving some
> > payer credential is an edge case.
>
> Sharing an email address and shipping information is not an edge case.
> Those two pieces of information are regularly exchanged as a part of an
> online payment.
>

But only online payments. I think we are never going to agree on this :)


>
> > I see this standard as a means to use the internet to change existing
> > payments, most of which occur in the real world, not online.
>
> That could be one thing that the standard affects, yes. That said, we
> can't make that our solitary focus. If we're successful, we won't have
> to make a distinction between online and offline payments, or mobile and
> non-mobile payments. We're creating a set of modern standards for
> payments, full stop.
>
> > i.e. People are already making card payments at a POS today, how can we
> > change this so they use their mobile but not in a way that simply puts
> > their card on their mobile?
>
> +1, that's exactly the right question to ask (and one of the questions
> that we're attempting to address in this group).
>
> > My impression is that the work of the group thus far has been to take an
> > Internet payments first approach and that pulling in "brick 'n mortar"
> > use cases is a something that came after.
> > i.e. CNP eCommerce sucks, how can we make it better?
> > Am I wrong?
>
> No, we want the solution to work on the Internet and Brick and Mortar
> (BaM) as well. The issue with leading with Brick and Mortar first is
> that the BaM industry moves at a snails pace and the cost of upgrading
> POS terminals are quite large. There are large players (like Verifone,
> for example) in that industry that control access to what technologies
> are used and when they're deployed. We can't deploy and iterate quickly
> in BaM, but we can deploy and iterate quickly on the Web.
>

The BaM moves at snails pace because they are dependant on cards.
We are proposing a standard that displaces cards in the BaM context and
therefore the POS hardware that is so slow to iterate.

If we are realistic, by the time we have published this standard a huge
percentage of retailers will have internet enabled POS running on tablets
or similar.
If not then there are technologies like QR codes and NFC stickers that can
easily be added to the POS as a polyfill.

Remember if we are talking push payments then the innovation and iteration
mostly happens between the payer (on their phone or browser) and the
providers.
The merchant may be a mostly silent partner.

The following use cases both describe scenarios where the merchant is stuck
with their old POS but could still support push payments.
http://openpayee.org/use-cases/use-case-1-qr-code-bitcoin/
http://openpayee.org/use-cases/use-case-2-nfc-wallet/

(Ignore the custom URI schema etc. That's just me thinking out loud)
The principal is, the payee just needs to be able to pass their identifier
to the payer in some way.
If they can't pass any transaction data that's okay (not the ideal, but the
standard should allow it)


> > I see both as valid problems to solve but I see the brick 'n mortar
> > scenario as the one that should be solved first.
> > If you can solve that, entirely online payments can be solved easily.
>
> I strongly disagree. Why do you think it'll be easier to deploy in a BaM
> environment than an online one? Retailers are among the most
> conservative when it comes to new payment rails.


The simplest form of payment is that done in a BaM store. (Hand over card
details, submit to payment gateway - in this case often a bank directly,
get confirmation of auth, print receipt).
Online payments follow the same model but have additional steps like
capturing shipping details etc etc.

My proposal is that we break the whole process into steps and then first
standardise the steps that are common to all use cases.
In effect, that means standardising the steps that are essential to
performing a payment in the situation where a card payment at a POS would
be most common today.
i.e. Payer gets payee's details and pushes a payment through their provider
to the payee. Payee gets a receipt.

If this is done well we will have standard ways of performing these steps
but also ways for additional steps to be added and standards for those.
e.g. Before the payee provides their payment details they request the
payer's proof of age and validate this.  (We provide a standard for this
step)

>
I have provided some more detail below.


> > The payments process should a be simple one.
> > 1. Establish who is paying who and how.
> > 2. Process the payment
> > 3. Provide both parties with proof of the completed payment
> >
> > Other services like verifying the age of the payer, getting the shipping
> > address of the payer, generating a full invoice including the basket of
> > goods can all be bolted-on.
> > If we try to make them integral to the payment process then things get
> > way too complicated.
>
> I understand the point you're making, but I see your proposal as just
> digitizing the current payment flow we have today and paying with an
> electronic cheque equivalent.
>
> Keep in mind that there is nothing preventing organizations from simply
> doing what you state above with the current spec. You're talking about a
> simple transfer of money w/ a memo field (an electronic cheque). That's
> the easy problem to solve, and that what this spec is for:
>
> https://web-payments.org/specs/source/web-payments#the-transaction-process
>
> That approach also ignores much of the input that we've gotten from
> large retailers, banks, and governments. The fact is that identity is a
> big problem on the Web and in payments. The use case that you want to
> solve is just a minor part of the bigger problems with payments on the
> Web. You may want to review the input we got from major banks/retailers
> and financial technology companies here:
>
> http://www.w3.org/2013/10/payments/final_report.html#output
>
> This may also help:
>
> http://www.w3.org/2013/10/payments/minutes/
>
> While I agree that what you're proposing we do is a good first cut, it
> won't address the many other concerns that the world wide payments
> community has. Again, this is about striking a balance between boiling
> the oceans and spec'ing a toy payments protocol. If we go too far in
> either direction, adoption will fail. I expect that we'll be debating
> whether we're straying too far in either direction for the duration of
> the work we do here. :)
>

My proposal is to standardise something far simpler than the whole Pay
Swarm transaction process attempts to address.
The actual processing of transactions should be left to the providers to
standardise based on the channel they use.
(In many cases this will be out of band, on proprietary networks - existing
payments rails).

That is not to say a standard shouldn't one day exist for using the
internet as the actual payments rails but I think that should come last.
(I sense some discussion coming on this point)

My approach

Phase 1: lay the foundation for push payments

Simply requires a standard mechanism for the payer to get the payee's
payment details (only enough info to actually make a payment to them).
Consisting of:
1. A standardised format for the payee identifier
2. A standardised protocol for the payer (or their provider) to use the
identifier and discover the ways that they can pay the payee (channels)

That's it.

Adoption of phase 1 standards are simple.
Payer providers (banks and wallet providers) add support for reception of
the standardised identifier to their mobile apps and websiites via QR
codes, NFC tags and plain old hyperlinks.
Merchants with providers that support this standard simply put a QR code or
NFC sticker on their register (BaM) or display a QR code on their checkout
page (eComm).

Ideally the browser vendors catch on and recognise some markup in the
online stores that identifies a payee identifier and can be configured to
process that and redirect the user to their preferred payment provider site
with the payee identifier and transaction data in the request.

We have standardised the toughest part, the initiation, which must be done
through various fragmented mediums in various contexts.

Adding additional standardisation to the "behind the scenes" stuff is much
easier now as the adopters are payments providers and adoption of the
latest features becomes a competitive advantage to them.

Phase 2: Enhance the standard to introduce additional functionality (in no
particular order)

1. Payment Terms
The next version of the discovery protocol can discover more than just how
to pay the payee but also how to interpret payment terms specified by the
payee.
The payer can now choose the terms they prefer most.
The payee can provide payment options that have no terms as a fall back if
the payer's provider doesn't support this feature yet.
(See how the providers are incentivised to keep up with the latest
standard? If my bank is slow in adapting I'll start using some wallet
provider instead or switch banks.)

2. Identity Exchange
The protocol now also supports requests for information from the payee as
part of the process.
If the payer's provider doesn't support this version of the protocol then
they will simply not be able to complete the transaction (no payment
options will be available that the provider supports) or the payee will
accept this and allow the transaction to continue.
Industry associations or local laws can dictate what is required and also
how the payee must behave in the case of a fallback.
i.e. Selling alcohol only allowed if you support age verification. Fallback
to skipping verification not allowed.

3. Digital Invoicing
As part of the discovery process a new resource endpoint is advertised
where the payer can request an invoice.

4. Digital Receipts (proof of payment)
I know this will be contentious :)
What is stopping the payment channels from defining how the payee will be
notified that the payment has completed successfully.
If the payee chooses to support a channel for payment and that channel
notifies him by SMS then he has chosen to accept SMS as a proof of payment.
(By the way there is a company in South Africa doing QR code payments with
verification by SMS who have just been bought by Standard Bank - biggest
bank in Africa).
Ultimately we'd want to standardise this process.
An additional resource endpoint advertised during the discovery phase where
the payer can request a receipt explicitly and pass this onto the payee as
proof-of-payment (so we now support scenarios where the payee is offline).

5. Other


> > As far as I know real-time ACH is not possible in the US.
>
> It is, it's called FedWire, but it's only accessible to the banks. :)


> > To make a real-time payment you have to use a card.
>
> A card payment isn't real-time, the money can still take days to settle.
>
> ... but I get what you're saying. We want instantaneous
> customer-to-customer clearing. That said, what you've proposed doesn't
> lead to instantaneous customer-to-customer clearing.
>
> The banks have been able to do instantaneous customer-to-customer
> clearing for years now. However, when the time comes to vote for
> instantaneous customer-to-customer clearing, it's voted down each and
> every time because if it's allowed, the float goes away and banks lose
> that revenue stream on which they depend.


We need to be careful we don't confuse clearing and settlement.
What is usually more important to the payee is clearing but even more
important is irrevocability (I think I am making up words).

The only way for a customer to pay a merchant in the US today in a way that
the merchant has a guarantee from their provider that they will get the
funds is by card or cheque.
With cards they still have the risk of a charge back later so the
transaction isn't truly irrevocable anyway.

We need a concerted effort by all of the national reserve banks (or
similar) to institute a system of real-time push payments (like Faster
Payments in the UK).
It would need to have a lower interchange (or no interchange) than cards
(and that should be possible as it's less risky and irrevocable).
Many domestic payment networks have these clearing houses in place already
but only for large payments and with high fees (targeted at corporate
banking).
Ultimately systems like Bitcoin and Ripple will negate the need for this
but the jury is still out on how that will work or if they will ever be
allowed.

Until that system is in place the push payments model I describe above will
have to fall back to cards where the payer's provider passes their card
details directly to the payee's provider to process the transaction. There
are countless mobile payments businesses doing this already but none have a
standardised way of doing the initiation and discovery steps.

I see the value proposition to the banks (to move away from sitting on
float) being that they can cut out the card networks when processing retail
payments.
i.e. They can charge less and/or earn more off of the transaction fees.

I see the card networks either recognising an opportunity and reusing their
existing rails for the interbank network or trying to exert political
pressure on the banks to stick with cards.


> >     Hindsight is always 20/20, but if we had caved in on that problem
> area
> >     those many years ago, we wouldn't have JSON-LD today. We view
> identity
> >     in the same way, we're not trying to find a solution for identity
> that
> >     works for payments. We're trying to find an identity solution that
> works
> >     really well for the Web, and it just so happens to also work really
> well
> >     for payments.
> >
> > I applaud this work and I really like JSON-LD.
> > You may argue that it brings us closer to a payments standard by an
> > essential providing a piece of the puzzle that you considered to be
> > missing.
> > My contention is that it wasn't really essential to developing a
> > payments standard which is what I believe is the mission of this group.
>
> We'll have to agree to disagree that JSON-LD wasn't required for a
> Web-based, scalable payment standard. :)


Maybe it was required for the full stack you have in Pay Swarm, it wouldn't
be required to produce the simple standard I have described above in phase
1.
Let's say we're both right :)


> > Why not take this work into the appropriate forum and from the
> > perspective of developing a payments standard we can consider it just
> > another arrow in the quiver?
>
> It will eventually move to the appropriate forum. The unfortunate
> reality is that forum doesn't exist right now. If it did, the identity
> work would already live there. This is the same thing that happened with
> JSON-LD. It was incubated in this group until the JSON-LD CG was formed
> and then the RDF WG adopted and standardized the work.
>
> Where do you think the identity work we're doing here should go? Which
> forum should it move to?
>

I take your point. As we have discussed think this was just bad timing :)
In my view it's mature enough to justify it's own working group.
Not worth dwelling on.


>
> > My concern is that by developing an identity exchange standard under the
> > name of a web payments group you have effectively labelled it as a
> > standard for payments.
> > The assumption from anyone outside the group will always be that it is
> > designed for this purpose because the group felt the existing solutions
> > weren't good enough.
>
> That didn't happen for JSON-LD, why do you think it'll happen to the
> identity work?
>

Call it my impression that everyone trying to solve the payments problem
considers identity key to the solution (because they haven't considered
cards not being part of the solution).
The result is that an identity protocol/standard that comes out of a group
focused on development of payments standards must be payments focused too
right?
Also not worth dwelling on.


>
> > I think there needs to be clear messaging that the Identity Credentials
> > work is, as you have said before, an experiment being done "on the
> > sidelines" to test some theories.
>
> Where would you like to see that messaging?
>

Integrated into an architectural overview (as I described above)?


>
> > I need to do a deeper dive but from my first impressions, a lot of what
> > is laid out in the 3 payments focused specs could be done without any of
> > the stand-alone standards.
> > How you exchange credentials, sign messages, represent linked data are
> > all implementation details that can be achieved a number of ways.
>
> Yes, but the point of standards is to nail down the implementation
> details wrt. interoperability. You can't just say "and then you
> digitally sign a message and send it to the payer". Interoperability and
> standards are about /how/ you do that.
>

I agree. But it helps to say "and then you digitally sign a message and
send it to the payer" first and then get into detail after.
Once you have the high level process documented you can add the
implementation detail.
As with everything, once you get into the detail things may have to change
but at least have documented somewhere the highlevel architecture and
process.
I consider this a failing of most specs from the W3C and IETF. They all
dive into details too fast and don't provide a layered approach.
Start with a high level view and work down.

Speaking from experience in trying to catch up on the work of this group
only having the specs to refer to to try and understand the big picture
makes life very hard.

We don't need to rewrite the specs but some less-specification-style
easier-to-read docs and diagrams that give the overall high level view
would help external stakeholders to understand our proposed solution.

> My approach has been to break payments down to the following steps:
> >
> >  1. Initiation
> >     The payee provides the payer with an identifier and optionally a set
> >     of transaction meta-data such as the payment amount and currency.
>
> +1
>
> What sort of identifier is this? Is it a URL? Is there machine-readable
> data at that URL?
>

Does it matter yet? Let's agree that there is an identifier then define
what it is. :)

In my OpenPayee work I said use anything that can be treated as an Open ID
Connect identifier.
At a minimum it needs to be a form that the payer can normalise and use to
discover information about the payee.

So, yes, URI is probably best.
Also, because you can then append transaction data to it in the query
string or fragment, it can become more than just the payee identifier.


> >  2. Discovery
> >     The payer uses the identifier to discover the available channels on
> >     which the payee is able to receive payments.
>
> +1
>
> How does the payer extract the information in an interoperable way?
>

Standardise this.
My proposal was Open ID Connect Discovery to discover an endpoint where the
payer can GET a JSON document describing this information.


>
> >  3. Channel Selection
> >     The payer selects one or more payment channels from those that are
> >     available and for which payer accepts the terms.
>
> +1
>
> >  4. Invoice (optional)
> >     The payer requests a digital invoice from the payee confirming the
> >     transaction details including the amount, currency,  channel(s) and
> >     terms that will be used to make the payment.
>
> Why is this step optional? If you make it optional, where is the
> consumer protection? What happens if the payer changes their mind? "Oh,
> no, I never said pay me $1 for access... I said pay me $10! - the $1 was
> for the preview that I showed you". Remember, this stuff is going to be
> used for peer-to-peer payments as well. It's not just customer-to-merchant.
>

As I described in my phased approach above I consider any steps that are
not essential to the process as optional.
As we add more of the "optional" stuff we start to cover more and more use
cases.
It is good to know that we ultimately want this step so we can plan for it
in adjoining steps but we don't have to go into the implementation detail
during the first iteration.


> >  5. Payment
> >     The payer processes the payment.
>
> +1, if you mean the payer's payment processor processes the payment.
>

Yes I do.
Although you raise a great point.

Ultimately the payer should be able to be their own provider for certain
channels (and I expect the browser and mobile OS vendors will latch onto
this).
Bitcoin would be a good example.
I have a Bitcoin app on my mobile so if the payment processing is as simple
as me sending Bitcoin then I don't need a provider do I?

The standard should consider that it is the payer (or their provider)
performing the operations that the standard describes.


>
> >  6. Receipt
> >     The payer requests a digital receipt from a trusted entity
> >     participating in the payment (dictated by the channel used, usually
> >     the payee's provider).
>
> +1
>
> >  7. Notification
> >     The payer notifies the payee that the payment has been completed by
> >     posting a copy of the receipt to the payee. Alternatively the payee
> >     may receive the receipt directly from their provider.
>
> +1
>
> >  8. Confirmation
> >     The payee confirms that the payment is complete.
>
> +1
>
> > Notice that all of this can be achieved without the payer doing any
> > identity exchange.
>
> Sure, it can happen w/o the payer doing any identity exchange, but that
> only covers a small-ish portion of the number of use cases that we have
> to cover if this payment mechanism is going to achieve what you can do
> online today.
>

Be careful that the number of use cases is considered in conjunction with
how often those use cases are actually exercised today.
How are the largest number of transactions done today?
Like I said, let's focus on the simple BaM use case and build from there.


> Let's take the example of a movie rental where you have to be over the
> age of 15 to rent the movie.
>
> How do you prove that you're over a certain age? What happens when the
> buyer returns to the website to say, view the rental on the second day?
> How do you prevent the digital receipt from being pirated and used by
> 1,000 different people?
>

I think this is starting to blur the lines between the business process and
payment process again (like the shop vs buy point I made before).
Most payment processes don't care about your business processes. They
integrate into them but don't depend on them.

In this case the user would have a user account with the site and would
have to prove their age when they registered.
(KYC is not part of payments, it's part of governance and other processes.
It may be a prerequisite to do some payments but it doesn't have to be part
of the process).

The purchase would be tied to their account and when they log on tomorrow
they can still get the movie.

DRM protections are available to prevent pirating.
While I see the appeal of tying these to payments it's a very complicated
use case to try and include in the first iteration of a standard like this.

Personally, I would see the mature payments standard being extended by a
media focused working group in the future to integrate payment, identity
validation and DRM.


>
> >  1. That the Identity classification is split (or a new category added:
> >     Discovery) so there is a clear distinction between the payer
> >     discovering the channels available to pay the merchant and the
> >     merchant discovering information about the payee.
>
> It's already split out:
>
> https://web-payments.org/specs/#identity
>
> Where else would you like to see the clear distinction?
>

I was referring to the use cases on the WPCG wiki


>
> >  2. That the other steps above be considered for inclusion as categories.
>
> Categories where? I think we've been considering those categories for a
> while and, while it may not be obvious from the website, that's the
> operational model we've been assuming for a number of years now. So,
> this sounds like a documentation problem. Where do you think we should
> document those steps?
>
>
Also WPCG Wiki.


> >     These specs can be used to solve /other/ problems on the Web.
> >
> > A bonus if it happens but surely a distraction and likely to cause
> > delays? :)
>
> In some cases yes, in others no. You'll have to be more specific about
> what you think is a distraction. :)
>
> Keep in mind that when Web standards go out there, their life span is
> 10+ years. So, we should be very careful to craft a solution that's
> extensible and that is capable of changing with the times. The worst
> case isn't that the technology isn't adopted, it's that it /is/ adopted
> and it isn't flexible enough to keep pace with innovation or it doesn't
> scale appropriately to billions of people.
>
> To put it bluntly: This is the Web, we don't half-ass solutions just
> because we want to make rapid progress. :
>
> Bolting things on after-the-fact is far more difficult than designing
> them correctly from the start.
>

I take your point and I agree.
I still think breaking the payments process into steps and standardising
this as I have described earlier in phases is a better approach than trying
to cover as many use cases as possible in iteration 1.

I'm certainly not suggesting that we should do a half-arse job for the sake
of getting it done quickly.
My reason for breaking things up is for clarity and to promote flexibility.

Being "extensible and changing with the times" is much easier on a
collection of small standards instead of a big one (but we have agreed on
this already).
I think where we differ is where the split should occur and what should be
in scope for v1.


>
> > Although I'd also propose a standard for each stage and name them as
> > such maybe?
> >
> > Some ideas:
> >
> > Web Payments Initiation (OpenPayee was heading down this road, elements
> > of Web Commerce API)
> > - How to normailse an identifer and optional meta-data into a resource
> > address(es) where the channel discovery, id exchange etc services can be
> > found
> > - Should probably include a means to verify the payee in some way
> >
> > Web Payments Channel Discovery (some stuff from Web Commerce)
> > - Standardised way to represent available payment channels and basic
> > requirements for channels to plug into this system
> >
> > Web Payments Payer Identity Exchange (Identity Credentials?)
> > - Standardised way to request payer credentials etc
> >
> > Web Payments Terms Core (+ extensions for specifying how specific terms
> > would be represented: currency, fees, clearing requirements etc )
> > - Standardised way to represent what terms are understood by both
> > parties, elegant fallback for those that aren't and a means to describe
> > the terms.
> >
> > Web Payments Invoicing
> > - Standardised way to request a digital invoice in which the final terms
> > are described (and calculations done so this only contains final
> > amounts) that is signed by the payee.
> > - Standard format(s) for the invoice, signature etc
> > - Should include a mechanism to reject a request if the terms have been
> > misrepresented or misinterpeted by the payer
> >
> > Web Payments Receipts (stuff from Web Commerce and Web Commerce API)
> > - Standard way to request a signed receipt after the payment is complete.
> > - Standard format(s) for the receipt, signature etc
> > - Standardised means to conclude the payment by sharing the receipt or
> > confirming it's signature or similar
>
> I think these are good suggestions. It feels a bit like premature
> re-arranging, but perhaps we should start a separate thread to discuss
> this proposal. Do you mind starting that thread?
>

This is it :)


> >     > Off the top of my head we should start by defining a standard way
> for
> >     > the payee to advertise the channels that they will accept payments
> on
> >     > (either with a specific transaction context or in a general
> >     > context).
> >
> >     That's what this spec does:
> >
> >     https://web-payments.org/specs/source/web-commerce/
> >
> > Yes and no.
> > I think this spec is the perfect place to start but it highlights what I
> > mentioned before about coming at this from the Web angle first.
> > I know that this the original intention of PaySwarm (as I understand it)
> > was a web based payments system solving problems specifically around
> > digital assets, micropayments and licenses so this is expected.
>
> No, PaySwarm was already intended as a mechanism to make both Internet
> and "physical retail" payments.
>
> > The spec assumes that all of the information about the transaction will
> > be bundled together.
>
> Hmm, why do you say that?
>

Where in the spec does it describe how a payee can simply pass a list of
payment options to the payer without an offer or asset or other info.
i.e. If the payer holds all knowledge about the transaction and just wants
a list of payment options how would that work?

In this case the payer will pick a channel, complete the payment and the
payee will be notified.
Only then will the payee reconcile the notification with the exchange of
their identifier to the payer just before.
"Someone owes me $12. I gave my payee identifier to them. Oh look, here's a
$12 payment I just received".

This is worst case scenario (ideally the payee does provide transaction
info to the payer but this allows for the very primitive BaM use case)


> > All the payer wants to know is how much and how do I make the payment.
> > That's all I think the channel discovery standard should solve.
>
> That may be all the payer wants to know, but the regulatory environment
> requires much more to be collected during the sale. Same for the
> retailer and the payment processor. A retail transaction isn't as simple
> as "I want $5, give it to me."
>
>
The message would be more like: "I want $5, you can pay it by EFT to bank
number 12345 and send me a proof of payment via SMS to 67890."
Everything else that is required by regulations is static data held by the
providers.
When you pay for something with a card today all you provide is your card's
track 2 data (PAN, expiry and CVV) why must we spec more for the most basic
use case?


> > A completely seperate specification can deal with digital contracts,
> > defining the basket of goods (assets) etc.
>
> Maybe... open to discussion on which spec each of these things go in.
> It's all good as long as the narrative is clear.
>
> > The channel selection or other specifications should allow for this and
> > provide extension points for this explicitly.
>
> +1
>
> > True. But again, I see this as an optional step that doesn't justify
> > thee amount of airtime it's getting.
> > (Maybe my timing in joining the group is just unlucky?)
>
> Your timing in joining the group is exceptionally unlucky... we hadn't
> been discussing identity much until just a few weeks ago. :)


I am beginning to realise that. Sorry for the noise.

> I see your point but I would counter that by saying, if the major
> > players are adopting that standard the cruft get's quickly hidden from
> > the implementer by being core to whatever library they build on.
>
> Cruft has a fantastically huge cost when you're talking about Internet
> and Web infrastructure. We aren't designing a software library here,
> we're designing part of an infrastructure that 3.4 billion people are
> going to be using by the year 2025. We don't want 70% of that
> infrastructure to consist of cruft.
>

True. So let's find the compromise between re-inventing the wheel and
carrying baggage into the standard.


> > Call it simplistic but I see this process as similar to software
> > development.
> > You either find a base library that does most of what you need and
> > extend it or you start from scratch.
> > History tells us that most engineers will always want to go with option
> > 2 but the pragmatic programmer usually goes with option 1 for good
> reason.
> > - No need to become intimately familiar with the internals of the base
> > library
> > - Leverage the hard work and many eyes of the people that contributed to
> > the base library
> > - Benefit from the constant improvements and updates to the base library
>
> IMHO, looking at Web and Internet architecture design in those
> simplistic terms is a recipe for disaster. :)
>
> Designing technology and protocols for the Web is a different beast than
> standard software development and engineering.
>
> I understand the analogy that you're making, but having participated in
> the standards-making process for a while now, software engineering and
> Web standards engineering only share a few things in common.
>
> You build on top of standards that are useful, that much is true.
> However, building on top of standards that contain 70% cruft is a good
> indicator that what you're building on top of is probably not a good fit
> for what you're doing.
>

Thanks for being gentle with my fragile analogy :)
I Agree. I don't think we should build on top of anything if we only use
30% of it and 70% is baggage.


> Again, I'm not saying that OpenID Connect is 70% cruft, or that OAuth2
> is not useful. I'm saying that from what we've experienced to date, they
> didn't drop in as easily as some of the other technologies we've decided
> to build on top of (like RDF, JSON, JSON-LD, AES, HTTP Signatures, HTTP,
> URLs, etc).


Sure. As soon as I understand these better I want to try and replicate my
thinking for OpenPayee with them.

I am just cognisant of the fact that OAuth2 and Open ID are proliferating
and getting support from some important players.
Building on a standard just because it's popular may not be ideal but it
does give you much higher chance of your standard actually being adopted
(surely the goal?).

Adrian

>