IJ: Now we want to fill in blanks
between flows and tokenization/3DS
... What is status of conversation about EMVCo using FIDO data
as input to 3DS?
Jalpesh: We can call out where risk analysis can be done
Jalpesh: WebAuthn can be
input
... step 7 of transaction can include cardholder verification
information
... can also include 3DS data input
IJ: what about in enrollment
Brian: First question was - FIDO
dataset as part of EMVCo; that's a work in progress.
... regarding SRC...3DS can be input to SRC
Jalpesh: Regarding transaction
step 7...you are correct...3DS input can also include
cardholder verification (which might include Web Authn)
... but in general, that information can be used without
3DS.
IJ: SRC CheckoutRequest, carries cardholder verification information (e.g., 3DS or other)
Jonathan: +1
Jalpesh: +1
IJ: SRC CheckoutResponse, carries token info and optional verification results
Jalpesh: Add add an optional step-up flow that looks like the enrollment step-up flow after 8 and before 9
Brian: In the scenario with step-up...would that be part of the SRC response?
Jalpesh: Step 8 response data would include a step-up instructions
Jonathan: That's when SRC is
doing risk analysis, but the risk analysis could be done by the
merchant.
... three options from a merchant perspective:
- No 3DS
- merchant will do 3DS
- SRC will do 3DS
Jalpesh: Maybe we need to remove the part about 3DS and just talk about SRC transactions
Jonathan: As soon as we put some
content on the different flows, I'd like to have 3DS data
mentioned somewhere, and we understand the data is going from
one flow to the other
... I don't think we should separate the 3DS part
... it's fine if it's optional
IJ: +1 to a note to clarify different ways to do 3DS.
Jalpesh: We will want merchant to
be able to say (1) want 3DS ... and step 7 includes 3DS data
(2) no 3DS ... and step 7 does not include 3DS data and (3)
merchant handles 3DS
... Let's call it "assurance data" in steps 7 and 8 (that's the
SRC term)
... It also seems to me that what happens between DCF and SRC
is less important to detail; that's covered by SRC
protocols
IJ: We still need to know what flags to support as request
Jonathan: 3DS data may go through the system without, for example, FIDO authentication.
IJ: I am hearing "don't put all the things in an SRC spec"
Jalpesh: 3DS has merchant provided data. SRC will perform risk analysis regardless of merchant request. SRC system needs to support assurance data regardless of whether risk analysis is performed on that transaction.
IJ: Feels to me like SRC spec would have an "assurance slot" for various assurance data blobs
https://github.com/w3c/webpayments/wiki/Authentication
https://github.com/w3c/webpayments/wiki/3DSDataSources
Data about the merchant / transaction
scribe: that would be request data to a 3DS assurance module
Jalpesh: So that makes sense .... if merchant requests 3DS, step 1 has to support that data
https://w3c.github.io/3ds/index.html
Jalpesh: Tokenization and definliely 3DS will have distinct objects that go all the way from 1 to 7
BrianPiel: It's part of merchant request (in 1)
Jalpesh: we can simplify diagram
to clean up 1, 2, 7, 8 to have no 3DS
... and create a second copy where the flow is labeled
"Merchant requests 3DS" and we add the bits to those flow
arrows.
https://w3c.github.io/webpayments-methods-tokenization/index.html
IJ: I don't understand the dependencies fully between tokenization and 3DS; so don't know if the objects are entirely distinct.
Jonathan: I don't see high value
in 2 diagrams; I think we can just say "3DS can go here
optionally"
... we can have separate discussion about 3 flavors of 3DS
Jalpesh: then I'm ok to call 3dS Optional in step 1 and conditional in steps 6 and 7
<scribe> ACTION: Ian will update the diagrams to capture more clearly 3DS data in steps 1, 6, and 7
<trackbot> 'Ian' is an ambiguous username. Please try a different identifier, such as family name or username (e.g., IFSF-EFT-WG-Lead, ijacobs).
Jalpesh: 3DS would be optional in step 1. In step 6 3DS explicitly mentioned as well. In step 7 can have abstraction of "assurance data" (where 3DS is one option)
Jonathan: +1
BrianPiel: I think that assurance data is optional according to SRC
(IJ: I will label assurance data as optional)
IJ: Should we also call out in 1 the token preference?
Jalpesh: I don't think that's as relevant from SRC perspective
https://w3c.github.io/webpayments-methods-tokenization/index.html
IJ: Should we pull the ECI out of the token spec?
Jalpesh: I think it's card processing data, which applies to 3DS and non-3DS transactions
IJ: What should we do by then?
- SRC spec draft?
- Prototyping?
Jalpesh: I'd like to help
IJ: I'd suggest we start with URL-based payment method to get started. I will reach out to Jalpesh after the call.
Jalpesh: One question I have on
the spec
... Adrian opened an issue on the flow altogether
https://github.com/w3c/src/issues/1
[We will take up AHB's issue then]
Proposed 13 Feb instead of 20 Feb
IJ: Any objections?
RESOLUTION: Next call is 13 February and no call on 20 February