Re: Thanks!

On Mon, Dec 8, 2025 at 1:41 PM Stephen Mcgruer <smcgruer@chromium.org>
wrote:

> Hi Julien,
>
> Apologies for the late reply, as I was on vacation for a few weeks after
> TPAC. Even if the WPWG meeting times are not feasible for Japan (sorry -
> maybe given enough interest there could be occasional JST-friendly
> meetings?), input/thoughts via email always works too in my opinion :).
>
> > I found the credit card-centric discussions confusing, as it was
> sometimes unclear if we were talking about actual credit cards or about
> payment instruments sharing some of their characteristics (e.g.
> mediation/attestation/verification…).
>
> From my *personal* perspective, this is a bad habit we all have in the
> WPWG, of trying to focus on generic instruments but using cards as all of
> our examples. Part of it is our historical make-up and geographic make-up
> (card payments are still incredibly common in both NA and EU), and part of
> it is (with apologies for the bluntness) that those involved in non-card
> payment methods have not consistently shown up or brought needs to the
> group, even when solicited. (There are exceptions to that statement, and I
> apologize for the generalization to those folks!)
>
> As a browser maker we are heavily invested in making payments better for
> *all* our users, many of whom are in markets where credit cards aren't
> the common way of paying, and I always welcome hearing about a non-card
> payment problem on the web that we can help with :).
>
> > Will 16-digit plastic cards still be relevant by the time SPC reaches
> REC level? They're an antiquated proof of possession with no real rationale
> for existing anymore in the age of tokenized digital wallets, and the
> latter offer more space for designing robust flows. I think Nick Shearer
> made a similar point earlier this week.
>
> Respectfully, I think they will be. People don't change their behaviour
> that fast - we have had wallets supporting tokenization for decades, and
> still credit cards are over 1/3 of e-commerce payments (by volume, by
> transaction value they are higher) in the US. Again it varies in other
> markets (digital wallets are 70%+ in Asia-Pacific I believe, but credit
> cards are still > 50% of volume in Latin America, and ~40% in EU...)
>
> Anyway, despite all that, I do still agree that we need to push to not
> only focus on cards :).
>
> > Finally, I feel that payment is just a specific case of a much more
> generic problem space around intent, delegation and traceability that we
> are circling around a solution for. Why is it Secure Payment Confirmation
> and not Secure Intent Confirmation? What makes paying for a cowboy hat on a
> merchant's website so different from, say, changing the beneficiary of my
> life insurance on my insurance agent's website?
>
> I find it interesting that you (rightfully!) point out that the group
> struggles with dealing with the immense space that is 'just' commerce in
> the previous paragraph, then suggest we switch from payments to all of user
> intention in this next one :D.
>
> But this is a good question. Historically, folks across payments and
> identity did push the browser makers (hi, that's me!) for a generic signed
> intent mechanism. And the browser makers refused, largely because it was
> too liable to be abused by websites - if a website can write anything and
> have it appear in formal text that will then get signed by the user, then a
> website can use this surface to attempt to scam or abuse the user.
> Restricting the scope to payment intents makes this tractable for us - we
> can use structured data around the intent, build UX based off of that, and
> be more sure as a browser that the user is not being scammed.
>
> However, that viewpoint may also be changing. See the 'intent mandate'
> concepts from AP2, which are basically the same thing - completely generic
> text for the user to read and sign over. Will browsers be happy to present
> that to users in browser-level UX (and/or allow the OS to do so)? I don't
> know! It's a reasonable question for us all to keep exploring :).
>

I agree this is a very good question, and it's of a type that we often
struggle with in web platform API design. Do we try to solve the harder
more general problem or the more tractable specific problem? Usually these
days we do some of both (eg. see CSS and Canvas) and use the usage of the
more general approach as a way to help us prioritize the more targeted
features.  Some of us have regrets from going too far the other direction a
decade ago with the extensible web manifesto
<https://github.com/extensibleweb/manifesto> - it turned out that caused us
to focus so much on general solutions that we didn't solve as much as we
hoped to in practice, or achieved only lower quality solutions through
fragmentation of the solution space (tons of JS framework for solving a
problem like scroll-linked UI effects, none of which work very well).

In this specific case, having a trusted UI which we know is about a payment
is a big advantage. It lets us avoid all the abuse issues with
trustworthy-looking
UI <https://developer.chrome.com/blog/dialogs-policy> which can have
untrusted content inside of it. Specifically, if we launched such a general
feature I know we'd very quickly find websites using it with text like
"ALERT: A virus has been detected stealing your personal information. Would
you like Microsoft to remove it for you?" etc.

I think our more general bet for intent confirmation is probably the wallet
escape hatch that is the Digital Credentials API
<https://developer.chrome.com/blog/digital-credentials-api-shipped>, or
even more generally the custom schemes navigation mechanism that lets any
website communicate with any wallet / authenticator in whatever fashion it
wants. If we see a lot of usage of those mechanisms taking off for use
cases like approving beneficiary changes, then we might look into being
able to give developers a more integrated solution as an option (in
addition to doing the general thing via a wallet app).


> --------
>
> One again, thank you so much for taking the time to write up your
> thoughts! I am sure the group would love to continue to hear input from
> participants around the globe going forward :).
>
> Thanks,
> Stephen
>
>
> On Sun, 16 Nov 2025 at 07:49, Cayzac, Julien <julien.cayzac@rakuten.com>
> wrote:
>
>> Hi everyone!
>>
>> It was my first TPAC. I learned a lot from all of you. It was very
>> humbling!
>> I wish the time zone difference didn't make the time of the regular calls
>> so brutal for us in Japan.
>>
>> Following are a few comments on the discussions, that I thought did not
>> deserve to intrude on meeting time:
>>
>> I found the credit card-centric discussions confusing, as it was
>> sometimes unclear if we were talking about actual credit cards or about
>> payment instruments sharing some of their characteristics (e.g.
>> mediation/attestation/verification…).
>>
>> Although credit cards certainly should serve as a basis for payment
>> instrument characteristics that the platform must support, IMHO designing
>> an API around (or let's say giving too much weight to) a legacy payment
>> instrument might be unsound. Will 16-digit plastic cards still be relevant
>> by the time SPC reaches REC level? They're an antiquated proof of
>> possession with no real rationale for existing anymore in the age of
>> tokenized digital wallets, and the latter offer more space for designing
>> robust flows. I think Nick Shearer made a similar point earlier this week.
>>
>> For the same reason, I liked Ian's suggestion to make DPC a generic
>> payment instrument for PR, as it uncouples the payment intent from the
>> underlying payment instrument. I hope this gets explored further. The
>> dimensionality of the use cases this group is trying to cover is very
>> large, and we have so many interests represented, that I think decoupling
>> the most things can only benefit moving things forward and reaching
>> consensus. I think my brain collapsed when commerce entered the room on
>> Thursday :)
>>
>> Finally, I feel that payment is just a specific case of a much more
>> generic problem space around intent, delegation and traceability that we
>> are circling around a solution for. Why is it Secure Payment Confirmation
>> and not Secure Intent Confirmation? What makes paying for a cowboy hat on a
>> merchant's website so different from, say, changing the beneficiary of my
>> life insurance on my insurance agent's website?
>>
>> Anyway, thanks everyone for the super interesting week!
>>
>> Cheers,
>> Julien.
>>
>