PCI Watch

Tracking changes across the Payment Card Industry

EMV® 3-D Secure Protocol and Core Functions Specification DRAFT 4 and 5 Disposition of Comments

v1.0 Draft Specification
3-D Secure

Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 DRAFT 4 FEEDBACK: Annex A A4 te opDescription is freeform which will lead to Introduce structured subfields to In The 3DSWG prefers to get uncertainty of interpretation and will hinder complement opCategory, e,g. opDetail / Info progress operational feedback on the response automation to OReq messages. / SubCategory or whatever name. Operational messages before Some proposed use cases could benefit defining sub-categories. from more detail being communicated, e.g. with opCategory 03 TLS Certificate For example for certificate expiry warnings, Expiry, how to identify which certificate is opCategory 03 could have opDetail 01 to expiring? indicate what opDescription contains, e.g. opDetail 01 certCN, opDetail 02 certSerial, opDetail03 certHash could allow the DS to precisely specify which certificate is expiring (DS’s own, ACS’s own etc.). It may also be useful to have different opDetail codes for CA vs. leaf certificates to help alert for changes in root CA migrations in future. Annex A A4 te OReq could communicate DS availability Consider a new opCategory, eg. In The 3DSWG prefers to get and probe for availability of other serviceStatus 07 DS Availability Status with progress operational feedback on the components. This may be useful to help 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 Annex A A4 Annex A A4 manage cyber attacks and provide an out of band way for the DS to probe for 3DSS and ACS availability instead of depending on discovering availability during transaction processing, resulting in timeouts, failures, and retries. opDetail 03 DS Unavailability announcement opDetail 04 DS Availability announcement. Consider a new opCategory 08 for status probe with opDetail 05 ACS availability check, opDetail 06 3DSS availability check. ed Clarify opCategory 03 applies to TLS certificate vs. LOA/AOC certificates. Reword the definition. Accept te OReq extensions to communicate Introduce new opCategory 08 for Reject forthcoming changes affecting AV forthcoming AV key change, using calculations, e.g. key rotations, algorithm opExpDate to communicate the date. version retirement etc. Lack of co- opCategory 09 for algorithm version ordination of AV implementations has the changes with supporting opDetail 07 and 08 potential to significantly disrupt to sub-define whether the algorithm or the downstream authorization processing. version is changing (use a sequence of messages if it’s both) with opDescription Operational messages before defining a new opCategory. The values were updated to clarify. 03 = Public Key Certificate expiry 04 = Letter Of Approval/Attestation Of Compliance expiry An AV key or algorithm change is too complex to handle with the OReq message. The Payment Systems may already have processes in place. 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 Annex A A4 General te ed opSeverity thresholds are undefined which may lead to differences in implementation between schemes. containing the new algorithm name or version as appropriate. By way of example, with regard to TLS certificate expiry, consider opSeverity 04 at 60 days to expiry, opSeverity 03 at 30 days, etc. Accept Potential confusion with Device Binding: ACS, and some 3DSS, implementations, use the association and recognition of a previously-used device as part of fraud scoring. It is imperative that this process is not undermined by Device Binding. For example users should not be able to "opt out" of this data point as part of risk assessment. Clarify in the specification that Device "Binding" means enrolling the device as an authentication element, and this is a distinct process to using the 3DS Method data and SDK Device Data for recognising patterns of device use by a cardholder when scoring fraud. Accept The OpSeverity should be read with the Operation Expiration Date that provides the time information. It is difficult to standardise in the short term, without implementation and feedback form the industry. A definition of Device Binding was added in Table 1.3, and the data element description is updated. 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 Annex A A4 ed in deviceBindingDataEntry it will be more Edit the wording to clarify that Accept This is an ACS choice; the powerful if Device Binding is associated deviceBindingDataEntry binds the device to specification does not stop an ACS with the Cardholder and not just the PAN. the cardholder or the PAN. to bind to the Cardholder. E.g. if the cardholder has multiple cards with the bank one Device Binding could smooth the authentication flow across cards. Some ACSes may associate discrete PANs with a single cardholder. The description of deviceBindingDataEntry is updated to the following: Indicator provided by the 3DS SDK to the ACS to confirm whether the Cardholder gives consent to bind the device. Annex A A4 te Multiple Challenge Entry UI elements Redefine challengeEntryBox as an array of Reject The 3DSWG may consider should be defined as an array to allow for objects from table A.25 and discard the improving the challenge UI in a future expansion. Not that more challenge challengeEntryBoxTwo element, e.g.: future version of the specification. elements to enter is a desirable user experience, however in future it may be that a challenge data entry input is { "challengeEntryBox": [{ obtained passively (e.g. biometric). Must "challengeDataIndex": 0, also consider UI templates and "challengeDataEntryKeyboardType": "01", predictability of those templates. "challengeDataEntryAutofill": "Y", 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 "challengeDataEntryAutofillType": "01", "challengeDataEntryLengthMax": "6", "challengeDataEntryLabel": "Enter OTP:", "challengeDataEntryMasking": "Y", "challengeDataEntryToggle": "N" }, { "challengeDataIndex": 1, "challengeDataEntryKeyboardType": "02", "challengeDataEntryAutofill": "N", "challengeDataEntryLengthMax": "30", "challengeDataEntryLabel": "Enter shared secret:", "challengeDataEntryMasking": "Y", "challengeDataEntryToggle": "N" }]} 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 Similarly delete the definition of challengeDataEntryTwo and redefine challengeDataEntry to be an array. Define a new challengeDataEntryLimit field and associated upper values, i.e. a display limit, which may change over time, for the size of the challengeEntryBox array, i.e. an upper limit on the number of displayable challenge entry fields on one screen. For 2.3.0 set this limit to two. If the spec ever needs more then that version can support a higher limit. There does not necessarily need to be the same limit on the challengeDataEntry array because certain challenge data may be gathered silently in future, e.g. biometric. 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 Annex A A4 ed Take the opportunity to strengthen the wording to reinforce the importance of including the appID field and taking care to make sure it is an accurate external IP. Accept Annex A Table A,1 Annex A.4 Table A.1 Annex A.4 Table A.1 te Te MAJOR Te MINOR Field recurringCurrency, column "Conditional Inclusion", 2nd bullet has "Required for 01-PA for 03-3RI". It is not clear if it is for both 01-PA and 03-3RI or if this is a typo. It would be interesting to know from which DS the ACS receives an OReq message. Either "for 01-PA and 03-3RI" or just "for 03RI" Make the field ‘dsReferenceNumber’ required for OReq messages. The field ‘threeDSRequestorChallengeInd’ is already not always really used, as DS can provide their challenge wish in other ways, such as message extensions or Don’t allow two ‘threeDSRequestorChallengeInd’. Accept Accept Reject SDKAppID is required for App flow. The AReq will stop at the DS if not provided. The 3DS FAQs will be updated to highlight the importance for the 3DS Requestor and 3DS Server to provide reliable data. The final 2.3 specification has enhanced the recurring data elements, and their conditional inclusion. The dsReferenceNumber is added to the OReq message. The 3DS Requestor may need more than 1 value. For example, ask at the same time for trust list and device binding (03 +09). 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Annex A.4 Table A.1 ge ‘messageCategory’ field, so the possibility to give two values is just a technical constraint for ACS with no real value for DS. What is ‘cardSecurityCode’ ? Is it CVX ? If yes isn’t it dangerous to have the CVX along with the PAN? Anyway this value can’t come from the ACS as stated in the field ‘cardSecurityCodeSource’. ‘cardSecurityCodeSource’ field can’t have the ACS as source. Annex A.4 Table A.1 ge Field ‘transChallengeExemption’ has strange possible values. Use the values in numerical order. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Reject Card Security Code Status was missing in draft 4 and justifies the ACS as a source of the ‘cardSecurityCodeSource’. This data element is included in the final version of the specification. The 3DSWG is collaborating with PCI to ensure the proper controls are in place for the card security code. The values of the transChallengeExemption are in sync with 3DS Requestor Challenge Indicator. 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 A clarification was added to the ‘transChallengeExemption’ data element.

3.3 Browserbased Requireme nts [Req 442] Te MAJOR With no limitation on the number of restarts on authentication in case of multiple CReq messages, we could have cases of brute-force attack/fraud. Add a limitation on the number of restarts allowed. Reject In Req 442, the ACS has the option to respond with an error message, so it may decide not to restart the challenge, also the 3DS Requestor will time out if the challenge takes too long.

5.1.7 Message Content Validation [Req 434] 5.5.2.2 RReq/RRe s Message Timeouts [Req 242] Te MINOR ge It is a huge technical constraint to open ‘DS used’ fields one by one, that is why it is more convenient to open the range as soon as a one of the value is used by one DS. The DS impose ACS some KPIs especially concerning timings and timeouts, so it seems odd to give them the ability to set their own timeout values. Moreover, the handling for different Remove the ‘DS use’ clause of this requirement on error handling. Don’t allow the DS to set their own timeouts. In progress Reject The 3DSWG has reviewed the question and it is not possible to delete or ignore the DS-used value. Suggestions on the management of these values would be appreciated. The DS has to perform optional processing such as attempts, so it is necessary for the DS to adjust the timeout values accordingly. 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 schemes will be a huge technical constraint. Req 390 te The Split-SDK specification seems to Add missing SDK Type(s) to Req 390, 5.9.5, Accept The following updates were made to imply that the SDK Server Signed Content 6.2.4.1, Table A.1 - SDK Server Signed the specification: is also included in the AReq message for SDK Type ‘04’ (Browser-SDK). Shouldn’t Requirement 390 also mention SDK Type ‘04’? Content Browser SDK and Shell SDK types are added to: Req 390, 5.9.5 - If SDK Type = 02 or 03 (missing 04 and 05), 6.2.4.1 - For SDK Type = 02 or 03: A128GCM (missing 04 and 05), Table A.1 - SDK Server Signed Content: condition - Required if SDK Type = 02 or 03. missing 04 and 05. Chapter 4 ed Chapter 4 contains a couple ‘Error! Reference source not found.’ Ensure all hyperlinks within the document are correct and functional. Accept Updated. Annex A.4 Table A.1 ed Example value provided for threeDSRequestorAppURL seems to be Correct the example value. Accept Updated. 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 incomplete as the value ‘https://appname.com?’ contains a question mark, but no query parameters. Annex A.4 Table A.1 te Are only URLs using ‘https’ as scheme allowed for threeDSRequestorAppURL or can a 3DS Requestor also use App specific URL schemes, e.g. merchantApp://open?transactionId=…? Add clarification that only https is accepted for Universal App Link (refer to Android and iOS) Accept The definition of the Universal App Link requires the use of https. A note is added to the related data element to clarifie this requirement. Annex A.4 Table A.1 te There are 3DS Requestor Challenge Indicator values to request Trust List Prompt (‘09’) or Device Binding Prompt (‘12’) if a challenge is required, but not both. Is this a valid use case (as some of the UI templates in chapter 4 seem to suggest) and if so, shouldn’t there be a corresponding 3DS Requestor Challenge Indicator value? Accept The 3DS Requestor Challenge Indicator is defined as an array (max 2 elements). Annex A.4 Table A.1 te Shouldn’t challengeDataEntryKeyboardType be Delete challengeDataEntryKeyboardType from Table A.1 Accept challengeDataEntryKeyboardType is removed from Table A.1. 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Annex A.4 Table A.1 ed Annex te A.12 Annex ed A.13.6 removed as separate data element as it is now part of challengeEntryBox and challengeEntryBoxTwo? Table A.1 contains a couple ‘Error! Reference source not found.’ Annex A.12 still mentions a total maximum of 81920 characters, however that does not sum up with the change to 15 extensions and the element length defined in Table A.8. Note, that the messageExtension data element will be larger than 81920 characters anyways as the field names take a bit of space too. The example for deviceRenderOptions below table A.14 lacks value ‘06’ in the sdkUiType subfield. Ensure all hyperlinks within the document are correct and functional. Correct the maximum length mentioned in Annex A.12. Add value ‘06’. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Reject Accept Updated. A review of the existing message extension showed that the message extension data will be at the maximum length of 4k. The maximum number of message extensions is increased to 15 for a total length of 80k, whichever limit comes first. The value ‘06’ is added to the deviceRenderOptions example. 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 Annex B.4 Table B.4 ed Table B.4 lists challengeEntryBox2 while the data element is defined in Annex A.4 as challengeEntryBoxTwo. Synchronize the data element identifiers. Accept Updated. Core [Req 195] ge Any Message Version Number not indicated as active in Table 1.5 Draft Specification Bulletin 255 shall be returned as an error. The 3-D Secure component shall return an Error Message with the applicable Error Component and an Error Code = 102. —> how to maintain the reference to the bulletin? Will we always refer to the SpecVersConfig doc as SB255, even for future updates? Accept The Specification Bulletin 255 lists the active Message Version Number, that the 3DS components that return error 102 if they receive a message with a non active Message Version Number (Req 195). The 3DS components will always use the latest update of Specification Bulletin 255 available on the EMVCo web site. Core [Req 311] ge 3DS components shall support all lesser active protocol versions limited to major.minor versions. 3DS components shall support latest patch for their current version. 3-D Secure messages containing Accept Req 311 is updated. 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) an active Message Version Number supported by the 3-D Secure component shall be processed according to the requirements of the specified protocol version (See Draft Specification Bulletin 255 Table 1.5). —> what does "supporting all lesser active protocol versions" mean? Core Note: ge Protocol and Message Version Numbers are in the format: major.minor.patch (for example, 2.3.0). —> so what is the 4th component in the new versioning "2.3.0.0"? What are the repercussions in terms of messageVersion for the transaction? (The Message Version Number is set by the 3DS Server which originates the protocol with the AReq message. The Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept The 4th digit is used for editorial updates of the specification. Refer to the 3DS version management document. The Message Version Number is coded as major.minor.patch.. An example is added to the Message Version Number to illustrate the coding xx.yy.zz in Table A.1. 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Core [Req 434] Core [Req 227] Message Version Number does not change during a 3DS transaction.) If the value of a data element is in the range of "Reserved for DS use" and not recognised, or in the range of "Reserved for EMVCo future use", all 3DS components shall return an Error Message (as defined in Section A.5.5) with the applicable Error Component and Error Code = 207. —> Why the need to differentiate from 203? If the timeout expires before Cardholder authentication can complete, send an RReq message within 60 seconds to the DS to be passed to the 3DS Server with the Transaction Status = N and Transaction Status Reason = 14. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept This error code was added to help in the error investigation, as 203 was covering too many error cases. Accept The 3DSWG agrees, the same requirement applies to both browser and app flows. Requirement 224 is updated with the same 60 second time limit. 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Core/DSB [Req 256] ed Core/DSB [Req 442] Te/ed Core [Req 437] te —> Is the addition of "within 60 seconds" not applicable to [Req 224]? The 3DS Requestor shall" [Req 256] —> " typo in DSB, should be: Start a timer against the 3DS Method to AReq Max Time. —> I couldn’t find this is the Draft4 document, but it’s in the DSB227v4 [Req 442] was something else in the Draft4 doc. OReq/ORes Upon the second failure to complete the TCP/IP connection and TLS handshake to the recipient, end the transaction, and periodically retry within the 24-hour Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Updated. Accept There is no new timer for the 3DS method in the 3DS specification v2.3. The draft timer requirement is deleted. Accept This 60-second value is in line with similar requirements for the other messages (AReq, PRes …). 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. 22-Sep-2021

of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Core Oreq/ores te window at 60- second intervals until the transaction completes successfully. —> Isn’t retrying this at 60-second intervals too often? Or is the information expected to be the same priority as the PReq/PRes exchange? Is OReq/ORes only supported at messageVersion = 2.3.0? What is the expected usage of the messageExtension field in OReq/ORes? Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept All the 3DS messages contain the message extension for future use. Core Oreq/ores te ACS Transaction ID and 3DS Server Transaction ID being required in ORes —> won’t they be conditional depending on whether it is the ACS or the 3DSS responding to the DS? Accept The presence condition in the specification is updated to: Required in ORes Message for an ACS/3DS Server receiving an OReq message. Core Oreq/ORe te s opStatus

  • 02 = Failed to receive messages Accept Clarifications are made to the OpStatus data element values. 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 Core Cardholde r Informatio n Text —> When is this sent? (Wondering how the 3DSS/ACS will be able to respond if it failed to receive the message… Or is this related to receiving messages out of sequence?)
  • 03 = Successfully received message, but action not supported —> What is a sample use-case for this if OReq is mostly informational? Cardholder Information Text —> issuerImage / paymentSystemImage —> Should the secure link requirement for SDK issuerImage/psImage handling also apply? See: "If the CRes message for a Native UI contains a URL(s) directing the 3DS SDK to fetch data from an external server (i.e., an Issuer Image or Payment System Image for use with a Native UI), establish Accept The link is defined as Fully Qualified URL that uses the https scheme by definition. 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 an additional secure link to the external server as defined in Section 6.1.4.1 and fetch and display the received data within the UI. If a secure link cannot be established, the 3DS SDK proceeds with the challenge displays all other provided mandatory and optional UI data elements and does not send an error message to the ACS. " Core Cardholde r Informatio n Text Te/ed A.20 Cardholder Information Text —> should "[Req 356] If the Cardholder Information Text has been provided by the ACS for this transaction the 3DS Server shall ensure the Cardholder Information Text is displayed on the 3DS Requestor website. " be updated to refer to the A.20 recommended layout? Accept Requirements 355 and 356 were updated. And "[Req 355] If the Cardholder Information Text has been provided by the ACS for this transaction the 3DS 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Core challenge te Cancel shall ensure the Cardholder Information Text is displayed on the 3DS Requestor App. " —> BTW, how does the 3DS Server ensure that this is displayed? Shouldn’t it be a 3DS Requestor requirement? challengeCancel:
  • 09 = Error message in response to a CRes sent by the ACS
  • 10 = Error in the CReq message —> when are these applicable? What were the values being returned before these new codes were introduced? Ah, found the challengeErrorReporting field. challengeCancel = 08 also involved SDK sending ACS an Erro message. Should challengeErrorReporting field also be Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept A clarification is made in the description for value 10. 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 included then or the new 09/10 codes are limited to CReq/CRes validation errors? Core challenge te NoEntry Question on challengeNoEntry, should this only be included if both challengeDataEntry and challengeDataEntryTwo are not included? What happens if the user only fills up one of the fields? Accept A clarification is made in the description: UI is replaced by entry box/UI. Challenge data has been entered in the entry box/UI. —> ah, found this: For ACS UI Type = 01, the Challenge Data Entry is considered as missing in the table when both the Challenge Data Entry (challengeDataEntry) and the optional Challenge Data Entry 2 (challengeDataEntryTwo) are missing. challengeDataEntryTwo: Conditional inclusion specifies - Challenge data has been entered in the UI, AND —> should we clarify that the challenge data was entered into the 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 Core Core Core Core Table A.1 ed ed A.14 UI te Data Elements second input or the above is clear enough? challengeDataEntryKeyboardType —> still in Table A.1 but should only be in Table A.25? challengeDataEntryLengthMax —> "Set to default to 45 if not present. " —> "Set to default 45 if not present"? challengeDataEntryLabel —> "Label to modify the Challenge Data Entry field provided by the ACS. " —> description is not so clear. What is being modified? - N = Not present —> What is the expected behavior on the SDK for this? Should the SDK report an Error if it is still present in the CRes? Or just ignore, but don’t display it? Accept Accept challengeDataEntryKeyboardType is removed from Table A.1. Updated. Accept challengeDataEntryLabel is updated. Accept The 3DS SDK ignores any additional UI data elements as per requirement 362: If the 3DS SDK receives an unsupported UI data element(s) for this ACS UI Type, the 3DS SDK does not display the UI 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Core Core Core ed challengeInfoLabel Text provided to the Cardholder by the ACS/Issuer to specify the challenge. —> Unclear description. ed transChallengeExemption —> No "09" but not part of
  • 01–04, 06, 07, 13–79 = Reserved for EMVCo future use (values invalid until defined by EMVCo) te 102 | Message Version Number Not Supported | Message Version Number received is not valid for the receiving component. Error in the Card Range Data. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept data elements, proceeds with the challenge and does not send an error message to the ACS. The challengeInfoLabel description is updated. Accept The value 09 is added to the Reserved for EMVCo future use for the transChallengeExemption. Accept The error 102 only applies to the Message Version Number The error description is updated to: One of the following: 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Core Core Message Version Number provided for a Payment Token is not supported by the actual PAN when de-tokenised. —> Recommending having "One of the following: " like Error 101 (previous row) —> What Error in the Card Range Data will require Error Code 102 to be returned? Is this only applicable to the Version fields within the card range data? te sdkAuthenticationType: 12 = Out of Scope —> What is a sample of an Out of Scope type? te Table A.26 Broadcast Information Recipient(s) Field Name: recipients —>
  • 01=3DSSDK Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Message Version Number received is not valid for the receiving component. Error in the Message Version Number in the Card Range Data. Message Version Number provided for a Payment Token is not supported by the actual PAN when de-tokenised. The value 12 = Out of scope is removed from the specification. Accept 3DS SDK is removed from the possible recipient. 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 How will the SDK Receive this if it is in the AReq/ARes messages? Core Core ed Table te A.18: Table A.20: Issuer Image —> Includeat minimum one —> "Include at.." Table A.18: Seller Information Merchant-assigned Seller identifier. Note: If this data element is present, this must match the Seller ID field in the Seller Information object. —> Referring to itself? I think this was cutand-paste from Table A.17: MultiTransaction Additional question on multi-transaction: a). what is the point of having avNumberUse parameter? Isn't AV is a single time per txn authentication value? if so, how is the AV reused? Accept Typo correction. Accept Seller Information lists the possible sellers/merchants. The Mutli-Transaction object includes all the Seller ID involved in the transaction. a) avNumberUse parameter is conditional based on DS rules b) It is possible that some merchants are not listed, so the amount may not match up. Also, for a multi-currency transaction, the amount may not match due to exchanges rate differences. 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Core b). Secondly, in a multi transaction scenario, will merchantAmount(1)+merchantAmount(2)...(n) = purchaseAmount ( incase purchaseCurrency=merchantCurrency(for all 1 to n)) te Need to clarify, if all the xxCountryCode(merchant, acquirer, shipping, billing) parameters will only follow, ISO 3166 as per the spec (3 char String), or will it also accept ISO-3166-2 (2 char String). As per latest directive received from VISA based on doc (Visa.Secure.August.2021.Release.Notes. 1.0.pdf) it is a mandatory requirement for all 3DS servers and ACS endpoints to adhere to the edition of the ISO 3166-2 for countryCode value utilized by Visa DS Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted In progress Liaise with the Payment System for clarification. 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Core te Regarding the format change for browserIP and appIp from Draft 3 and Draft 4: [Draft 3]
  • IPv4 address is represented in the dotted decimal format of 4 sets of decimal numbers separated by dots. The decimal number in each and every set is in the range 0 to 255. Refer to RFC 791.
  • IPv6 address is represented as eight groups of four hexadecimal digits, each group representing 16 bits (two octets. The groups are separated by colons (:). Refer to RFC 4291. [Draft 4]
  • IPv4 address. Refer to RFC 791.
  • IPv6 address is represented as. Refer to RFC 4291. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept In line with the RFC 4291, different IPv6 formats are accepted. Please also refer to the EMV<sup>®</sup> 3-D Secure Specifications Frequently Asked Questions (FAQs) – question 30. 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 Core Does that mean other IPv6 formats are accepted? 0:0:0:0:0:0:13.1.68.3 0:0:0:0:0:FFFF:129.144.52.38 or in compressed form:::13.1.68.3::FFFF:129.144.52.38 Additionally, this was also included in the latest FAQ doc (EMV_3DS_SpecificationFAQs_20211703.pdf): 28. How should the App IP Address and Browser IP Address data elements be encoded in versions 2.1.0 and 2.2.0 of the 3-D Secure core specification? (NEW) The App IP Address and Browser IP Address data elements are encoded as string. Accept This is intended to be a clarification as 3DS Servers are sending compressed IPv6 format. 3DS components should implement the RFCs and support compressed formats for IPv6. 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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
  • Refer to the RFC 791 for the representation of the IPv4 address (https://tools.ietf.org/html/rfc791).
  • Refer to the RFC 4291 for the representation of the IPv6 address (https://tools.ietf.org/html/rfc4291), in which Section 2.2 defines the different representation options. So do the components have to backwards-apply support for the other IPv6 formats? DRAFT 5 FEEDBACK: Annex A.4 Table A.1 ed Typo in Condition Inclusion column for new threeDSRequestorSpcSupport data element: Correct to Required if Accept Updated. Required is supported by the 3DS Requestor supported by the 3DS Requestor 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 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 Annex A.4 Table A.1 ed The Condition Inclusion column for the Recurring Amount mentions in the second bullet point: Purchase Amount Recurring Indicator = 01 However, the specification does not define a ‘Purchase Amount Recurring Indicator’ data element. Correct the inclusion condition to refer to the ‘Recurring Indicator’ data element instead. Accept The final specification 2.3 has enhanced the recurring data elements, and their conditional inclusion. Annex A.4 Table A.1 te I cannot comment on the presence conditions for the recurring payment data elements from a practical use case point of view. However, from a testing and message validation point of view, I applaud the presence conditions currently defined in Table A.1 as they allow for strict presence validation based on the received AReq message content. The alternative conditions mentioned above Table A.1, Keep the current strict conditions. Accept The final specification 2.3 has enhanced the recurring data elements, and their conditional inclusion. For some data elements the presence conditions depend on the context of the transaction. 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. 22-Sep-2021 of 31 Draft Specification & Bulletin Industry Feedback Form Company Name: Primary Contact Name: Working Group or Task Force: 3-D Secure Working Group Document: 3-D Secure Protocol and Core Functions Specification Drafts 4 and 5 Date: September 2021 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Section 3.5 Note at top ed of e.g. ‘Required when there is a fixed frequency’ on the other hand, are (at least from a technical point of view) to vague (although they might be perfectly understandable from a business rule point of view) and therefore would be difficult to implement as part of message validation logic. The note contains two undefined references which makes it a bit difficult to understand how the DS is supposed to return the mentioned parameters to the ACS and 3DS Server. The same applies to step 10e (above requirement 444) and the note following requirement 444, as well as steps 10f, 10g, and 10i. Correct the references. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Accept Updated. 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. 22-Sep-2021 of 31