<scribe> Scribe: Ian
https://github.com/w3c/3ds/issues/8
asolove: I reviewed the spec and
compared to our internal implementation and documentation from
our provider
... asked what cases, data, are missing from this spec
https://w3c.github.io/3ds/index.html
scribe: one thing I note is
a) Is 3ds required or not
b) If 3ds is required, is a challenge required?
scribe: they are not the same
thing
... we either need more values or two flags with the necessary
values
... what happens in the sheet (e.g., address) might change the
merchant preference on the fly for "required" v. "optional" v.
"don't do 3ds"
... the spec talks about data that the merchant needs to
provide
... or that the payment handler needs to gather from the
user
... 3DS requires shipping address if for physical goods. ... so
we may need to pass the shipping address to the payment
handler, or the payment handler may need to show UI to the
user
... in short the 3DS spec may not speak to this data directly
but will need to require that it be available
... e.g., email and some phone number
IJ: We may need to discuss this
around payment-handler...requests for browser-stored
data.
... that topic has come up previously
asolove: Moving on...payee data
will depend on existing relationships
... there's 3ds data and may be extra network-specific
data
... here are things that the merchant is likely to provide:
order number, merchant id, acquirer id, acquirer merchant id,
merchant name,
opt in to encrypted or tokenized card number
scribe: 'merchant id' is the
network's id for the merchant; their acquirer may have a
different id for the merchant (also to be included)
... the spec also allows the merchant to opt-in to encrypting
the PAN in the response or getting a tokenized card
... some of these may be optional in 3DS for payment
handlers
IJ: We have a transaction id through PR API; likely different from order id
stpeter: It seems to me that
there might be other data of interest
... e.g., item data
asolove: I only went through and
looked at the "absolutely required for 3DS2"
... but there's a long list of optional data.
... it may not be worth enumerating yet
jonathan: I will send data I gathered that is necessary for merchant identification
[Returning to use cases]
asolove: One case - merchant
wants to do 3DS and if they do it, they want the issuing bank
to do a challenge
... e.g., for high-value transaction
Another case - merchant says "If the bank is willing to do 3DS, that's fine, but no step-up"
Another case - merchant needs to do 3DS and don't want challenge flow
scribe: those cases lead to some observations about response data as well
Cases:
===
(See Cardinal's 3DS2 result test cases)
if we add a requestLevel=never3DS, then returned data shape is different
is the shape of returned data then specified by the host payment method?
if there's an error during 3ds, or ACS is unavailable or times out
if 3ds required, handler should prompt for another form of payment
if 3ds not required, handler maybe falls back to returnign card/token without performing 3ds.
there are lots of case intersections, for example:
if 3ds is required but merchant specifies frictionless, what do we do if frictionless denied?
give up and ask for another payment method from the customer?
try 3ds again and allow a challenge?
===
asolove: It might be interesting
for payment handlers to handle some of these cases in a
standard fashion, and to enable merchant to configure
behavior.
... so if the merchant says "I never want 3DS" then the
response data will not be there
... if there is an error or timeout, then we have some more
cases
... if 3DS is required but there's error, there are questions
about whether the error should be exposed to the merchant, or
whether the payment handler should retry() before going back to
the merchant
... or if there is an error and 3DS is not required, then
perhaps the payment handler should be able to try another
card
... if we split our options into "is 3DS required?" and "is
challenge required?"
IJ: My gut response is that the merchant should regain control
asolove: It's possible for PR API to fail due to lack of match, or from the user canceling, but this is the first example where the payment sheet can fail partway through the transaction based on a third party response. Should the handler own the error and offer a retry? Or should the handler return data to the merchant?
jonathan: What are failure modes specifically? E.g., OTP password error?
asolove: That's one case,
although in that case the customer probably understands.
... I am more interested in cases like ACS times out or is
unavailable, so something that is invisible to the user
... 3DS protocol fails behind the scenes before the user sees
something from the issuer.
IJ: What happens today between, say, merchant and Stripe when these things happen?
asolove: See the Cardinal
docs....there are dependencies on network or others
... e.g., in some failures, the merchant is prohibited from
doing anything with card data after failure and must request a
new payment method.
... there are some use cases where there are partial
successes...
... or some cases that are much rarer such as ACS
time-out
... and a few others that are not exactly a failure
... in these cases it's up to the PSP or merchant whether they
can use the card data "without 3ds" and use the card data to
authorize payment
IJ: Do we need more response data ?
asolove: We could add two more flags to let the merchant know what case they are dealing with
<scribe> ACTION: asolove to mention in his post flags we could add to response data to give merchant more information about what their options are after some edge cases of partial success or failure
asolove: the section on privacy
and data gathering is important
... the big question is what will browsers implement, what will
payment handlers do, and how to comply with the 3DS spec via
method_url custom fingerprinting mechanism that browsers could
provide
... the method_url is the fingerprinting script that the
issuing bank runs in the merchant page
IJ: 23 October "auth" discussion
at TPAC
... I am meeting with Adam Powers today to discuss TPAC
agenda
jonathan: I think we need to
agree on use cases we want to cover
... need a session on leveraging device info from web
authn
... need a session on tokenization
... there are a few tracks
<scribe> ACTION: Jonathan to write up a proposal for how to organize TPAC discussion around 3ds, tokenization, authentication
asolove: Do we have anyone who
has customer relations in the payment space who is interested
in the webauthn space?
... some issuing banks?
... I'd love to work with a bank or klarna
IJ: At TPAC - bank of America,
barclays, capital one, klarna, worldpay
... should I make an introduction?
asolove: Yes, let's take to email
5 September