EMV® Secure Remote Commerce v0.95 Disposition of Comments
Secure Remote Commerce Draft Specification v0.95 – Disposition of Comments Document Clause / Subclause/ Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Proposed change Status Accept, Reject, In progress, Acknowledge EMVCo observations on each comment submitted Spec 0.95 8.1.4 Spec 0.95 8.5.3 Spec 9.2 0.95 Spec 9.3 0.95 Spec 9.3 0.95 Spec 9.3 0.95 Spec 9.4 0.95 Req 031 ge Req 158 ge Table ge 9.2.3 Table 9.3.1 Table 9.3.1 Table 9.3.3 ge ge teMINOR Table 9.4.2 teMINOR It is not clear how the SRC System can ensure the uniqueness of DPA. It seems that the SRC must trust in SRC-I when it informs that the DPA is new. The spec defines that the SRC-I defines the method of for data collection. To the information to be trusted, it is important to indicate how the spec will ensure the assurance of the information. For example, for 3DS there is a certified SDK and the ACS 3DS Method that is controlled by the issuer. It is no clear the possible DCF Handover Method Consumer Identity Type does not include natural Identy Type, such as National Ids, Passports and Driver Licenses Identity Validation Channel just contain email and SMS options The spec informed that Device Identifier is a value created by an SRC Participant to uniquely identify a device. It is Inconsistent to be Manufacturer-specific. The value status list for PAN Status does not contain a value to identify a "good" PAN. Include information on how the SRC System can ensure the the uniqueness of DPA in the onboarding. Make clear how to ensure trust to the information. Clarify the possible domain Consider to include a more comprehensive domain list Include all possible channels to be supported by the specification Consider the revision or clarification. Complement the list or clarify how to register that kind of information Acknowledge Acknowledge Accept Reject Reject Accept Accept The DPA itself is not unique rather the identifier of the DPA should be unique. The SRC Specification does not provide requirements on testing or certification. Testing and certification is the responsibility of the SRC Programme. Testing and Certification are under consideration for incremental revisions. Changes have been added to this section to indicate the SRC API and SRC SDK specifications provide the methodology for DCF handover. This identity type is used for consumers to self-identify with an SRC System. The specified channels are examples in the specification and may be expanded with future versions. The specification has been updated to remove the restriction in the valid values. The specification has been updated to include a value to represent "good" when describing a PAN. Document Clause/ Subclause/ Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Spec 9.9 0.95 Table ge 9.9.1 The Card Verification Method does not consider the 3DS NPA as possibility of verification method. Spec 0.95 11.11.2 - ge How to be inter-operable without defining a message protocol and format? Spec 0.95 Spec 0.95 Spec 0.95 Spec 0.95 11.11.4 2nd Bullet 11.11.4 3rd Bullet General General Revision
Log TeMAJOR TeMAJOR ge Ed All Conditional data elements for the data message received must be present when the conditions for presence are met as defined in Section 11 Request and Response Messages. But the spec doesn’t mention the conditions. Required, Conditional, and Optional data elements contained in the message must meet formatting and length criteria as specified in Section 9 SRC Data Dictionary. The SRC Data Dictionary does not mention formatting and length criteria. This version has removed UI/UX directive.The document mention it in some parts, but there isn´t a Clause to clarify UI/UX. It is very time consuming to review the new version of the specification and see what has changed. Proposed change Consider this possibility. Consider justify how the SRC System will inter-operate without using a single message protocol and format. For all conditional information consider to describe the conditionality. Complement the Data Dictionary with formatting and length criteria Consider to include it or an specific document to define the general UI/UX directives. Please, finally start a comprehensive revision log listing all (!) changes in the spec from the last version so that we can concentrate on the relevant parts. Status Accept, Reject, In Progress, Acknowledge EMVCo observations on each comment submitted Acknowledge Accept Accept As the industry develops solutions for 3DS NPA the SRCWG will continue to monitor for future revisions to the specification. This section of the specification has been updated to with references to the API and SDK which is the protocol and format. This section of the specification has been updated to with references to the API and SDK which describes the conditions for data elements. Accept This section of the specification has been updated to with references to the API and SDK which describes the format and length of data elements. Accept The 0.9 annex for UI Guidelines will be extracted and included as a separate document similar to the API and SDK. Acknowledge The publication of 1.0 will be the initial version of the SRC Specifications. Revisions to 1.0 will include revision logs. 1 BA/TA/Dual/Sub = Dual Associate, or Business Associate or Technical Associate, or Subscriber company (enter a 2-4 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. 10/22/2018
of 7 Document Clause/ Subclause/ Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Proposed change Spec 0.95 Spec 0.95 4.2.1.1 8.3 Table Ed 4.1 Req 086 Te Spec 9.1 0.95 Spec 9.1 0.95 Table Ed 9.1.3 Table Te 9.1.3 Spec 9.1 0.95 Spec 91 0.95 Spec 9.2 0.95 Table ed 9.1.4 Table Te 9.1.4 Table Te 9.2.3 2 typos under use case "No Delivery": "exchanged" & "completed" – both times ‘d’ missing; Req 086 seems to suggest that a SW provider has to deliver SRCI SW in all possible permutations of the SRC Systems. E.g. one for just Visa, one for just MC, one for Visa & MC, one for just Amex, one for Visa & Amex, and so on. At "DCF TSP", first word should be "Identifies" Under "DCF TSP", EMVCo seems to suggest that EMVCo will give out TSP identity numbers; How is this supposed to work? Do TSPs in the future have to get certified by EMVCo? Are there only 1,000 TSPs worldwide? At "DPA 3DS Preference"; Typo in "Notes": ‘processes’ (plural) "DPA 3DS Preference" seems to suggest that this preference can be overridden at run time; so far, we understood that this is a one-time configuration element; "DPA Call Back URI": under ‘Condition’ it says "Provided by DPA"; we believe the chain should be that the DPA should provide a URI to the SRCI, and the SRCI should provide a URI to the DCF; Please, make this flexible enough so that the combinations can be enabled thru configuration only. Please clarify Please clarify Please elaborate Status Accept, Reject, In Progress, Acknowledge EMVCo observations on each comment submitted Accept Errata has been corrected. Accept The language has been updated with the removal of the work "only" which removes the restrictions. Accept Errata has been corrected. Acknowledge EMVCo has an existing TSP registration programme which enables the assignment of TSP Code to each TSP. Accept Reject Reject Errata has been corrected. The preference established in onboarding and registration can be overridden as a result of transactions events. The specification highlights the origination of the information with the subsequent dissemination left to each of the SRC Participants. 1 BA/TA/Dual/Sub = Dual Associate, or Business Associate or Technical Associate, or Subscriber company (enter a 2-4 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. 10/22/2018
of 7 Document Clause/ Subclause/ Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Proposed change Status Accept, Reject, In Progress, Acknowledge EMVCo observations on each comment submitted Spec 9.3 0.95 Spec 0.95 Spec 0.95 Spec 0.95 SDK 0.95 SDK 0.95 9.9 9.9. 11 2.6.2 2.7. Table Te 9.3.1 Table Te 9.9.2 Table Te 9.9.2 Ed Table Te 2.12 Table Te 2.14 API 2.1 0.95 Table Te 2.21 API Versioni Ed 0.95 ng "Identity validation channel": valid values for Email and SMS are not enough; identity validation must be able to use the full range of available methods. All "Age" fields: use a number field for number of days. "Shipping Address Usage (New)" and "Age of Shipping Address Usage" are redundant; Masked validation channels; email/sms insufficient (see comment above) OOB validation channels seem not to be supported by this All "Age" fields: use a number field for number of days. Also, here ‘Age’ is of type ‘String’, whereas in the spec it is of type ‘Number’ In New Orleans, the relevance of API versioning was addressed:API versioning is important; how would the coexistence of Please change Please don’t use a number field for number of days, but use a proper UTC date time stamp. Dissolve redundancy by dropping "Age of …" "SRC DSA Identifier" should be replaced by "SRC DPA Identifier" in various tables (4x) Please change Please expand Please don’t use a number field for number of days, but use a proper UTC date time stamp. While technically, keeping the version in the API URL is definitely the right thing to do, it would still be Accept Accept Accept Accept Accept Acknowledge Acknowledge Acknowledge The SRC Specification has been updated to indicate additional values may be added in future revisions. Specific format values have been removed from the age data fields. The SRC Specification has been updated to remove the duplicate data element. Errata has been corrected. The SRC Specification has been updated to indicate additional values may be added in future revisions. EMVCo acknowledges that not all possible OOB validation channels are listed, further revisions of the specification may cover more OOB validation channels. The field is an age field and it is defined in number of days. It is not intended to be used as a time stamp, therefore it is outlined in a number field. The specification provides various fields in UTC format. The API specification will keep the version number of the APIs, the SRCWG will handle potential 1 BA/TA/Dual/Sub = Dual Associate, or Business Associate or Technical Associate, or Subscriber company (enter a 2-4 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. 10/22/2018
of 7 Document Clause/ Subclause/ Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Proposed change Status Accept, Reject, In Progress, Acknowledge EMVCo observations on each comment submitted Spec 0.95 Spec 0.95 various versions of the API be handled; this great if the version life cycle would backwards compatibility issues in next is already getting difficult in 3DS where v2.1 be clarified, including the handling revisions of the specifications. is out and the market is already calling for of how/when are new versions 2.2. which is only going to be ready by end introduced, mandated etc. and also of 2019 or so which combinations of versions will work together (compatibility etc.) Te Is it planned to add the auth method used in Acknowledge The request is on the roadmap for the 3DS challenge flow to the 3DS 2.0 revisions of the SRC Specifications. protocol? (more a question for the 3DS working group) And, is it planned to add this information to the federated identity data that is exchanged with the SRC Systems? (e.g. if 3DS NPA was used to authenticate a customer identity before displaying the candidate list) Te Slide 51 of the PDF at New Orleans Acknowledge Merchant-initiated Transaction are not mentions the MIT; today, this is one of the out of scope for Secure Remote use cases for CoF or ToF and outside the Commerce. The current revision of the scope of SRC; is it planned to add this use specification introduces Merchant case to SRC as well, meaning that rather Initiated Transaction in section 2.7.2. than storing a card or token on file, a The current specification does not merchant uses a customer identity to get the provide the details on the uses cases digital card from a SRC System?##If so, this as the specification focuses on would probably not work if more than one Consumer Initiated checkout. Further card is returned – how to handle details and potential extensions on this?##Merchant tokens (e.g. M4M) are token handling for this particular use bound to a specific merchant whereas SRC case may be further discussed with the tokens don’t carry this information. Would Tokenisation Working Group may get this be a problem? Wouldn't it make sense introduced in later revisions of EMV to have SRC be able to create merchant specifications. specific tokens for them to use a ToF? 1 BA/TA/Dual/Sub = Dual Associate, or Business Associate or Technical Associate, or Subscriber company (enter a 2-4 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. 10/22/2018
of 7 Document Clause/ Subclause/ Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Proposed change Status Accept, Reject, In Progress, Acknowledge EMVCo observations on each comment submitted Spec 0.95 Spec 0.95 Spec 0.95 Spec 0.95 Ch. 4.3.4.1 1st paragra ph Te Ch. 1st 4.4.3 bullet Te Ch. 5th 4.4.3 bullet Te Ch. 5th 4.4.3 bullet Te "The SRC System creates a unique identifier for each unique Digital Shopping Application." This chapter "creates a unique identifier", and the referred chapter 5.2 (Registration) uses "unique reference identifier". "unique reference identifier" should be used consistently "Identifies its BIN and or BIN ranges eligible to participate in SRC" Does this participation refer to one or more SRC Programmes, or is it in general BIN ranges assigned to SRC transactions? "each PAN enabled for participation in SRC" Does this participation refer to one or more SRC Programmes, or is it in general PANs assigned to SRC transactions? "SRCPI can elect to send PAN data in Enrolment Request to add a PAN to the SRC System and may elect to send PAN Reference Data for Enrolment Request to Delete or Update established content" In previous sections, "add, Delete, Clarity Clarity Clarity Either write all characters un uppercase; or replace "add" by "Add" Replace "PAN Reference Data" by "PAN reference data" Accept Errata has been corrected. Acknowledge The SRCPI will identify which of its existing BIN ranges will be eligible for SRC transactions upon onboarding with each applicable SRC System. Acknowledge The SRCPI will identify which of its existing PAN are eligible for SRC transactions upon cardholder enrolment. Accept Errata has been corrected. 1 BA/TA/Dual/Sub = Dual Associate, or Business Associate or Technical Associate, or Subscriber company (enter a 2-4 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. 10/22/2018
of 7 Document Clause/ Subclause/ Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) Spec Ch. Req 0.95 8.1.2 024 Ed Update" has been written as "ADD, DELETE, UPDATE" Consistency of the text Chapter 2.3 introduces Cardholderinitiated transactions, and not Consumer-initiated transactions Proposed change Status Accept, Reject, In Progress, Acknowledge EMVCo observations on each comment submitted Replace "Consumer-initiated" by "Cardholder-initiated" Accept Errata has been corrected. 1 BA/TA/Dual/Sub = Dual Associate, or Business Associate or Technical Associate, or Subscriber company (enter a 2-4 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. 10/22/2018
of 7