Meeting minutes
Welcome
<Ian> [To raise your hand, type q+]
<Ian> Antitrust guidance
Context Setting for this meeting
[Adrian Hope-Bailie slides to frame the meeting]
AdrianHB: As the group thinks about its work at this tpoin, here is an order of priority of Web platform capabilities (proposed):
- SPC
- Payment Instrument Selection
- Secure modal window / in-context display
AdrianHB: I think we will focus on the SPC piece at this meeting.
...we have done a lot of work on it lately
...might also spend some time (but more likely in the future) on instrument selection and modal window
NickTR: If we can deliver *Pay experience in the browser, that would be great.
Stripe Experiment Results
[Benjamin Tidor slides on Stripe experiment]. See also the enrollment video and the authentication video.
btidor: Those are the slides from the 18 March presentation. Today I will dive a bit deeper on UX and ideas for second pilot
...Adrian mentioned instrument selection and authentication, and decoupling these
...I think that makes sense and happens this way in the real world
...e.g., you need card number to kick off 3DS
...SPC intended to be compatible with all flows/systems but the pilot was focused on 3DS
...several superpowers in SPC compared to WebAuthn alone:
- Browser binds payment details into cryptographic signature
- Any merchant can request a signature from the issuer's public key: cross-origin credential sharing
[Videos of the enrollment and transaction flows]
btidor: First you enroll your authenticator
...there's a redirect to the issuing bank
...in the pilot we used a secure modal window (from a payment handler) for the user's enrollment to the issuer.
...that is because we had a first party context in the secure modal window
...after successful ID & V (OTP) the user is prompted to enroll the authenticator
...under the hood, standard webauthn exchange. The issuing bank provides to the browser (1) card art (e.g., masked card number) and (2) logo. The browser memorizes this and uses this for subsequent display of information (e.g., in the tran saction confirmation dialog).
...so it's an enhanced Webauthn PaymentCredential
mweksler: Does the enrollment happen once per merchant or per browser (hoping it is the latter)?
btidor: In this scenario, once with the issuer. After that transaction can happen across different merchants.
[Benjamin shows authentication flow]
btidor: Merchant can validate the assertion as well using public key from the issuing bank. The issuing bank can ALSO verify the assertion. The issuing bank doesn't need to trust the merchant. All the information in the signed data blob was presented and controlled by the browser
Deepu: Regarding the 3DS enrollment flow. How does this differ from PH API?
btidor: We used the Payment Handler API. We used the modal to do the redirect.
...we would like to discuss enrollment flow standardization (to eliminate service worker requirement)
...we can discuss this as part of SPC or a separate work stream
Gkok: I recall enrollment success was around 20%. Could that be affected by strings only in English?
btidor: Great question. Localization is important.
Tomasz: Did you work with any issuer or ACS?
btidor: We did not. (I am showing mockups)
Tomasz: How will ACS know this is a regular Webauthn credential v. enhanced credential?
... If the ACS has a credential id, how will it know which type of credential?
Gavin: btidor mentioned a "secure modal window"...remind me what that is?
btidor: You get that window in the payment handler API. (And adrian hb mentioned it as a general architectural feature of interest)
<Ian> (In short: you get the secure modal window as part of Payment Handler API)
Gavin: what makes it "secure"?
Ian: The displayed URL (at the top of the payment handler window) is managed by the browser and (in some sense) is phishing-resistant.
NickTR: You'd have to break the browser
Sebastien: Is biometric FIDO required? Or can PIN-based FIDO authenticators be accepted too?
btidor: For the pilot we limited ourselves to TouchID. But the anticipated scope is "any verifying platform authenticator".
...this enables the browser to check silently if you have one, otherwise allow seamless fallback
...The key behavior for browser: if you don't have an authenticator, need silent fail to allow for seamless fallback.
...regarding user presence check...some jurisdictions may require user presence check, but during this meeting we should also talk about flexibility to drop that requirement
Tomasz: Here is the GH discussion I was referring to while speaking about the need of more detailed specification of assertions: https://
Deepu: Is the modal window the same used by the sheet?
Ian: We need to define what "same" means. In the current Chrome implementation, the sheet is owned by the browser and the payment handler window is opened by the origin. They take up the same real estate on the screen, however.
btidor: The window we show is launched by the service worker, which controls the whole flow
Deepu: Just to confirm: a goal is for this to work with all payment methods?
btidor: Yes.
Deepu: What type of payments were covered in the scope of the pilot?
btidor: Global card payments
Ian: We have a variety of payment methods represented at this meeting and want to hear requirements
NickTR: I also think Ideal would be good
Srini: Would delegated auth be supported with SPC? (e.g., would SPC API be capable of sending out a 3DS FIDO blob to the merchant?)
btidor: Yes. It does not have to be the issuer who enrolls the credential. many parties could do so
...the assertion (webauthn + a little bit of data) should be insertable in a web Authentication context
NickTR: If I were to add to the shopping list, I would add delegated auth
btidor: One really special thing about SPC..if the issuer is aware of SPC data, may strengthen use case for delegated authentication
Ian: Today, the secure modal window is only available in payment handlers. We've talked about it as something available outside payment handlers. Will be interesting to hear from group later about priority we have in mind (auth, selection, modal) and whether the industry agrees.
ChrisD: What does a payment flow have to have in order to be SPC? E.g. do you have to offer the WebAuthN authentication ahead of any fallback mechanism or could you do a risk-based authentication and fallback to WebAuthN via the Secure Modal only if RBA was not possible? What makes something "SPC"? For example, if you attempt a risk based authentication first, is that part of SPC?
...or is SPC more specific?
btidor: You can imagine running risk-based auth first, then SPC
ChrisD: So is scope of SPC WebAuthn, or is it not tightly coupled to WebAuthN?
btidor: I think the transaction confirmation window should be tightly coupled to SPC.
...no identifying information should be given back to the merchant before the user hits "Verify"
...I think we can increase flexibility about WebAuthn or not
<Gerhard> +1 agree
AdrianHB: Tomorrow we will talk about lower-friction flows
...Agree with Benjamin that the core thing is the transaction confirmation window
<Ian> [Ian: I think that we should not rule out low-friction as part of SPC]
[Benjamin returns to experimental results]
btidor: At a high level, SPC increased conversion and decreased authentication times.
...today I'd like to talk about ideas for a second pilot
... We want to experiment with traditional iframe compared to modal window. users are not familiar with Modal window and may be thrown off.
...might have led to some people dropping out.
...I do really like the secure modal window.
...I like the secure origin in the title and think it addresses cross origin security policy issues
...but we may want to look at iframe approach...
...we'd like to try enrollment in iframe context
...browser might have to give more context in an iframe world...telling the user what's happening (enrolling a context to a 3p)
...in a 1p context that context may not be required
...So if you are invoking enrollment from iframe, we might want browser to provide context
...that might involve another click, but it might be less of a departure from the UX people are familiar with (iframe)
...Another thing we'd like to test is to include proper 3DS binding
...users recognize today's flows and we want to see if we can replicate the UX people are familiar with
...even though we changed the UX enough, users liked it..and that gives us confidence in the overall project
..but we'd like to see if we can get the enrollment prompt to come from the issuer and be branding as usual
...I realize there are limits potentially to what we can do in the browser's trusted UX as far as logo location
...Lots of people hit the cancel button on the transaction confirmation dialog.
...one reason might be the time elapsed and difference in look and feel between the UX associated with enrollment and the authentication screen
...I think that an iframe enrollment is likely to look more like the authentication screen and that could help raise comfort levels
...You can try this out yourself in Chrome (by flipping some chrome switches and using the SPC demo page
SameerT: +1 to discussion about iframe and secure modal window. Traditionally iframe has been preferred over redirect because of how seamless it appears to the user and users are educated to not trust a URL they don't recognize (not visible in iframe), curious to see if secure modal window can address some of those concerns in collaboration with EMV 3DSWG
MWeksler: I was reacting to the "more clicks" proposal
...It should also be possible to do enrollment outside payment flow
...Regarding authentication, I would not be too concerned about the existing UI
...better UI is better. I would encourage us to not be too hung up on what currently exists.
SameerT: We don't want merchant to wait for enrollment in order to get paid.
btidor: +1 to getting rid of extra click if we can; perhaps there are other ways
<Ian> ...in my mind, whitelisting flows from 3DS could be useful: remember this merchant and don't ask me a second time
MWeksler: +1
NickTR: PSD2 has "trusted beneficiary" concept. In some auth flows, you can check box to say "You don't have to do a step up in the future with this merchant."
Ian: What would that change in the SPC UX?
btidor: Enrollment is provided by a separate screen. The issuer can say "While you are waiting for your text message, do you want to set up biometric authentication?" Having one screen might be the fasted way
Tomasz: User says to issuer "This is a trusted merchant"
...next 3DS flow can involve silent flow and no SPC flow
James: As a consumer, I'd give a big +1 to being able to enroll out of band at the bank site.
...banks say "we will never ask for your password"
SameerT: Potential topic for exploration - Modular use of SPC so that ACS/Issuer could use part of the solution after their risk assessment or with credentials enrolled with the acs/issuer outside of 3DS
AdrianHB: +1 to SameerT
btidor: I think that if a user uses 3DS a lot, they will be more familiar with the flow
...a cool thing with SPC is that a bank can "upgrade" an enrolled WebAuthn credential (by adding payment info) and then those can be used in an SPC contxt
AdrianHB: We should not solve distribution problem.
...how an RP does "upgrade" should be solved by stakeholders
Benoit: +1
3DS Risk Assessment requirements
SameerT: We talked with the WPSIG about risk assessment in 3DS in light of changes to the browser around privacy
...today risk assessment leverages three sources of data: browser + user + transaction
...risk assessment is not black and white
...we want to create a requirements document (in collaboration with W3C) to figure out how meet risk assessment needs in light of browser changes
...the problem we want to solve: Is this the same device the user used with this card previously?
...in native platforms we have solutions with device identifiers
...For the Web, there have been two moments of collecting data: (1) 3DS Method URL ...javascript (2) AReq
...Today issuer is relying on a broad set of parameters
...this is an evolving set of data
...privacy controls are likely to lead to more step-ups
...there are no unique identifiers defined for transaction risk assessment
...cookies will no longer be a viable approach
...there is a lack of hardware based identifiers that could be derived from browsers for use in Risk Assessment
...Device recognition is and will remain a critical need for Transaction Risk Assessment in CNP transactions.
...we want to find a why to identify a browser in a unique, privacy aligned manner to be used exclusively for TRA in a payment context
Ian: An important question is "what amount of friction is small enough? "
SameerT: We have some solution goals in mind:
- new identifiers, potentially only usable in a payments context
- Alignment with privacy goals
- Solution does not interrupt ux during payments flow
SameerT: We have some solution requirements as well:
- Uniqueness per browser instance
- Generated and protected by browser core libraries and generated through Native API calls
- Resettable by the user
- user enrollment/consent takes place outside of payments context and does not interrupt payment flow
SameerT: The ideal solution will not:
- Allow tracking outside of payments context
- Enable super-cookies
- Create more friction than what we have today
SameerT: We are planning to record all this in a document, after some additional work in the EMVCo 3DS Working Group. That document should be available soon.
<Gerhard_> note: Tomorrow we hope to present an approach that should address this. Would really appreciate expanding on it.
btidor: What does frictionless mean...literally zero clicks?
SameerT: Not really
… the user should not see a prompt every transaction, but could be prompted the first time
… and agree to no friction moving forward