Draft spec => https://w3c.github.io/3ds/index.html
https://w3c.github.io/3ds/index.html#threedsrequestlevel-enum
IJ: What does the Cardinal doc say about how we should organize the response data?
Adam: Just note that that is
specific to Cardinal; that can be different from raw 3DS 2.0
protocol.
... but I find the page the most useful thing I've seen re:
3DS2.0
... and what data is exchagned
... I note that this is probably targeting a PSP or very large
merchant
... there are 14 cases shown but I don't think we need to
expose all of them
... I think there are 3 or 4 responses:
1) Success; here is the cryptogram and ECI
2) There was a timeout or failure that is not your fault; therefore you should fall back on authorizing the charge normally but you won't have a 3DS cryptogram to go with it since 3DS failed for some reason.
3) Things worked but the cardholder failed for some reason, or the data you sent us was invalid. In this case the merchant MUST NOT try to authorized the card for some reason.
scribe: I think those are the
three main cases
... there is a bunch of data that could plausibly go with that
(e.g., error numbers or error description strings)
... the page is useful for also covering what cases payment
handlers will need to address.
Jonathan regarding this => enum ThreeDSRequestLevel { "required", "frictionless-only", "challenge-only", "none" };
scribe: the merchant will want to
indicate a full flow, a "frictionless-only" flow, ...but I am
not sure why we have four of them.
... I don't think the merchant will request a challenge-only
flow.
... I don't think there will be a use case where the merchant
will say "challenge-only"
... and can understand "none" as well
IJ: any others want to weigh in
on "challenge-only" flow?
... Note diff between user preference ("I the user don't want
frictionless") and merchant preference
stpeter: From a privacy
standpoint, I can see a use case where I the user have
registered a preference with a merchant.
... but I don't know whether merchants are going to
differentiate based on privacy. But I wouldn't forestall the
possibility of having this.
asolove: As 3DS2 is written, the "challenge-only" flow does not exist; there is always a frictionless first.
Ian: Is it possible in 3DS2 today to say "don't do the challenge-flow" ?
asolove: They are 2 separate API calls, so the merchant can choose not to do the challenge-flow
MikeH: There is a field in the 3DS spec that corresponds to the challenge preference of the merchant.
see the "3DS Requestor Challenge Indicator"; values may evolve over time
<asolove> +1
IJ: Should we align with that
value in 3DS?
... +1
MikeH: +1
<scribe> ACTION: Ian to edit the spec to reflect the 3DS Requestor Challenge Indicator prefs
IJ: I also plan to continue think about Adam's issue and perhaps pester him to work on the response data. I am still thinking about how the use cases listed above (success, failure due to system, failure due to user) relate to our merchant preference flag.
<stpeter> jonathan: could browsers provide the 3DS SDK data?
<stpeter> stpeter: we'd need to check on what data could be accessed via the browser
<stpeter> asolove: the native SDK accesses way more data than could be gathered via JavaScript
<stpeter> asolove: we had a discussion in Singapore about potentially providing some kind of stable fingerprint ID
<stpeter> jonathan: would be helpful to do the analysis
<stpeter> stpeter: +1
<asolove> +1
<stpeter> jonathan: this would enable us to decide on a common subset
<stpeter> jonathan: this would also enable the browsers to provide a better user experience
stpeter: There will be some form of user consent; user understanding of consent prompts is tricky
[Gap analysis between SDK and browser-based]
stpeter: +1 to gap analysis
https://github.com/w3c/webpayments/wiki/UserConfidenceScore
IJ: Two Api ideas
- Get data API
- Get user confidence score API
Jonathan: The second one does not exist today in 3DS; might still be useful regarding risk analysis
IJ: Goal is to get on the same page and have good discussion at TPAC about web authn, data gathering API, and confidence score
Jonathan: Any FIDO people going to be there?
Ian: Adam Powers, WebAuthN people. Let me know if you think others should join us.
26 September
scribe: look for a 1-time WebEx for that meeting