<scribe> Scribe: Ian
https://www.w3.org/2019/07/24-wpwg-minutes.html
[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]
Jalpesh:
* 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
https://www.w3.org/TR/2019/WD-credential-management-1-20190117/
<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?
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!