EMV® 3-D Secure Protocol and Core Functions Specification v2.3 DRAFT 3 – Disposition of Comments

2021-03-01T00:00:00+00:00 v1.0 Draft Specification

Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV 3-D Secure Protocol and Core Functions Specification DRAFT 3 Date: February 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Req 419 Section 3.1 te What happens if the 3DS Server chooses Updated version will fix the issue a protocol version lower than the one selected by the 3DS SDK (during createTransaction processing) and the outcome of the authentication request is Transaction Status ‘C’? How does the 3DS SDK know the correct messageVersion value to be used in the subsequent CReq message? As far as I can tell, the 3DS SDK specification does not provide an API to the 3DS Requestor (App) to pass the message version from the ARes message to the 3DS SDK. EA Req 394 Section 3.1 te How does the DS determine if the SDK Clarification ‘according to DS rules’ Type is valid for the transaction? Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Update will be included in the final version of the specification. Accept Update will be included in the final version of the specification. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: http://www.emvco.com/subscriber/QueryAdd.aspx to submit feedback. 26-Feb-2021

of 13 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV 3-D Secure Protocol and Core Functions Specification DRAFT 3 Date: February 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Section 3.2 te First note after step 17 mentions that the Delete the note 3DS Requestor should adjust the 3DS SDK’s challenge time-out if the ACS indicates to use OOB. sdkMaxTimeout has already been provided in the AReq message. Isn’t this in contradiction with each other? EA Req 82 Section 3.3 ed First line contains duplicated ‘, ‘ in ‘ACS Remove duplicated ‘, ‘ part. Protocol Versions,, DS Protocol Versions and’ EA Req 422 Section 3.3 ed Requirement mentions 3DS SDK which is Remove 3DS SDK from Req 422. not applicable to the 02-BRW device channel discussed in this section. EA Req 423 Section 3.4 ed Requirement mentions 3DS SDK which is Remove 3DS SDK from Req 423. not applicable to the 03-3RI device channel discussed in this section. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Update will be included in the final version of the specification. Accept Accept Accept Update will be included in the final version of the specification. Update will be included in the final version of the specification. Update will be included in the final version of the specification. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: http://www.emvco.com/subscriber/QueryAdd.aspx to submit feedback. 26-Feb-2021

of 13 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV 3-D Secure Protocol and Core Functions Specification DRAFT 3 Date: February 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA Req 291 Section 3.4 ed/te Requirement contains "authentication not Remove quoted sentence if Transaction Reject / The 3DSWG Rejects the first requested by the 3DS Server for data sent Status ‘I’ is indeed not applicable to 03-3RI. Accept proposed change to remove for informational purposes only (Transaction Status = I)". According to discussions I had with the WG/TG last year in May, Transaction Status ‘I’ is not applicable to 03-3RI and therefore this part should be removed. If Transaction Status ‘I’ is applicable to 033RI, I would suggest to convert the sentence into a proper bullet point such that it becomes part of the listing for the other Transaction Status values in this requirement. support of Trans Status = I for transaction type 03–3RI And Accepts the second proposal to support Trans Status = I with 03– 3RI. Note: this should probably also be corrected in the 2.2.0 specification! 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: http://www.emvco.com/subscriber/QueryAdd.aspx to submit feedback. 26-Feb-2021

of 13 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV 3-D Secure Protocol and Core Functions Specification DRAFT 3 Date: February 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Req 354 Section 3.4 te EA Section ed 4.2.1.1 EA Req 153 Section ed 4.2.4.1 The note after Requirement 354 mentions what the 3DS Server should do if no RReq message is received for a Decoupled Authentication. However, this scenario should never occur based on Requirement 353. Has this note become obsolete? Same question applies to the corresponding requirements in section 3.1 (for 01-APP) and section 3.3 (for 02BRW). Text below Figure 4.9 contains ‘Error! Reference source not found.’ Text of Requirement 153 contains an unresolved reference (‘Error! Reference source not found.’). Remove note if no longer applicable or clarify the situation in which this scenario could occur? Correct the reference. Correct the reference. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Reject This covers the case the 3DS Server never received the RReq due to technical problems. Note is a recommendation, not a Req. Accept Accept Update will be included in the final version of the specification. Update will be included in the final version of the specification. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: http://www.emvco.com/subscriber/QueryAdd.aspx to submit feedback. 26-Feb-2021

of 13 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV 3-D Secure Protocol and Core Functions Specification DRAFT 3 Date: February 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) EA Req 229 Section te 5.5.2.1 How is the 3DS Server suppossed to deliver the Erro message to the DS if the connection could not be established to deliver the AReq message (which is the cause of the Erro message to be sent)? If the DS is not accepting incoming connections because of too much traffic/load, attempting to establish another new connection to deliver the Erro message is not going to help to reduce the load on the DS and hence may make the issues the DS is experiencing even worse. A similar remark applies to Req. 424 and 243. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Reject No change It is optional for the 3DS Server The handling of error message on the DS may be a separate function, and could work, also usually DS have a backup server. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: http://www.emvco.com/subscriber/QueryAdd.aspx to submit feedback. 26-Feb-2021

of 13 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV 3-D Secure Protocol and Core Functions Specification DRAFT 3 Date: February 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA Req 426 Section 5.6 te EA Section ed 5.9.8.1 It looks like that a DS will always receive the Accept-Encoding header from a 2.3.0 3DS Server implementation (according Req. 425). Is the intention of Req 426 such that the DS always returns the compressed response body and only in case the 3DS Server does not behave according Req 425 the uncompressed body is returned (in line with the Note below Requirement 426), or does the DS have the option to send either compressed or uncompressed data irrespective of the presence/absence of the Accept-Encoding header? First bullet point lacks reference for a 3RIbased transaction. Correct Accept DS has the option to respond with either compressed or uncompressed data irrespective of the presence/absence of the Accept-Encoding header Clarification of the requirement, in case the PReq header does not include gzip, the DS does not return an error Add 3RI related requirement corresponding to the requirements 22 (01-APP) and 99 (02BRW). Accept Updated Req 426. Update will be included in the final version of the specification. The equivalent of Req 22 is missing in the 3RI flow, 3DS Server URL is used during a decoupled transaction. Update will be included in the final version of the specification. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: http://www.emvco.com/subscriber/QueryAdd.aspx to submit feedback. 26-Feb-2021

of 13 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV 3-D Secure Protocol and Core Functions Specification DRAFT 3 Date: February 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Section ed In all 4 places throughout this section Add 3RI related requirement corresponding 5.9.10 where requirements 63 and 125 are to requirement 63 (01-APP) and 125 (02- referenced, the corresponding BRW). requirement for 3RI-based transactions is missing. EA Section 5.9 ed/te A section ‘ACS RRes Message Error Add section 5.9.13 ACS RRes Message Handling – 03-3RI’ similar to 5.9.11 and Error Handling – 03-3RI. 5.9.12 is missing in section 5.9. EA Section ed Third sentence in this section contains Replace shown by known. 6.2.2.3 "signed by a DS CA whose public key is shown". Should shown be replaced by known? EA Annex A.4 Table A.1 te The field name of the new data element App IP Address is ‘appIp’ where the ‘p’ in IP is in lowercase. The corresponding Browser IP Address data element’s field name is ‘browserIP’ with uppercase ‘P’ in IP. Change the App IP Address field name to ‘appIP’ to use consistent uppercase usage compared to ‘browserIP’. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Same as above, review 3RI flow for decoupled. Update will be included in the final version of the specification. Accept Accept New section for 3RI. Update will be included in the final version of the specification. Update will be included in the final version of the specification. Reject The WG decision is to keep appIp and consistency in the naming for the new data elements. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: http://www.emvco.com/subscriber/QueryAdd.aspx to submit feedback. 26-Feb-2021

of 13 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV 3-D Secure Protocol and Core Functions Specification DRAFT 3 Date: February 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Annex A.4 Table A.1 ed EA Annex A.4 Table A.1 te EA Annex A.4 Table A.1 ed Description of Challenge Data Entry Keyboard Type mentions ‘the ACS shall display’. However, the ACS is the source of the data element and does not display anything at all. How are challengeDataEntryLengthMax and challengeDataEntryLenghtMin used? These data elements are only mentioned in Table A.1 and B.4, but nowhere else in the specification (at least not in the Protocol and Core Functions specification). Entry for challengeDataEntryLenghtMin contains ‘Challenge Data Entry Length Maximum’. Correct ACS to 3DS SDK: ‘Indicates if the 3DS SDK shall display a numeric or alphanumeric keyboard’. Correct to ‘Challenge Data Entry Length Minimum’. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Update will be included in the final version of the specification. Accept Min length has been deleted. Clarification will be included in the final version of the specification. Accept Update will be included in the final version of the specification. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: http://www.emvco.com/subscriber/QueryAdd.aspx to submit feedback. 26-Feb-2021

of 13 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV 3-D Secure Protocol and Core Functions Specification DRAFT 3 Date: February 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA Annex A.5.5 Table A.4 te EA Annex A.5.7 Table A.6 ed Table A.4 lists the new Error Code value ‘309’. In which scenarios is this new value being used? The Protocol and Core Functions specification does not mention it anywhere. The current table does not reflect the actual structure of the entries in the Card Range Data data element. Refer to the Split-SDK specification - req 25 To clarify the structure of the elements in the Card Range Data data element it may be worthwhile to mention in the description column of threeDSMethodURL, acsInfoInd, and version that these subfields are included in the acsProtocolVersions array. Reject Accept The Split SDK server will return this error when problem in the CRes content, Req 25 of the Split SDK specification. Update will be included in the final version of the specification. EA Annex A.5.7 Table A.6 ed Field names for End and Start are not correct, or the example JSON provided below the table is incorrect. Similar for the end and start subfields it may be mentioned that these are present in the ranges array. Either correct field names to ‘start’ and ‘end’ (instead of ‘startRange’ and ‘endRange’), or correct the JSON example. Accept Update will be included in the final version of the specification. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: http://www.emvco.com/subscriber/QueryAdd.aspx to submit feedback. 26-Feb-2021

of 13 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: EMV 3-D Secure Protocol and Core Functions Specification DRAFT 3 Date: February 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Annex A.7.5 Table A.12 te EA Annex A.7.6 Table A.13 te EA Annex A.7.6 te EA Annex A.7.8 Footnote 12 te EA Annex ed A.7.11 Is the presence of the three subfields in ACS Rendering Type mandatory for all three subfields? Is the presence of the three subfields in Device Rendering Options mandatory for all three subfields? Does the note above Table A.13 apply to the SDK Authentication Types? If so, value ‘12’ is missing in the example provided below table A.13. Does the addition of ‘(or as specified by DS rules)’ allow the usage of Transaction Status value ‘I’ in combination with the 033RI Device Channel? The text above table A.18 refers to Table A.1. Should this have been referring to Table A.18? Additional column to specify the inclusion Additional column to specify the inclusion Correct the example by adding value ‘12’ in the sdkAuthenticationType subfield. Correct the table reference. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Update will be included in the final version of the specification. Accept Update will be included in the final version of the specification. Accept Update will be included in the final version of the specification. Accept 3DSWG wants to support Trans Status = I with 3RI. Accept Update will be included in the final version of the specification. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: http://www.emvco.com/subscriber/QueryAdd.aspx to submit feedback. 26-Feb-2021

of 13