<Benoit_> trying to connect...
<jtoupin> @Ian, do you mind posting the webex link? Having trouble finding it.
<danyao> Hi Ian - sorry I'll have to drop at 11:30 due to another meeting.
<scribe> scribe: Ian
Jonathan: Email I wrote up is restatement of Ian's proposal for how SRC would work.
[IJ summarizing; will share text later with group]
- Each SRC system would have its own PMI (URL)
- Payment method manifests would identify payment handlers, including a default payment handler.
- Each SRC system would distribute a payment handler, and would identify a default payment handler (which might be referenced by multiple SRC systems)
scribe: the default payment handler could be defined by a variety of parties (including card brands or browser or other party)
[First time user]
Jonathan: We would like a
mechanism to recognize the user for future transactions in a
way that is not reliant on cookies
... it might be interesting to learn more about discussions
about browser-generated keys bound to particular origins
(in b vi, change "Mastercard payment handler" to "Mastercard site")
(in b vii, change "just in time registration" to "service worker registration of payment handler")
Jonathan: So at the end of initial flow, you have a payment handler with one card in it
[Returning user]
Jonathan: User sees two payment handlers - one with a card, and one for "add card")
a?
<Zakim> Ian, you wanted to ask about "log into SRC" behavior in default payment handler and to ask about limitations of cookies
Ian: What are you concerned about with respect to cookies?
Jonathan: Cookies can be removed
IJ: What is the full requirement that you have for which cookies are inadequate?
Jonathan: Cookies can be removed; so I'd like to have the ability to recognize a returning user without relying on cookies
IJ: Is your expectation that that token is not clearable?
Jonathan: I would expect the user to be able to make a decision...the consumer still has a choice
Tomasz: Suppose as a user I have 2 installed cards and both rely on cookies, and then cookies are cleared. What will happen if service workers no longer have access to the cookies?
David: If we go back to one
instrument per payment handler, couldn't that pass back a
unique value to whatever needs it?
... so the payment handler identifies the user and id is used
on the backend.
Tomasz: So the flow would be like this - the user is on the page where the SW is installed, and the SW gets a token, and it's stored in the browser. And then every time there is invocation of the payment handler, it would fetch this information and present it as a token. Is that what you are thinking?
<Zakim> danyao, you wanted to clarify trust token API and to clarify the requirements of identification
Danyao: Regarding the identity requirement, it seems like there are two requirements:
a) Default payment handler should be able to recognize the user, and
b) Once a payment handler has been installed, it also needs to recognize the user.
scribe: for case (b), what about the user needs to be sent to the backend. Do you need to know who this user is?
Jonathan: The working assumption
is that the browser does not provide any identity, but might
provide something (like a key) to an origin.
... in SRC there is a unique identifier (e.g., email
address)
Danyao: I would paraphrase this way:
- The SRC would like the browser to provide an attestation of the user's identity; the user is attesting "this is user A"
scribe: the SRC system needs to be able to differentiate user A from user B
Jonathan: And the SRC system on the backend will associate an attestation with a user identity.
Danyao: There is a proposed
extension to trust token that might be applicable here...where
the browser generates a key pair and returns the public key to
the requestor
... the browser stores the key in a secure place, and it is not
subject to clearing
... it's the responsibility of the client (e.g., the SRC system
) to associate that key with the SRC identity.
... then later the browser can prove that it is the owner of a
private key
... Let's hash out requirements by email
Jonathan: What you describe is what I'm interested in
https://github.com/WICG/trust-token-api#extension-trust-bound-keypair-and-request-signing
Ian: I am reaching out to the author of that stuff to learn more and maybe bring back to a call
stpeter: Mozilla doesn't have a
position yet on that proposal; agree more conversation is
required
... I will check with mozilla colleagues on that
<stpeter> See https://github.com/mozilla/standards-positions/issues/262 for the issue in Mozilla's standards-positions repo
IJ: What is it that you are optimizing for for returning users?
stpeter: My understanding from
SRC is that, what we care about, is the ability to encrypt data
end-to-end to the SRC system
... i'm not as clear on the identification requirement
Jonathan: Today a cookie will be
set to see if an SRC system has a card for a particular user.
But what we are trying to do here is to remove dependency on
cookies. And so can we find a better way for the src system to
recognize whether it's the same user on the same browse.
... the SRC system wants to know whether it is a returning
user
stpeter: It sounds like this is an equivalent of device binding.
Jonathan: Yes, I think so
Chris: From the scenarios
described above, what I got was potentially the default payment
handler could "fast track" registration a card into SRC. Is
that a goal?
... are you looking for a shortcut mechanism to enroll the
card?
Jonathan: I think that we may have other mechanisms than what is described here. So different use cases might lead to different flows; e.g., if same party distributes payment handler and is srci
callen: Are you talking about linking a browser-stored card to an SRC ecosystem?
IJ: Service Worker is persistent. Why does the server need to say more (e.g., via cookie)
stpeter: Regarding card stored in the browser and onboarding to SRC...I think that would be better to do outside of a transaction flow
callen: I think that's fine. I
think the key thing for the flow named here...someone said that
using cookies to identify the connection between payment
handler and SRC is not the best path forward.
... I think the right question is how to to identify a user
across the two ecosystems.
IJ: What is not sufficient with "service worker is associated with only one browser; can store info on server side?
Jonathan: Let me clarify this in
the next day or so
... the goal is for the user to not have to re-enter their SRC
identity
(IJ thinks the payment handler can manage that)
Jonathan: Let me clarify the flow / requirement over the next couple of days.
[Returning to jonathan's text]
Jonathan: If we do follow a "one
card per payment handler"...it's possible to have 2 cards from
the same origin.
... I want to be sure that that can be managed.
https://rsolomakhin.github.io/pr/apps/src2/
IJ: I had understood "yes" with different scope URLs
Justin: Yes, that's roughly my
understanding as well.
... if you look at Rouslan's flow, once you select a card you
go into a specific payment handler for that card
Jonathan: Let me jump to the last point on "canMakePayment" and "hasEnrolledInstruments"
https://www.w3.org/blog/wpwg/2020/01/17/working-with-canmakepayment-and-hasenrolledinstrument/
IJ: We will answer the question "when is hasEnrolledInstrument true" in the payment method definition
callen: A lot of people are talking about affinity between handlers and cards
https://github.com/w3c/src/wiki/ProposedArchitecture
19 February
Summary of what would be good to talk about at next meeting:
- Jonathan is going to revise description based on conversation today and also say more about id requirements
- Ian is going to look into browser generated keys
- Bring back open questions to the 19 Feb call
- Justin is going to double check on whether can have multiple cards per origin (in the 1 instrument per handler model)
acá callen