Re: [Blog] Summary of TPAC 2018 WPWG meeting

> The generic token contains an URL pointing to the bank where it can be
redeemed.

This is how I'd propose to design the scheme too, it's a very flexible way
to provide tokens that can be used on more open ecosystems than the current
networks so it future-proofs things nicely.

>  The generic token is encrypted by a bank key eliminating the need for
external token servers.

This is also the goal. The token should be mostly opaque to everyone in the
chain. The "issuer" (bank, wallet etc) is creating a token that only they
need to understand when it is finally redeemed so no need to make it
readable by anyone else. That said, some data needs to be visible like a
human-friendly label and meta-data like the token type (single-use vs
multi-use etc) and most importantly the network(s) on which it is redeemable

> - A security/trust architecture building on an enhanced version of the
traditional "four corner" model eliminating [front-end] payment
intermediaries for most payments.
> - A discovery solution enabling the parties to perform further checks
before executing a transaction or transaction request.

I don't know what these sentences mean, they don't explain any details.

If you are able to provide input to a generic tokenization payment method
specification then that would be very helpful.


On Fri, 2 Nov 2018 at 17:39, Anders Rundgren <anders.rundgren.net@gmail.com>
wrote:

> On 2018-11-02 15:05, Ian Jacobs wrote:
> > Dear Web Payments Working Group,
> >
> > I’ve written a blog post to try to summarize our FTF meeting:
> >
> >   TPAC 2018 Recap
> >   https://www.w3.org/blog/wpwg/2018/11/02/tpac-2018-recap/
>
>
>   "For the second topic, Generic Payment Tokens, Adrian described
>    the pitfalls of push payment flows: where the user’s bank
>    initiates a payment (e.g., credit transfer) outside of the
>    control of the merchant. Adrian offered an alternative flow
>    where the party that initiates a pull payments returns a
>    (“redeemable”) generic token through Payment Request API.
>    The merchant can subsequently use the token to initiate the
>    payment from the user’s bank. (I believe this is how direct
>    debits work; please comment below if I am mistaken.) Adrian
>    described a vision where merchants would declare through
>    Payment Request API “I accept the generic token payload
>    from the following networks,” and this would enable payment
>    handlers to innovate and support different payment networks"
>
> Interesting, this is exactly how the Saturn payment authorization scheme
> works!
>
> However, Saturn adds several enhancements to this "push with a twist"
> scheme:
> - The generic token contains an URL pointing to the bank where it can be
> redeemed.
> - The generic token is encrypted by a bank key eliminating the need for
> external token servers.
> - A security/trust architecture building on an enhanced version of the
> traditional "four corner" model eliminating [front-end] payment
> intermediaries for most payments.
> - A discovery solution enabling the parties to perform further checks
> before executing a transaction or transaction request.
>
> What's missing then?
> A lot, including:
> - p2p payments using the same account credentials
> - real-time account status
> - electronic receipts
>
> A peer review of security solution would also be nice :-)
>
> Anders
>
> https://github.com/cyberphone/saturn/blob/master/PSD2.md#saturn---optimized-for-payments
>
> >
> > Feel free to share and add comments. If you spot any errors, please let
> me know. Thanks!
> >
> > Ian
> >
> > --
> > Ian Jacobs <ij@w3.org>
> > https://www.w3.org/People/Jacobs/
> > Tel: +1 718 260 9447
> >
> >
> >
> >
> >
>
>
>