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

Draft Specification & Bulletin Industry Feedback Form Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification v2.3.1.1 – Draft Date: May 2023 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 A.13.8 Table A.17 ed EA 3.5 Req 449 ed EA A.9 Table A.4 ed The table does not yet reflect that Transaction Status value ‘D’ is now also valid for the final CRes message. Please update the columns ‘Final CRes’ and ‘Error Response’ for the row related to Transaction Status ‘D’. Accept The last item in the bullet list belongs to the second last item? This is most likely caused by using the full text above Table A.28 as the reference instead of only the table number. Error Code 313 (Inconsistent RReq message) has been updated to mention Transaction Status ‘S’. I fail to see in the specification how Transaction Status ‘S’ in the ARes message could result in a RReq message? In case of a 3DS Requestor initiated SPC authentication (see Section 3.5), the first ARes message contains Transaction Status ‘S’, but no RReq message is sent. The second ARes message could contain Transaction Status ‘C’ resulting in a RReq message, but that means that the ARes message contained Transaction Status ‘C’ and not ‘S’. Merge the second last and last bullet item resulting in • SPC Transaction Data (See Table A.28). Please clarify and if needed update the descriptions related to Error Code 313 to remove Transaction Status value ‘S’. Accept Reject Transaction Status = D is valid in Final CRes only if 3DS Requestor Decoupled Request Indicator = F or B within the AReq message. This appears to be a PDF conversion issue. Not present in the Word document. In case of timeout for an SPC transaction (second AReq never received), the ACS will return an RReq to indicate the timeout [Req 452]. Therefore, it is possible that the ACS sends an RReq for a Transaction Status = S in the corresponding ARes message. 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. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Draft Specification & Bulletin Industry Feedback Form Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification v2.3.1.1 – Draft Date: May 2023 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 A.4 Table A.1 te For a SPC authentication initiated by the ACS, the first (and only) ARes message contains Transaction Status ‘C’ and once the challenge (using SPC as authentication method) has been completed a RReq message will be sent, but again the ARes message did not contain Transaction Status ‘S’ in this case. The presence conditions for oobAppLabel and oobAppURL depend on each other and are not that easy to understand (in my opinion). The way I understand it is: • if the ACS wants to use the OOB Authentication App automatic switching feature for the current transaction, the ACS has to provide the oobAppURL (otherwise the 3DS SDK does not know how to open the OOB Authentication App), so therefore the oobAppLabel is required when oobAppURL is present and OOB App URL Indicator was 01 in the CReq message (presence of oobAppURL for other values of OOB App URL Indicator may not Can you confirm that my interpretation of the presence conditions for ACS UI Type ‘04’ is correct? Can you also confirm that my observation for ACS UI Type ‘06’ is valid? Should the wording of Requirement 407 be updated to include the scenario of a missing oobAppURL data element? Accept For ACS UI Type = 04, the logic is as follows: - If the OOB App Label is present, then the OOB App URL shall be present. - No other check expected from the 3DS SDK, as it is an ACS decision whether or not automatic switching should be used. Clarification on the presence of the OOB App Label and OOB App URL: OOB App Label: Only present for ACS UI Type = 04 if: 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. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Draft Specification & Bulletin Industry Feedback Form Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification v2.3.1.1 – Draft Date: May 2023 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 make too much sense logically, but the specification does not prohibit the ACS to include it either), and as a result • oobAppURL has to be present for ACS UI Type ‘04’ if oobAppLabel is present. • So, for ACS UI Type ‘04’ the 3DS SDK should be able to detect any missing elements. However, for ACS UI Type ‘06’ the 3DS SDK can only detect whether oobAppURL is required by either parsing the received acsHTML to see whether there is a button triggering the HTTPS://EMV3DS/openoobApp URL (which seems to be a bit too much to me) or by the time the relevant HTML element is clicked/tapped by the user and therefore the 3DS SDK receives the GET request at HTTPS://EMV3DS/openoobApp: - OOB App URL Indicator = 01 in the CReq message AND - the ACS uses the OOB Authentication App automatic switching feature for this transaction. OOB App URL: Only present if [ ACS UI Type = 04 if the OOB App Label is present] For ACS UI Type = 06, the 3DS SDK does not need to verify the ACS HTML code and the presence of HTTPS://EMV3DS/openoobApp, this is complex and does not guarantee that the code is valid. In case, the oobAppURL is not present, [Req 407] applies: The 3DS SDK will return a CReq with OOB App Status = 01 (Open OOB App URL failed) and OOB Continuation Indicator = 02 (Automatic complete) 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. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Draft Specification & Bulletin Industry Feedback Form Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification v2.3.1.1 – Draft Date: May 2023 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 N/A A.4 Table te A.1 If the oobAppURL was not present, the 3DS SDK cannot perform the actions mentioned in Requirement 405. By that time, it would be a bit too late to send an Erro message with Error Code ‘201’ indicating the missing oobAppURL as the challenge UI (i.e. acsHTML) has already been shown to the cardholder, isn’t it? Does requirement 407 apply in that case? MAJOR - challengeSelectInfo key is to be changed to a maximum length of 4 characters. This would imply a complete overhaul of all items and variables in existing products: the key is an important internal value that addresses a lot of data, hence requiring more digits. Allow key length of 45 digits to match the challengeDataEntry maximum length Reject In case of a Multi-Select challenge, it is possible to have 8 entries in the response (worst-case scenario). The challengeDataEntry is not long enough to carry 8 keys in the response (45 characters long). Therefore, the choice was to limit the length of the challengeSelectInfo key to 4 characters. The extra characters are needed for the syntax used to format the response. 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. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Draft Specification & Bulletin Industry Feedback Form Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification v2.3.1.1 – Draft Date: May 2023 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA N/A EA N/A A.13.3 ge Table A.12 A.21 Table te A.28 Electronic ID is added as a 3DS Requestor Authentication Method, but the specification does not provide any information regarding the use of this value MINOR - spcTransData.currency is changed to be defined over 3 alphanumeric characters, but other currency values in the specific do not prevent from using numeric values. What is the reason behind the difference? Provide additional guidance for the use of Electronic ID Align all currencies’ format throughout specification. EA N/A Req 220 te MINOR - Opinion for timeout change: 30 N/A N/A seconds is OK from our ACS stand point Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept The Electronic ID use case will be explained in a forthcoming 3DS White Paper. In progress In progress Purchase Currency as originally defined in the 3DS specification uses numeric ISO 4217 three-digit currency encoding. SPC managed by w3c uses ISO 4217 three-character alphabetic currency encoding. At this stage of deployment, it is not possible to align the two specifications. Thank you for the feedback. 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. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Draft Specification & Bulletin Industry Feedback Form Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification v2.3.1.1 – Draft Date: May 2023 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA 3.2.1 Req 472 te Check that the OOB App URL uses the HTTPS scheme What should happen if this validation is not successful? Should the 3DS SDK still try to open the OOB App? 3DS Requestor App URL which is also a universal app link does not have this requirement. Add the same requirement for the 3DS Requestor App URL, or remove it for OOB App URL. Additionally specify clearly what should happen if the validation is not met. EA Req 119 ed Rephrase the sentence, list the processing steps sequentially. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Clarification to [Req 472] The 3DS SDK shall - Check that the OOB App URL uses the HTTPS scheme. - If not, the 3DS SDK returns an error as defined in Section 5.9.7: Accept New requirement for the ACS: The ACS shall verify that 3DS Requestor App URL uses the HTTPS scheme (CReq message validation), - if not, the ACS returns an error as defined in Section 5.9.5: [Req 119] updated to list the requirements 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. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries. Draft Specification & Bulletin Industry Feedback Form Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification v2.3.1.1 – Draft Date: May 2023 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Req 461 te [Req 464] and [Req 461] represent the Add the check for the 3DS Requestor same requirement but for different flow. Decoupled Request Indicator for the app The requirement for checking the “3DS flow as well [req 461] Requestor Decoupled Request Indicator” is missing for [req 461] but written in [req 464] Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Condition missing in [Req 464] [Req 464] If the ACS determines that Decoupled Authentication Fallback is necessary and 3DS Requestor Decoupled Request Indicator = F or B, inform … 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. © 2023 EMVCo, LLC. All rights reserved. Reproduction, distribution and other use of this document is permitted only pursuant to the applicable agreement between the user and EMVCo found at www.emvco.com. EMV® is a registered trademark or trademark of EMVCo, LLC in the United States and other countries.