We discuss feedback on the Proposed Architecture for SRC through PR API
Fawad: We like this architecture
more than one-instrument-per handler
... we are generally supportive and have some questions like
who will host the common payment handler
... we are supportive of doing a proof of concept but would
need to learn more about the resources required wrt POC
IJ: What would you need for a POC?
Fawad: What do we need to do to
have access to a common payment handler?
... We are continuing our internal deep dive.
Sophie: We've begun our internal
review; have not completed it
... we haven't identified any showstoppers yet
... hope to have more concrete feedback for next call
Jalpesh: While this proposal
looks technically feasible. we don't see it as adding a lot
more value than current implementations. It requires SRCIs to
do more work
... we'd like an experience that relies less on local storage
and legacy technology
IJ: I understand a goal of keeping user session alive as long as possible
Jalpesh: Storage at a higher level - cards, session
IJ: Would credential management help¿
stpeter: My understanding is that
concerns are not limited to cookies (e.g., clearable
indexDB)
... if we are depending on existing local storage, it's going
to be possible that the payment handler lose the
association
tomasz: In this proposed
architecture, the approach is based on existing storage
capabilities (mostly indexDB)
... because the browser is not providing identification, we
have to work with what we have
... the assumption here is that the SRC system generates the
token, which is then storage in indexDB on the browser
side
... but if the browser could provide some sort of identifier
for the device, that would be better...and we would use this
identifier within the SRC system
Jalpesh: I have a clarifying point. If a browser had built-in support for the payment method would this still be an issue?
<AdrianHB> I think native payment handler on Android would persist user sessions beyond browser data refresh today
Jalpesh: Suppose another browser
supported the payment method built-in, would it still rely on
indexDB for storage?
... does this current proposal allow for native payment handler
approach?
tomasz: If there is full built-in
support for SRC in a browser, then I would say that this
proposed architecture would not be required. But then there's a
lot of responsibility within the platform (browser or broader
platform) to carry out SRCI and DCF roles
... the current architecture leverages existing relationships
and code
... if there is built-in support in the browser, I think it's
possible to use the same princple
Jalpesh: There is a portion of
this proposal that we like, from how the developer / merchant
calls API. But I have similar concerns about the payment
handler side, both with issues about legacy storage approach
and also hosting common payment handler.
... but if same architecture could work with built-in support
that would be good...maybe separate the proposal into parts or
clarify which works in browser and which relies on third
party
Tomasz: I can help with
that
... we did some investigation into this
... we prepared similar flow diagrams for built-in solution
cases
<scribe> ACTION: Tomasz to add built-in flows to SRC wiki
https://github.com/WICG/trust-token-api#extension-trust-bound-keypair-and-request-signing
<Zakim> tomasz, you wanted to ask about WebCrypto API?
<Chris_D> Just to note, there seems to be an issue with the webex for me today and I am unable to connect audio however I try, so I will follow on here as best I can.
tomasz: I want to ask about
WebCrypto API
... would that help us here generating keys?
... is this data context-bound?
... and how is it cleared?
<AdrianHB> Do I understand correctly that the high level requirement is a user identifier that persists user's clearing their browser data?
JeffH: Chrome implements WebCrypto API. My vague understanding is that a Web site can do these things doing Web Crypto...but detail smatter
<AdrianHB> (specifically one that is only used for payments and therefor is treated differently to cookies etc)
Gerhard: WebCrypto lets you get
key pairs. Not a storage mechanism on its own
... so you would still be using indexDB
... and if you clear storage it gets cleared
<AdrianHB> If the desire is special storage for payment credentials that persist "longer" can we explore using Payment Handler instruments?
stpeter: One thing I think we
should think about is - the browser is the user's agent.
... users still need to be able to clear storage
... Need to be clear communication to user if they are signing
up to something that they "can't get out of"
IJ: I want to see if we can solve this as "make it easy for me to get in" instead of "hard to get out"
AdrianHB: You'd have to create a
special category for payments
... perhaps we can empower sites when known to be in the
context of a payment (in the APIs)
... and we should explore ways of having a more persistent user
identifier or session identifier, but only available in the
context of payments
... Chrome and other browsers let you clear categories of
information, some cleared by default others not
... if payments were available as a category, not clearable by
default, that would be interesting
<jonathan> sorry for joining late..
<tomasz> In Chrome: passwords and autofill data is disabled on the list of things to clear in Settings.
IJ: Are passwords cleared by default in browser? If not, then I am wondering whether we already have a lot of what we need: user saves password in browser, user clicks "ok" to re-login so that's easy, and passwords not clearable as easily.
stpeter: The browser can do some things that don't open up the can of work with tracking and arbitrary data storage
IJ: What is the real problem statement? I'd like to hear more clearly
Tomasz: The current architecture
relies on existing storage approaches. If we had other
capabilities, that would be preferable. Identification of the
browser is property of the browser.
... so not asking the browser to store more data from the
payment handler.
... I understand there are considerations related to privacy
and tracking
... stable identification would improve the situation.
IJ: Is the problem statement "stable recognition of browser across transactions"?
Tomasz: Partly. We'd also like to
have non-exfiltratable identifier
... so we'd like the identifier to be non-leakable / or
inherent to the browser
jalpesh: I think persistent
device id would be welcome
... the second thing I'd say is to reinforce that third party
payment handlers might require more work from common payment
handler and SRCI
... I'd like to make sure that built-in support be part of the
conversation
IJ: Why would other SRCIs exist if built into the browser?
Jalpesh: There are two functions
of SRCI, one is to deploy software across networks on behalf of
a merchant. They are integrating payment methods on behalf of
merchant
... in current implementation, we need SRCIs to do more ---
present cards
... in the context of PR API, that portion is not necessarily
by PSPs or merchants, it's done by browsers.
... the consolidation of payment methods is still done by
PSPs
<Zakim> AdrianHB, you wanted to ask for clarity on defn of native payment handler
AdrianHB: When you talk about "native payment handler" do you mean "native app on mobile" or "built-into the browser"?
Jalpesh: Built into the
browser.
... The user agent should be able to define a customer UX for
SRC
AdrianHB: You talked about second
SRCI role as displaying cards to user
... it's confusing to me why the SRCI (in the merchant domain)
displays instruments (held in the user domain)
Jalpesh: SRCI needs to consolidate cards across networks. The browser would play the role of DCF, not the SRCI
IJ: How common is scenario where SRCI is not party in the merchant site?
tomasz: I like the property of
decoupling merchant side from user side. The user experience
from PR API is the great value.
... we like the modal window of payment request...better than
iframe, popup and redirect
tomasz: for us, even in a situation where the SRCI is already PSP, there is still a benefit because of the modal window
Jalpesh: I am familiar with that perspective.
(Ian mentions previous Stripe demo at WPSIG meeting)
Gerhard: There are larger
questions about open banking...
... Our focus is on the issuer
IJ: Any other thoughts on identifiers in the browser
JeffH: My understanding of this
desire for some form of browser identifier or device identifier
really comes form an anti-fraud use case
... given the current trends in browsers to maximize privacy
and minimize user tracking, I don't see how burying something
in the browser that identifies the device and/or software
indelibly is going to get traction
... that said, certainly Web Authentication gives strong
customer authentication, so you can have strong assurance that
the user is the same user, whether or not they are using the
same user agent
... it could be that some the payments folks need to rethink
some of the anti-fraud approaches in this brave new world
13 May
<AdrianHB> +1 to jeffH "it could be that some the payments folks need to rethink some of the anti-fraud approaches in this brave new world"
<AdrianHB> WebAuthn has become widespread very quickly
<AdrianHB> It offers a great UI
<jeffh> shucks, thx :)