Re: [Tokenization] Attempt to synthesize Token Usage Type from 1 May discussion

Please see below...

On Wed, May 2, 2018 at 10:12 AM Ian Jacobs <ij@w3.org> wrote:

>
>
> > On May 2, 2018, at 12:07 PM, Peter Saint-Andre <stpeter@mozilla.com>
> wrote:
> >
> > Thanks, Ian! One comment inline.
> >
> > On 5/2/18 10:03 AM, Ian Jacobs wrote:
> >> Tokenization Task Force participants,
> >>
> >> Yesterday we discussed [1] tokenization use cases and corresponding
> request data requirements
> >> related to "token usage types”. I’ve updated the spec [2] based on the
> discussion and welcome
> >> review. I’ve pasted the new text below as well.
> >>
> >> Ian
> >>
> >> [1] https://www.w3.org/2018/05/01-wpwg-minutes
> >> [2] https://w3c.github.io/webpayments-methods-tokenization/
> >>
> >> ====
> >> Token Usage Type values
> >>
> >> * "one-time"
> >>   The payee expects to use the token only once (e.g., for guest
> checkout).
> >
> > Do we want to conflate one-time-use token and guest checkout? In my
> > experience, guest checkout allows you to not create an account at a
> > merchant website, whereas creating an account does not necessarily
> > involve allowing the merchant to store a card on file for future use
> > (but might be convenient to view past orders, create a wishlist, etc.).
>
> (I look forward to hearing from others on this.)


I think adding more examples to the "e.g." clause might make this clearer.
We might say "e.g, for processing a single transaction or for guest
checkout"
But I also agree with Peter that guest checkout does not necessarily add
too much value here as it implies a stance about whether an account is
created at the merchant for the user. I think the spec should not have an
opinion on this point (e.g. account creation). The spec should focus on
indicating that this is for a single use.


>
> >
> > Also, we noted in the conversation yesterday that a one-time-use token
> > might involve multiple charges (e.g., because of split shipments). I'm
> > not yet sure how that factors in…
>

The way I look at this is - "one time" tokens really mean a token that can
be authorized once. Beyond that, there are many other things that can be
done by a merchant with an auth, such as
A charge
An update to the authorization
A partial refund on the charge
Another partial refund on the same charge
A new "add on" related transaction (e.g. the second partial shipment, if
the merchant code allows it)
etc etc
So if we want to be totally descriptive in our name, we will end up with
"one-time-use-that-also-allows-partial-capture-and-partial-refund-and-many-other-things",
which of course would not be terribly useful.

My point is - calling it a one time use token should mean that you can use
it for a single authorization, and that you can then do anything else that
a merchant can do with an auth (e.g. the list above).
We can clarify all of that in the text, of course.


> I will update the definition to say that. (And hope that others with
> detailed knowledge refine/correct the definition.)
>
> Thanks, Peter!
>
> Ian
>
>
> >
> > Peter
> >
> >> * "card-on-file"
> >>   The payee expects to re-use the token for as yet uknown future
> transactions, including payer-initiated transactions and payee-initiated
> transactions (e.g., for partial shipment, incremental charges, and
> resubmission use cases). Whether and how the payee requests a new Token
> Cryptogram for future transactions is outside the scope of this
> specification.
> >>
> >> * "recurring"
> >>  The payee expects to re-use the token exclusively for a recurring
> payment according to an agreement with the payer.
> >>
> >> --
> >> Ian Jacobs <ij@w3.org>
> >> https://www.w3.org/People/Jacobs/
> >> Tel: +1 718 260 9447 <(718)%20260-9447>
>
> --
> Ian Jacobs <ij@w3.org>
> https://www.w3.org/People/Jacobs/
> Tel: +1 718 260 9447 <(718)%20260-9447>
>
>
>
>
>
> --
- Michel