Card Payment Security Task Force -- 02 Oct 2019

Card Payment Security Task Force

Infoshare

David: I found interesting the discussion of 3DS and privacy at TPAC

TPAC next steps

Ian: What happens next re: data model?

IJ: Other takeaways from TPAC?

rsolomakhin: Tomasz mentioned that in WebAuthn land it's possible to authenticate multiple origins
... e.g., EMVCo might have a list of origins and when origin A authenticates, origin B will accept it

IJ: Sounds like an out-of-band agreement

Rouslan: Maybe we should not hand wave and hear from others...

Brian: There's some crossover with the WebAuthn conversation

IJ: Where should the conversation happen?

Brian: TLD+1 adds wiggle room for how this might work
... WebAuthn is locked to a specific relying party domain (e.g., merchant)
... looking to open that up into a trusted third party provider
... the relying party might reach out to a domain
... but question is how do we know that the third party is trusted

Trust Tokens

[Ian and Brian chatting about WPSIG discussion]

SRC Demo by Rouslan

[Instrument in the sheet!]

rouslan: This does not require changes to API and implementation.
... the Chrome implementation today shows wallets not instruments
... what we are doing here is to have one payment handler per card
... payment handler information is "generated on the fly"
... so this demo shows two payment handlers, but they are "managed by the same code"
... they share the same code but for the label / icon
... we generate URL paths on the server side
... so we are technically showing N payment handlers, but to the user they look like N instruments

Tomasz: Thanks, Rouslan. This is an interesting approach
... we are still looking at this and we'll get back to you
... you are saying that there are 2 payment handlers in the demo (one per card)
... how does the browser discover that there are new cards?

IJ: When there was one payment handler, that could happen automatically

Rouslan: In this scenario, user would have to visit web sites for the updates

Tomasz: We'd need to document what user has to do if user has to install a new payment handler for each new card

Rouslan: Single click can be used for multiple payment handlers.
... and zero clicks needed; can be done on install

Tomasz: I am thinking about case where, outside of web payment, user is enrolling card through some experience
... user lands on DCF, which then installs the payment handler(s) for the recently added card(s)
... great if no user gesture is required

Rouslan: I was experimenting with redirect.
... payment handler gets name/icon from Web App manifest
... I was using different web app manifests (one per handler)

Tomasz: Redirection would be difficult. We'd like to do in a seamless way without redirections.

IJ: Another topic is mix of payment handlers and instruments
... How painful was it to design this?

Rouslan: Fairly easy. But one disadvantage is that the Web App Manifest and specific URLs are dynamic (per user)

IJ: Not "dynamic" but rather "per card-user"

Tomasz: Does the URL need to persist?

Rouslan: No, it can be temporary
... but what does need to persist is the service owrker

<Zakim> Ian, you wanted to ask about instrument display preference

Rouslan: Chrome will periodically check for updates to code (based on where service worker was installed)
... if you can have one service with multiple scopes....

Ian: Is that allowed?

https://w3c.github.io/ServiceWorker/v1/#service-worker-registration-scope

Rouslan: If you can share a service worker file but have multiple scopes, that would work

https://w3c.github.io/ServiceWorker/v1/#service-worker-url

Rouslan: We'd like to ask people to try out this approach and see whether it suffices.

Ian: Should we remove bits about instrument level display from the spec?

Rouslan: PH API is out of date

Ian: I will raise separately what we need to do for updates (now that there have been good changes)

Tomasz: How would "add card" work?

Rouslan: You could have an "add card" payment handler...but the ordering of that wrt other payment handlers would be important
... Regarding updates to PH API
... Edge time asked that JIT and skip-the-sheet be documented
... I am coming around to supporting the idea that the experience be well-documented
... I am more and more in favor of specifying how the browser behaves (without exact details of UX)
... I was hoping we'd get Edge volunteers to help add the text
... let me bring this up with my team