Card Payment Security Task Force

07 Aug 2019



Ian Jacobs (W3C), Laura Townsend (MAG), Dean Ezra (Barclays), Jalpesh Chitalia (Visa), Jonathan Grossar (Mastercard), David Benoit (Reach), Tomasz Blachowicz (Mastercard), Jonathan Vokes (Worldpay), Rouslan Solomakhin (Google), Brian Piel (Mastercard), Adrian Hope-Bailie (Coil), Peter St Andre (Mozilla)


<scribe> Scribe: Ian

Identity flows


[Jalpesh to drive flow review. We will post flow sequence diagrams on the Web once they have been revised after this discussion]

[First time user experience on a device]

Jalpesh: I am focused on UX here, not SRC details
... my understanding of the action item from 2 weeks ago is how the UX works
... from there we will have to document which SRC APIs are being called between the payment handler and SRC system(s)
... we'll talk about "first time" experience and "returning user" experience

[We walk through flow which will be available after the meeting, possibly with edits]

Jalpesh: When user types in card information, user can enter identity information. that might be as minimal as device info
... step up may occur at this point. This could be based on new card info, based on transaction characteristics, etc.
... depending on the request, card info, customer risk, there might be a step-up here.

Jonathan: It would be good to clarify what is meant by "step-up" here. Is it to check you own the identifier (e.g., email)
... or is it cardholder auth?

Jalpesh: This is doing cardholder ID & V and may also be doing transaction risk step-up at the same time.
... it might be issuer-driven step-up (cardholder verification)
... or merchant-driven (merchant wants higher assurance level)

IJ: I hear issuer always doing the step up, and at most one step-up.
... but that the motivations may vary according to merchant preference or issuer risk assessment.

Jonathan: Let's clarify here that this is CARDHOLDER AUTHENTICATION

Tomasz: I'm not sure it's the case that the issuer always does the step-up. The SRC system can do ID & V as well.
... the verification might be that the individual has access to the SRC profile
... so this might not be auth done by the issuer.

Jalpesh: Maybe we need to abstract that, and it may vary from SRC system to SRC system.
... so we could say that the SRC does auth or issuer does Auth.

Tomasz: so the step-up might have a different form (e.g., lightweight auth of email address using OTP)
... but if issuer-based, may vary depending on the issuer.

deanezra: There's a step before 7 where you are logging into the SRC system in the first place?

Jalpesh: There is no log-in per se. There is an identity presented. Minimum identity may be device info

deanezra: So you are saying you don't have to say "I am Dean"

Tomasz: What about the case where I am new user on device A and returning user on device B
... I would expect to have access to the same set of cards

Jalpesh: Let's also cover that flow

Jonathan: What is not shown here is access to the SRC profile
... in that case, there might be an auth step to ensure you have access to cards

Jalepsh: We may need a third flow.

Tomasz: So let's clarify "first time user for this specific SRC system"
... this user does not yet have a profile within a given SRC system

IJ: So on this flow just SRC System label, but on other flows SRC System(s)

Tomasz: You are saying that the payment handler orchestrates UX defined by the SRC system
... what if this is a 3DS flow
... will the Payment Handler display the issuer snippet?

Jalpesh: The PH has responsibility to do whatever the system asks for; whether OTP or whatever

Tomasz: The SRC system may not know how to handle the auth by the issuer bank. What if the issuer bank requires a mobile app?

Jalpesh: I assume the request goes back to the SRC system.

Dean: Is there an assumption that the issuer has integrated with SRC?

Jonathan: No special integration required, just regular 3DS flow reaching out to issuer for authentication
... mobile app is out-of-band authentication...that could happen in regular flow .... doesn't matter whether called in SRC flow or regular 3DS flow.

Jalpesh: So maybe the language needs to change in the diagram

Dean: A clarifying note on the flow would help...something like the flow saying that the UX may be part of a 3DS flow

Jalpesh: I didn't want to get into specific authentication methods here.

Tomasz: I think it's important to look into this nonetheless.
... how to integrate 3DS flow in a payment handler

Jalpesh: +1

Jonathan: +1

IJ: I am hearing we need to come back to 3DS in the payment handler

Jonathan: It would be valuable to have a separate flow to show the 3DS integration

IJ: Suggest adding "3DS" to this diagram just as a hook.

<scribe> ACTION: Jonathan to work with Tomasz on a new flow diagram showing the 3DS authentication in more detail

<trackbot> Created ACTION-125 - Work with tomasz on a new flow diagram showing the 3ds authentication in more detail [on Jonathan Grossar - due 2019-08-14].

Dean: Suggest a note at the beginning of this diagram that the profiles are not yet present when this flow happens

[Second diagram]


* Same user on same browser

* Different merchant

* Click on button to trigger SRC

* Get list of cards may reach out to multiple SRC systems

scribe: between step 5 and 6 there may or may not be a step-up depending on how the integration is performed

Tomasz: SRC 1.0 supports cookie-based recognition of the device. Alternatively, the SRC system features identity services to verify ID based on provided email and phone number.
... that would give the user access to the profile maintained by the SRC system.

Jalpesh: My assumption is that the payment handler may or may not have a user identity and may fallback on device identity.
... so if an identity is presented to the SRC system (whether device or user identity), the card metadata can be returned.
... and I agree that could be a cookie, or a token of some sort, etc.

Tomasz: +1; depends on the SRC system and what it allows.

Jonathan: Here we are talking about the candidate list

Jalpesh: The SRC system trusts the payment handler, and there may be trust between payment handler and browser

Tomasz: On the federated nature of identity in the SRC systems: if we have more than one SRC system available through the payment handler, each one SHOULD trust the attestation of identity verification by any one of them.
... that's part of SRC.
... attestation is a JWT issued by SRC system.

Jalpesh: Shared trust is based on identity...if in this scenario where identity is just a device,
... the JWT is also presented by the payment handler to all the SRC systems
... so it's a shared identity trusted by all the SRC systems
... Payment handler needs to pass the token to all SRC systems

deanezra: What about flow with new device?

Jalpesh: Good question, not captured in this flow
... we need a third flow for "Repeat user on a new device"
... the intention is that as long as the same identity is presented, the user can go and get the list of cards
... that would happen between steps 4-5 (on a new flow diagram)

deanezra: If it wasn't a device but rather "identity" as a repeat user, would there be extra flows where it would ask you to verify your SRC credentials?

Jalpesh: This is where the complexity and flexibility are trades. If there is a payment handler that does not support collection of user identity (e.g., for privacy reasons or others), then if you go to a new device, it might not work because the identity might not work if based on device characteristics

Tomasz: The SRC can verify the given identity (e.g., email address). So if the payment handler collects email from the consumer, the PH may use identity services from SRC to verify that, and would ultimately receive the SRC provided JWT token

IJ: What spoofing prevention is there?

Jalepsh: Could be, e.g., email sent to user or another challenge
... up to implementation of payment handler. Suppose handler is email provider; the handler can present email + token back to the SRC system.

Jonathan: Suggest diagrams for:

- First time user on device A

- Returning user on deviceA

- Returning user on new device

- Returning user on different device AND different payment handler

Dean: Need to describe whether the identification part is a payment handler feature or an SRC feature.

Tomasz: I agree with Jalpesh that these are implementation specific details both for payment handlers and for SRC systems.

deanezra: It may be implementation-specific, but I think it's important from a payment handler perspective to know who has to implement what.

AdrianHB: If we don't think about what payment handlers are going to do and what data they will need, we may not have the Payment Handler API that we need
... e.g., hints on who the user is

<scribe> ACTION: Jalpesh to document the payment handler to SRC systems for various possibilities

<trackbot> Created ACTION-126 - Document the payment handler to src systems for various possibilities [on Jalpesh Chitalia - due 2019-08-14].

Jonathan: You mentioned Credential Management API last time


<scribe> ACTION: Ian to re-ping Mike West about explaining the Credential Management API during TPAC

<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).

Tomasz: Could be helpful to have credential management API as a complement to any merchant-provided hints

[We continue with second flow diagram, step 8]

Jonathan: Step 8 is cardholder auth at transaction item.
... merchant preferences and issuer risk evaluation and regulation will determine whether step-up required
... and we could add here that FIDO auth could be used as input to 3DS auth
... A clarification that would be useful is that you could have 3DS without a step-up
... we should not hard-link 3ds to step-up

Jalpesh: Shouldn't this step just talk about POTENTIAL step-up?

IJ: I suggest that we have a box that says "Risk assessment (optional)" and within that "Step-up (optional)"

Jonathan: You can have a decision to use 3DS rails and you may or may not do step-up at that point

Jalpesh: choice of using 3DS depends on multiple criteria

IJ: Maybe talk about risk assessment after 7...then move all the step-up details inside the optional box

Jonathan: We also need to clarify who is doing the risk assessment...issuer or src system?

Next call

Ian: Regrets for me on 21 August

Next call will still be 21 August, and Visa and Mastercard will work out who hosts.


IJ: Demos would be great!

Summary of Action Items

[NEW] ACTION: Ian to re-ping Mike West about explaining the Credential Management API during TPAC
[NEW] ACTION: Jalpesh to document the payment handler to SRC systems for various possibilities
[NEW] ACTION: Jonathan to work with Tomasz on a new flow diagram showing the 3DS authentication in more detail

Summary of Resolutions

[End of minutes]

Minutes manually created (not a transcript), formatted by David Booth's scribe.perl version 1.154 (CVS log)
$Date: 2019/08/07 17:11:36 $