EMV® Secure Remote Commerce v.0.9 Disposition of Comments

Secure Remote Commerce Draft Specification v0.9 – Disposition of Comments SUBMITT ER 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 Nick TelfordReed 2.5.1 Nick TelfordReed 2.5.1 Nick TelfordReed Nick TelfordReed 2.5.1 2.5.1 Para Ed Ge Te MAJOR Te MAJOR Compare "Date of Card Last Used is the date that the Digital Card was last used in SRC System where Date of Card Last Used is governed by inclusion of the Digital Card in a Checkout Response or Payload Response to any SRC Initiator by that SRC System resulting from a Cardholder-Initiated Transaction " with "Date of Card Last Used is presented as date and time in UTC when a Cardholder-Initiated Transaction occurred and was populated in a Payload Response". Does this mean that the data and time is not presented in UTC if the digital card was populated in a Checkout response? Card last used – what is the behaviour when the underlying Card has been used in multiple SRC systems? Same could be said about enrolment date Multiple SRC systems multiplied by multiple consumer identities suggest that the SRC candidate lists might be very complex Display order – no opportunity for consumers to set the ordering themselves. Surely the consumer can set the order just like they can order cards in their physical wallet? / Improve wording of first bullet, and clarify format if populated in checkout response Text seems to assume one SRC system only (in practice) Consider mechanism for filtering/hiding set by consumer (and see below) Introduce mechanism for consumer- defined ordering in the candidate list Accept Acknowledge Acknowledge Reject This section has been revised for the next draft of the specification to provide more clarity. A checkout response may also include a payload response. The date of card last used is based on the Digital Card of the underlying PAN. This section has been revised for the next draft of the specification to provide more clarity. Section 3 for 1.0 draft describes the recommendations for management of the candidate list. No existing mechanism is identified to establish a single source of consumer preferences. However, Section 3 provides recommendation for the candidate list. SUBMITT ER 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 Nick 3.2 Telford- Reed Para Ge Nick 3.2.1 Para Gen Telford- Reed Nick 3.3.1 Para Gen Telford- Reed Nick 3.3.4 Para Gen Telford- Reed Payment authentication via a 3DS server – can authentication not occur in any other way? Does SRC require 3DS authentication The requirement for each SRC initiator to register each DSA with each SRC system feels hugely onerous – could existing identifiers not be re-used instead (for example, some combination of ARN/BIN/IIN/MID or similar) "When the SRC trigger is a button…" implies an SRC branding requirement – is this the case? If so, how will that also be consistently applied to other triggers including gestures, voice commands etc Who maintains a registry /directory of SRC systems? Given the requirement to register with each one, there needs to be a central Add text to show optionality Consider process simplified registration Remove Acknowledge Acknowledge Accept Reject EMVCo SRC specification describes assurance and in Section 2.8 this is not intended to be Authentication nor should be interpreted as Authentication. Authentication in the context of the broader EMVCo documents is associated with EMV 3DS and it is possible for the interaction of SRC and 3DS. As for any requirements associated with the support of 3DS, this consideration is outside the remit of EMVCo, and is defined uniquely by implementation. Payment Authorisation via an Acquirer Alternative payment authentication schemes may be used as well. The Registration Process is defined by the SRC Programme which is outside the scope of the SRC Specification, however in future releases it may be possible to define a common message which may consider existing assigned values. This text has been removed. The SRC specification does not require unique identifiers for SRC Programmes. 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 36 SUBMITT ER 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 Nick 3.3.6 Note Gen Telford- Reed authority which enumerates each SRC system "Note: A guest experience does not always result in an SRC Profile being created. However information will be created to enable transactional data retrieval. If an SRC Profile has not been created, is not considered enroled in an SRC System" Clarification of what is created when a guest checkout occurs. When is an SRC profile created (the text suggests it is sometimes)? Acknowledge Section 4.3.6 SRC Profile has been clarified to describe when an SRC profile is created or not. The assumption made during a guest experience is that the consumer does not want a relationship and therefore no profile is created but the card is capable to be digitized to allow consistency for SRC transactions. Nick TelfordReed Nick TelfordReed 3.3.6.1 3.3.6 Nick TelfordReed 3.3.6.5 Nick TelfordReed 3.3.6.5 Para Section Para Para Ed Ed Te MAJOR Ge Reference to ADD, DELETE or UPDATE – more commonly defined as "CREATE, UPDATE or DELETE" An entity relationship diagram showing the many entities here would be very useful (SRC profile, PAN, TPAN, Device ID, consumer ID, digital card reference id, PAR etc) SRC Digital Card Reference Identity is described as a reference that all SRC participants can use – is each one therefore globally unique across all SRC systems? How will that be maintained, guaranteed? "visual version" see note above on need to provide prompts and cues that can work for visual-impaired consumers, or other disabilities which affect access to payment flows Include Entity Relationship diagram SRC system identifier required for each SRC system, prefixed onto SRC DCR ID. This also requires registry of SRC systems. Suspect this is required for many data types Accept Reject Acknowledge Acknowledge References have been updated. The SRC Specification 1.0 will not include use case examples or sequence diagrams. The SRCTF is considering options for including use case and sequence diagram examples in incremental documentation. The SRC Specification will not include SRC System Registry in 1.0 Draft. The SRC Specification includes the required data to enable a variety of consumer interactions. 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 36 SUBMITT ER 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 Nick 3.3.9.1 Para Ge Telford- Reed Nick Telford- Reed SRC ecosystem is (I think) undefined. Is this the superset of all SRC systems? Or should this simply read SRC system? Also see previous question about whether SRC requirement 3DS to be the only authentication methodology Nick 3.3.9.2 Para Ge Telford- Reed Nick 5.2 Telford- Reed Para Ge Nick 5.2.1.3 Para Ge Telford- Reed "SRC data defined by the specific payment network" – surely SRC system as the specification must surely allow non- payment networks to provide SRC systems (just as non-payment networks can be token service providers Change to "SRC system" "A remembered device is one that is trusted" – this surely can’t be correct. Wouldn’t we want to also remember devices that can’t be trusted? "Consumer recognition is performed when no device recognition is available or after device recognition fails" – I would have thought that there will be use cases to perform consumer recognition even if device recognition has Acknowledge An SRC Ecosystem is consisted of all the participants involved in SRC activities. Accept Reject Accept Accept The term SRC ecosystem will be defined within the specification. The SRC ecosystem contains all SRC participants and SRC System participants participating in the various environments. Section 3.3.9.1 was changed to reflect that payment authentication using 3DS serves as an example only. SRC System should satisfy the requirement of data in the authorisation message defined by the Payment Network, as a result, the data in the SRC payload is associated with the merchants existing authorisation messages with each payment network. The option to store device identifying information is related to consumer agreement. When a consumer agrees to be remembered the SRC system may remember device and choose to trust it or not. The language in this section has been updated. 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 36 SUBMITT ER 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 Nick 5.3 Telford- Reed Nick 5.3 Telford- Reed Nick 6.3 Telford- Reed Nick 6.3 Telford- Reed Para Ge Para Ge Para Ed Para Ge Nick TelfordReed Nick 7.2.2 Para Ge Telford- Reed been successful – in other words some participants will require consumer AND device recognition to be successful. Device recognised consumer recognised (shared/stolen devices) How is a default DCF configured? Is that something that the consumer can set? "Specific environment" – can you provide Provide examples examples please Acknowledge Accept No, the default DCF cannot be set by the consumer, it will be done by the SRC Programme. The SRCTF has deleted the reference due to ambiguity. "SRCPI sends a binding information…" Change to "SRCPI sends binding Accept information…" Errata "An SRC Binding event occurs when the following message is sent to the SRC System:  SRCPI sends a Binding information in the Enrolment Request (section 6.2.1 Enrolment Request/Response) to create a relationship between a Payment Card and a Consumer Identity " But section 6.2 describes this as an enrolment event. Is it both? Text says binding is performed by DCF or SRCPIs but Figure 7.3 says that SRCI can also perform binding - Clarify/make consistent Accept Errata Accept Accept An Enrolment request may include binding data. A binding Request /Response is an additional message to bind a device to an enroled card. The figure reference has been removed and further clarification on binding has been included in Section 5.3 and 7.3 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 36 SUBMITT ER 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 Nick TelfordReed Nick TelfordReed Nick TelfordReed Nick TelfordReed Nick TelfordReed Nick TelfordReed Nick TelfordReed Nick TelfordReed 8.1.3 8.3 8.3 8.4.1 8.4.1 8.4.4.1 8.4.5.1 8.4.7.1 Para Para Para Para Para Para Para Para Nick TelfordReed 8.4.10.1 Para Ed Before requirement Req 026 Ed Req 085 – spelling Change "The SRC shall" to "The Accept SRC system shall" Change "mulitple" to "multiple" Accept Errata Errata Ed Req 091 – spelling Change "enaled" to "enabled" Accept Errata Te MAJOR Ed See notes above – in Req105, are these identifiers globally unique across all SRC systems? Spelling in Req 107 Change "elibigle" to "eligible" Acknowledge The identifiers are unique within an SRC System. Accept Errata Ed Spelling in Req 117 Change "particpiant" to "participant" Accept Errata Ed Spelling in Req 121 Change "particpiant" to "participant" Accept Errata Ge Te MAJOR Req 123 is a "SHALL" requirement, but section 3.2.3 reads like a checkout request is not always required (e.g. "A payload request might be the first message in a series". Req 138 talks about CPR for _each_ SRC system – there is clearly a need for a central registry of SRC systems Change SHALL to MAY Accept Reject A Checkout request may not be required in all use cases. In revision 1.0 of the specification the SHALL in Req 123 will be changed to a MAY The SRCTF does not believe the SRC ecosystem requires registration for SRC Systems or SRC Programmes. 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 36 SUBMITT ER 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 Nick 8.4.10.1 Para Ed Telford- Reed Nick 8.5.3 Para Ge Telford- Reed Nick 11.4.2 Para Ge Telford- Reed Private – – ge Private – – ge Private – – ed Req 142 is a non-functional requirement Remove ("500ms") in a list of functional requirements Accept The requirement was removed in 1.0. Req 157 makes reference to clicking on a button but text elsewhere says gestures and voice can also initiate Text references handing over user experience to DCF – but other flows suggest Payment initiator can provide all UX How does acquirer tokenization work with SRC? Same question with merchant tokens? How do merchant/3rd party fraud systems work with SRC? How do co-branded cards work with SRC if at all? (e.g. non-brand authorizations) Change text to reflect multi-modal possibilities of initiation of trigger Clarify please Support merchant and acquirer option to participate in card brand tokenization. Do not allow the card brands to mandate subscription of the token services Accept Accept Reject Acknowledge Acknowledge The requirement has been modified to Replace 'click' to "Activate". 'When the Consumer Activates the SRC Trigger in order to initiate an SRC Checkout, the Digital…' This section has been rewritten for clarity. The specification only considers EMV technologies for payments therefore other payment technologies such as acquirer tokenization whilst possible are outside the scope of the specification. Functionality of existing fraud systems depends on merchant implementation for SRC and is out of scope of SRC specification. This consideration is outside the remit of EMVCo as the term co-brand may have different business interpretations. However, the specification supports a variety of implementation options. Refer to an SRC implementation provider for guidance. 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 36 SUBMITT ER 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 Private – – ge How is Routing choice maintained for Ensure merchant capability of choice Accept The text has been revised to state: The Durbin? If maintained, where in the flow will routing it reside? specification does not define requirements or limit a merchant’s routing options when a payload is enabled or otherwise eligible for transaction processing on more than one Payment Network. The routing decision is part of the payment orchestration process, which is outside the scope of SRC Private – – ed Does SRC make decline/approve decisions Acknowledge The SRC Specification does not describe on card authentication? Or does it simply provide a response saying "this card is likely authentic, merchant/issuer can make further decisions" the details of Card Authentication Assurance methods. The method of Card Assurance and the impact to subsequent authorisation is dependent on each SRC Programme. Private – – ed Will there be multiple enrolments in SRC Acknowledge The specification already supports multiple systems (SRC initiators)? Who will play this role? Issuers? Acquirers? Processors? enrolment as 'Batch Enrolment'. SRCI, DCF and SRCPI can perform Batch Enrolment provided that SRC System supports this function for the SRC Participant. Also, refer to section 2.3 SRC Participants to understand the relationship between entities and the function for roles they may take on. Private – – ed For merchants that already supports the card No merchant mandate for a strict Reject Any entity's establishment of, or brand programs (e.g. Visa, MC, etc.), what is SRC support timeline the migration path? participation in any SRC Programme is enabled and not limited by the SRC Specification. Specifically, migration from 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 36 SUBMITT ER 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 Private – – ed Cartes C.3 Bancair es Cartes Bancair es 3.3.6.3 Will there be a defined sunset timeline for the existing card brand programs? Dynamic data is a mandatory data in the Payload Response. This data is generated by the SRC System (definition p 6). But the SRC Progamme define methods and policies of generation. (annex C3.1) As far as we understand, security concerns should lead to specific controls in the relevant payment network. Moreover a SRC System depends on one or more SRC Programme (definition p 8) so that, depending on several SRC Programmes, the SRC System shall be able to deliver dynamic data for each one, in compliance with the different policies. The content of the 3.3.6.3 is clear: a SRC System can elect to participate with one or more TSP Programme. Add a mandatory functional requirements to the SRC Programme in order to make it possible for a SRC System to work with several SRC Programmes:

• Each SRC Programme authorizes an SRC System to work with several SRC Programme (no restriction from the SRC Programme to SRC System, SRC Participatinf Issuer, DCF, DSA or SRCI that could lead to the bundling of Payment Network and SRC System) General Comment: In part 8, there should be an entire part to cover the obligation of each SRC Programme wich is a major governing role in the SRC specification. The single Req 083 is not sufficient to provide a fair understanding of the whole SRC Ecosystem. Add a mandatory functional requirement to the SRC Programme: Acknowledge Reject Reject existing solutions is not considered within the specification. This question is an implementation related question and cannot be answered by EMVCo. The description of the programme from the framework has been included in Section 2.0 to provide context. The SRC Programme is business entity without a defined technical role, therefore EMVCo does not impose any requirements on such entities and their presence in the specification is merely informational. Payment Tokenisation and the choices of TSP are not in scope of the SRC Specification. The relationship between 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 36 SUBMITT ER 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 Cartes Bancair es 1 2 3.2.4.1 What is unclear is the counterpart of this approach: the Payment System or the SRC Programme or TSP Programme must not be allowed to forbid SRC Participants to use another TSP than what could be considered as the default one… There is no indication in the document that confirms that a SRC System may supports several DS. Even if the major interface involved the SRCI and the 3DS Server, the SRC System shall be allowed to convey 3DS Input/Output in order to provide payment authentication. If the SRC System provides SRC processes and events on behalf of several SRC Programmes, SRC System shall be allowed to work with different 3DS solutions.
• Each SRC Programme recognizes the ability for a SRC System to be token requestor of several TSP Programmes. No restriction from the SRC programme (neither to SRCI, DSA, SRC System, nor DCF or SRCPI) to use a TSP Programme which is different from the default one of the SRC Programme. General Comment: In part 8, there should be an entire part to cover the obligation of each SRC Programme wich is a major governing role in the SRC specification. The single Req 083 is not sufficient to provide a fair understanding of the whole SRC Ecosystem. Add a mandatory functional requirement to the SRC Programme:
• Each SRC Programme recognize the ability to a SRC System to provide payment authentication, via several DS Server. No restriction is allowed from the SRC Programme (neither to SRCI, DSA, SRC System, nor DCF or SRCPI) to use a Directory server which is different from the default one of the SRC Programme. Reject SRC Programme and Payment Tokenisation Programme is dependent on the specifics of each use case. An SRC PI that enrols their cards will choose the Payment Tokenisation options available to each SRC System. SRC Programmes are not technical participants, rather business entities and responsible for policies and business requirements. EMVCo does not create business requirements, policies or mandate any compliance obligations and hence such matters are outside of EMVCo's remit. The implementation is uniquely responsible for compliance with local laws and establishing business policies and consent requirements that enable sharing of information between participants. BA/TA/Dual/Sub = Dual Associate, or Business Associate or Technical Associate, or Subscriber company (enter a 2-4 letter abbreviation for commenting) 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 36 SUBMITT ER Cartes Bancair es Clause/ Subclause/ Annex Paragraph/ Figure/ Table/ Note 2.5.1 Type of comment2 Comment (justification for change) Proposed change Status Accept, Reject, In Progress, Acknowledge EMVCo observations on each comment submitted In case an SRC system would be relevant for different SRC Programmes, the SRC System shall be able to build a Candidate list that is compliant with the criteria fixed by each SRC Programme. General Comment: In part 8, there should be an entire part to cover the obligation of each SRC Programme wich is a major governing role in the SRC specification. The single Req 083 is not sufficient to provide a fair understanding of the whole SRC Ecosystem. Add a mandatory functional requirement to a SRC Programme in order to make it possible in all the relevant use cases. Reject The candidate list is described by the technical elements used to display the presentation as described in Section 3.0. The rules and policies that govern what data is returned in the related messages is SRC programme specific and outside the remit of EMVCo. Cartes Bancair es "3.4.1 "The Cardholder always provides consents to participate in Secure Remote Commerce". It could be usefull to understand who is the beneficiary of the consent since: 4.4: "Enrolment is the process that enables the SRC System to identify the Cardholder" 3.4.1 " SRC PI provides enrolment data on behalf of the cardholder" 3.4.4: "DCF provides access to Consumer data". As you know, in Europe, there is a Regulation about Privacy Data (RGPD): it is tremendously important to understand the way the authorisation are given, since a lot of actors are involved in SRC Processes to provide personal data to another one (SRCPI, DCF, SRC System). Reject Add a mandatory functional requirement to a SRC Programme: SRC Programmes are not technical participants, rather business entities and responsible for policies and business requirements. EMVCo does not create business requirements, policies or mandate any compliance obligations and hence such matters are outside of EMVCo's remit. The implementation is uniquely responsible for compliance with local laws and establishing business policies and consent requirements that 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 36 SUBMITT ER 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 Private 9.3 Table te 9.3.1 The consumer identity needs to be managed in a centralized perspective, where information can be validated prior to enabling access to the customer profile and payment information. In the spec, it’s explained that management may vary depending on the checkout model supported. 1- In an SRC checkout, it will be done by SRC-System 2- In a Merchant checkout, it will be done by DSA However, in chapter 9.3 – table 9.3.1 it is described as a potential valid value for Consumer Identity Provider the role of a 3rd party authenticator. It is not that clear who will perform this role into SRC Processes.
• SRC Programme organizes SRC in such a way that he guarantees he has no access to Consumer or Cardholder related data. General Comment: In part 8, there should be an entire part to cover the obligation of each SRC Programme wich is a major governing role in the SRC specification. The single Req 083 is not sufficient to provide a fair understanding of the whole SRC Ecosystem. It is not clear who can take the role of 3rd party authenticator or if this role can be combined with any other roles specified in the framework. In addition to that, we would see the need of more clarity on the process of certification of 3rd party authenticator - including its aspects of functional and security requirements. From an issuing perspective, ING sees the customer authentication step for Checkout process equally important as the Payment authentication process. Acknowledge enable sharing of information between participants. The specification provides no definition of the rules for entities that perform functions associated with an SRC system or participant. The rules and policies for SRC system participant solely within the realm of the SRC Programme. The specification simply defines a data element that a Programme may establish polices around. 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 36 SUBMITT ER 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 Private 5.1 Paragra Te ph 3 Private 5.1 Te Private 3.3.6.2 Paragra Te ph3 According to chapter 5.1, identification data can be sourced by SRC participants who have a consumer’s permission to store identification data and provide to SRCSystem. Still, on the process of identity collection and SRC Recognition, SRC participants may trigger the assurance level (for authentication purposes). As an Issuer, it’s important to get information from the SRC Systems, on what type of assurance has been already performed. This type of information is important to keep internal risk engine up to date/assertive and avoid compromise the customer experience asking for additional authentication level (e.g: via 3DS challenge) With regards to the Consumer Identifier, the specification only says that it must be managed in such a way as to prevent unauthorized access to the Payment Card information, but does not provide any details of how strong and secure it must be. As an issuer, we are mandated to comply with privacy and GDPR regulation, we must understand each role has access to what customer data, who is the owner and who is the processor of the data. For any risk based transaction analysis, we want to have access to the assurance data and information about the party performing authentication (3rd party authenticator) As an Issuer we have a concern on the security and certification aspects of consumer identity, in this way we would like to have more clarity on: a. In a general scope, which components will be submitted to certification? b. The role of certification body as it is not captured in the specification. Which of the current roles will perform certification? Accept Acknowledge Reject The communication of all data including consumer data is defined within the specification. The SRC Specification enables the entity that store and "use" the consumer data to comply with regional regulations. The communication of all data including assurance data is defined within the specification. Specifically, the availability of SRC Assurance Data is expected to be covered independently by each SRC Programme At this time, no specific certification requirements have been established for the technical aspects of the specification. The specification provides technical details and does not describe business functions. SRC Programmes establish the policies for data access and the requirements for compliance by relevant parties. 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 36 SUBMITT ER 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 Private 3.3.6.3 Te Private 5.2 Private 2.2 Paragra Te ph 3 Figure Te 2.1 After the tokenization of a payment credential, where is the token for payment purposes stored? (DCF, SRC System or DSA) In the process of Identity Collection and SRC Recognition, it’s not clear who starts the process and the flow One of the possible use cases is Merchant initiated transaction. As an Issuer we are concerned about Merchant initiated transactions in the scope of PSD2 / RTS c. The requirements for certification with emphasis on the security aspects. In addition to this question, in a ‘recognized checkout’ use case, does SRC Systems use the same token for multiple merchants/transactions or a different token? Can you clarify who initiates the SRC Identity collection, SRC Recognition? – Also including more details on the flow. Could you provide more clarity of the MIT customer journey? Acknowledge Acknowledge Accept Where the Payment Token is stored (and how it is used) depends on the technical implementations as well as business decisions within an SRC Programme. The process is started by the SRC Participants who have a Consumer’s permission to store identification data and provide it to the SRC System. The specification has updated the corresponding section about merchantinitiated transaction to provide extra clarity as it relates to gaining access to the relevant payment data. However, MIT is about authorization processing which is outside of the scope of SRC as it relates to the areas you have highlighted. Private 3.3.1 Paragra Te ph 2 According to the chapter 3.3.1, the SRC System may provide a unique trigger or multiple SRC Systems may support a single Could you provide more clarity on the process / flow of unique trigger x Acknowledge Section 4.2.2 provides additional clarity on the use of SRC Trigger. Further clarity and guidance can be found in the Common 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 36 SUBMITT ER 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 Private 6.4.1 Paragra Te ph 1 Private Te SRC Trigger where the presentation requirements would be managed by the SRC Initiator and distributed as SRC Common Software The role of SRC Common Software is not very clear. According to the specification, SRC Common Software can facilitate a Customer Profile Request to each eligible SRC System to gather information for presentation in the SRC Candidate list In some markets (The Netherlands) card details are not embossed on the plastic debit cards. We favour enrolment into payment wallets (including SRC wallet) initiated from the issuer environment (commonly referred to as push provisioning when a card details are being pushed from the banking application to wallet application) multiple SRC Systems supporting single SRC Trigger? Could you provide more clarity on the SRC Common Software? Have you considered how SRC could be implemented in this type of markets? Acknowledge Acknowledge Software Section 8.3 which provides details on support of multiple SRC systems. The SRCIs are responsible for distribution and management of common software. Section 4.3.1 and 8.3 provides details of Common Software. They assemble, as necessary, SRC System Software from multiple SRC Systems into Common Software distributed to participating Digital Shopping Applications. The SRC Initiator will distribute software relevant to the Digital Shopping Application based on their elected SRC Systems. This Common Software enables interactions between the Digital Shopping Application and all relevant SRC Systems requiring a user interface. Section 8.3 outlines the requirements for common software. The Specification supports enrolment initiated from issuer to the SRC System. The push provisioning from issuer to wallet is out of scope of this specification. 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 36 SUBMITT ER Clause/ Subclause/ Annex Paragraph/ Figure/ Table/ Note Private 3.3.9.2 1st paragra ph, 2nd sentenc e Private 3.2.4.2 2nd paragra ph Type of comment2 Comment (justification for change) Proposed change Status Accept, Reject, In Progress, Acknowledge EMVCo observations on each comment submitted The sentence below needs further clarification "The Acquirer routes SRC facilitated transactions to the qualified Payment Network using the networks message format." We would request EMVCo add a minimum requirement for SRC facilitated transactions to ensure they do not limit the ability for an acquirer to route such transactions to all eligible (or qualified) Payment Networks. This will ensure that merchants have the ability to exercise their ongoing choice of Payment Networks to ensure the most secure experience. Furthermore, What is meant by the term "designated payment" in the phrase: The acquirer will route the authorisation request to the designated network for authorisation and settlement consistent with current acceptance practices. In other parts of the document the term "qualified payment network" is used We would like to see an additional sentence following this to indicate that "SRC facilitated transactions will not limit the ability for an acquirer to route transactions to all qualified Payment Networks using the networks message format", We would like to replace the word designated Payment Network to eligible Payment Network. We would also like to see, in the same paragraph, an additional sentence following the first sentence, that indicates the proposal below in red. Following an SRC Initiator’s receipt of a payload, the SRC Initiator sends, on behalf of the Merchant, an authorisation request to the Acquirer. The SRC initiator must not inhibit the Acquirer’s ability to route to all eligible Payment Networks on the (digital) card." Accept Accept The section has been updated to state: The specification does not define requirements or limit a merchant’s routing options when a payload is enabled or otherwise eligible for transaction processing on more than one Payment Network. The routing decision is part of the payment orchestration process, which is outside the scope of SRC. The text has been revised to state: An Acquirer or its agent provides routing and authorisation services as part of normal business practices. SRC does not impact the routing or authorisation processes. In addition, new text has been added to Section 3.3.9 The specification does not define requirements or limit a merchant’s routing options when a payload is enabled or otherwise eligible for transaction processing on more than one Payment Network. The routing decision is part of the payment orchestration process, which is outside the scope of SRC. 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 36 SUBMITT ER 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 Private Private 3.2.4.1 C.2.2 1st sentenc e The interface between the 3DS Server and the SRC Initiator is proprietary to the 3DS Server and outside the scope of the Specification The sentence below creates a binding between the SRC Participants and the SRC System. Credentials are assigned to SRC Participants by the SRC System during onboarding Later on in paragraph after the bullets, it indicates Participants will be assigned security credentials that enable cryptographic proof of identity to be provided during an SRC transaction. It is critical that assignment of the security credentials that enable cryptographic proof of identity to be provided during an SRC transaction, does not inhibit a merchant or Acquirer’s ability to route that SRC transaction to all eligible Payment Networks on that (digital) card. This is an important point because the specification is very clear about the value of credentials and the need for cryptographic proof of identity to ensure a secure remote commerce transaction. However, it is equally important that Given 3DS Server and SRCI are part of two EMVCo specifications, it doesn’t make sense to not have a defined interface that adheres to minimum defined security requirements. A proprietary interface will simply promote an implementation that is neither ubiquitous nor interoperable. We propose addition of the sentence that states the following after the sentence in the paragraph following the bullets: Assignment of the security credentials that enable cryptographic proof of identity to be provided during an SRC transaction, does not inhibit a merchant or Acquirer’s ability to route that SRC transaction to all eligible Payment Networks on that (digital) card. This proposal has nothing to do with policy or implementation but simply a statement of minimum security requirements and expectations of SRC compliance. Acknowledge Accept This statement was meant to convey that interfacing requirement would not be found within the SRC specification but is expected to follow requirements governed by EMV 3DS specification. Accept in Principle: The text in Payment Orchestration has been revised to state: "The specification does not define requirements or limit a merchant’s routing options when a payload is enabled or otherwise eligible for transaction processing on more than one Payment Network. The routing decision is part of the payment orchestration process, which is outside the scope of SRC." 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 36 SUBMITT ER Clause/ Subclause/ Annex Paragraph/ Figure/ Table/ Note Private 5.3 Private 6.2 1st paragra ph, 3rd sentenc e 1st paragra ph Private 7.1.1 Whole section Type of comment2 Comment (justification for change) Proposed change Status Accept, Reject, In Progress, Acknowledge EMVCo observations on each comment submitted merchants and Acquirers NOT be restricted from exercising the most eligible route, irrespective of the SRC system that generated the cryptographic proof of identity. The SRC System must establish proprietary criteria that defines the selection of a specific Digital Card Facilitator. The enrolment process can vary from SRC System to SRC System and may involve the use of proprietary enrolment mechanism or may be facilitated through an Enrolment Request This section promotes the use of a proprietary solution between an SRC system and SRC system participants (SRCPI, DCF and SRCI). How does proprietary criteria to select a specific DCF promote a ubiquitous solution when merchants have to integrate to multiple SRC systems? Does this mean the APIs the SRC system are proprietary as well? A proprietary enrolment mechanism will create disparate solutions, and potentially less secure solutions. Shouldn’t the SRC spec be promoting consistent solutions only – i.e. through an Enrolment Request, with minimum requirements that supports core data elements, while providing flexibility to add additional data elements? That way, minimum security requirements are ensured by an SRCPI and SRC system that claim to be conforming to the SRC specification. Isn’t this counter-intuitive to establish a standard the provides consistency, ubiquity and interoperability of digital card acceptance? Acknowledge Acknowledge Acknowledge Selection of DCF does not impact the merchant’s integration with SRCI or the message or API’s that are utilized. The DCF selection process is an internal SRC system process. Enrolment Proposed: The SRC Specification includes enrolment messages that may be used to promote commonality in the enrolment processes. SRC specification outlines Onboarding process. Establishment procedure depends on SRC Programme. 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 36 SUBMITT ER 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 Private SRC System onboards SRC System Participants using their own proprietary solutions:
• SRCPI
• Digital Card Facilitator
• SRC Initiator There is no specific mention in the specification that the selection of an SRC system for enrolment and authentication should not inhibit nor interfere with the merchant’s or Acquirer’s ability on behalf of the merchant, to route the resulting SRC transaction across all eligible Payment Networks across the existing payment rails. A public specification or a toolkit should not be leveraged to implement proprietary solutions that achieve the objective of the specification. We propose the addition of language such as: Reject The SRC specification does not provide any requirements on the selection of the SRC System for Enrolment. The decision of which SRC system a PAN will be enroled into is at the discretion of the SRCPI. Therefore, any routing is outside the scope of the specification Private 8.3.2 Whole section SRC Common Software – SRC Candidate List The selection of an SRC system for enrolment and authentication should not inhibit nor interfere with the merchant’s or Acquirer’s ability on behalf of the merchant, to route the resulting SRC transaction across all eligible Payment Networks across the existing payment rails. Doesn’t the SRC Common Software assist a merchant from having to integrate with multiple SRC systems, given that this software facilitates the aggregation of an SRC candidate list to enable selection of digital cards? Acknowledge SRC Initiator provided Common Software should be designed in manner that enables the DSA to choose which SRC Systems they participate within and integration of those system will be supported by the Common Software. This means that the DSA choice drives the 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 36 SUBMITT ER Private USPF USPF USPF USPF 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 Does the SRC Common Software accessibility of one of more SRC Systems. also ensure that SRC systems will support all card brands while ensuring a consistent level of security and assurance? The SRC Initiator interfaces with the SRC System(s) to enable the digital card presented that matches the preferences of the merchant, as well as the enroled cards eligible for selection by the consumer. All of SHAZAM’s prior comments/concerns Acknowledge Business and Implementation details on prior versions of SRC specification still apply, even those that have been categorized as business/implementation concerns. remain out of scope of EMV Specifications. The SRCTF would like additional detail on why these comments/concerns are applicable to the Specification. Please provide additional details. ed Does SRC require the use Tokenization or Acknowledge The SRC Specification does not require the EMV 3DS? use of either Payment Tokenisation or 3-D Secure. ed Does an SRC Programme specify sharing Acknowledge SRC provides a suite of EMV 3DS data that particular data elements from the enriched data set found in EMV 3DS? What are those may be used in SRC. required data elements? ed Can the SRC specification support merchant Acknowledge Yes, the SRC Specification doesn't preclude card on file? this use case. ed Does SRC facilitate auto-fill of fields, and Acknowledge SRC provides the data to enable autofill share billing and shipping information with the Digital Shopping Application/merchant? and share billing and shipping information, which could be used for an autofill user experience. The actual implementation of the user Experience is out of scope for the SRC specification. 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 36 SUBMITT ER 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 USPF USPF USPF USPF ed Is a wallet required to participate in SRC? ed Is a wallet the same as a Digital Card Facilitator in the SRC spec? If not, how is it different/same? ed Is the DCF proprietary to the issuer or owner of the wallet? ed Does the card provisioning into the DCF have implications to transaction routing? Acknowledge Acknowledge Acknowledge Acknowledge Whether a wallet is required to participate is determined by individual SRC Programmes. The language in Section 2 has been updated to provide additional clarity, but a wallet could be a digital card facilitator however, a wallet is also much more than just a Digital Card Facilitator. Wallet is not a universally understood term, but general wisdom is that a wallet has a unique merchant participation footprint that is managed and controlled by the wallet alone. A digital card facilitator does not have a direct relationship with a merchant and is not by definition a wallet. Any entity's establishment of, or participation in any SRC Programme is enabled and not limited by the SRC Specification. Specifically, the availability of various DCF options are expected to be covered independently by each SRC Programme. This should not impact routing, this is out of scope of this specification. The text in Payment Orchestration has been revised to state: "The specification does not define requirements or limit a merchant’s routing options when a payload is enabled or otherwise eligible for transaction 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 36 SUBMITT ER 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 USPF USPF USPF USPF ed Where an issuer provisions cards into more than one DCF, how is the card represented in the candidate list during an SRC checkout? Will the cardholder see two or more versions of the card in the candidate list? Please provide examples of what the cardholder would see in the DSA/merchant checkout process. ed Does the SRC System make an approval / decline, or provide an Assurance level to the issue for final decision? What visibility are other stakeholders given to these decisions and/or factors that led to the Assurance level? ed What use cases exist for SRC? ed What is the role of SRC vs. 3DS for card and user authentication? Acknowledge processing on more than one Payment Network. The routing decision is part of the payment orchestration process, which is outside the scope of SRC" Section 3.0 provides additional details surrounding the presentation of the candidate list based on the technical contents of the information presented. The Specification does not and cannot describe business policies that influence how the presentation is determined. Acknowledge SRC enables checkout and provides means for assurance, however the decision to approve or decline a transaction is not made by the SRC System. The SRC System will provide the relevant data only. Acknowledge Acknowledge The 1.0 Draft Version of SRC Specification describes 2 checkout models: SRC Checkout and merchant checkout. Refer to Section 2 for more details. Currently EMV SRC and EMV 3DS technologies can co-exist in cases where an SRC System or its participant is a 3DS server. The SRC specification defines 3DS as a form of cardholder assurance that can be performed to authenticate a cardholder usage of a PAN. SRC does not describe 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 36 SUBMITT ER Clause/ Subclause/ Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) USPF USPF USPF USPF ed How does lifecycle management work within the SRC system? What changes will be required of each of the SRC roles to support lifecycle management? ed How does an issuer support multiple network availability for a card in an SRC system? Please provide examples. ed Who (what SRC role or industry stakeholder) handles merchant registration? ed What is the vetting process for merchant registrations? Proposed change Status Accept, Reject, In Progress, Acknowledge EMVCo observations on each comment submitted Acknowledge Acknowledge Acknowledge Acknowledge authentication, rather it describes assurance, which is the authenticity of an assurance claim that maybe related to different aspects of the interactions within SRC. There is assurance for Card, Cardholder, Consumer Identity, Device Identity and Relationship and the data within SRC describes, which entity performed assurance and what method of assurance was performed. The SRC Specification describes messages that may be used to enable life cycle management. Many of these messages have "add update delete" options that may be utilised to facilitate lifecycle management. In some scenarios, there can be more than one Digital Card representing a single Payment Card. It is the responsibility of the SRC Programmes to define and manage policies consistent with international, regional, national or local laws and regulations. Section 5.2 describes registration. The SRCI is the role responsible for registration the merchant with the relevant SRC System The vetting process for merchant registration is outside EMVCo’s remit and 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 36 SUBMITT ER 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 USPF USPF USPF USPF USPF USPF SRC Specification and is a business policy established by an SRC Programme ed What SRC evidence / info is included in the normal authorization and settlement transactions? How will an issuer know SRC was performed? Acknowledge Authorization and settlement are out of scope of this specification, therefore the information in corresponding messages are implementation specific. ed Does the SRC specification support the ability for a card to be represented more than once in an SRC implementation (i.e. co- badged card)? Acknowledge The specification does not describe nor preclude support for the ability for a card to be represented more than once in an SRC implementation. The guidance for this situation would be described by an SRC Programme as part of their implementation requirements, and such consideration are outside of the remit of EMVCo. ed How does a cardholder enrol a co-badged card in SRC? Do they enrol in multiple DCFs or need to choose a DCF? Acknowledge The SRC specification does not provide any requirements on the selection of the SRC System for Enrolment. The decision of which SRC system a PAN will be enroled into is the discretion of the SRCPI. ed Does the cardholder always need to be authenticated before device binding? If not, how is the use of the cardholder account authenticated? Acknowledge The SRC Specification does not define a requirement to authenticate a Cardholder prior to binding. The SRC Assurance for Cardholders is defined by SRC Programme. ed Can proprietary card products participate in SRC? Acknowledge The specification is designed to support any card payment. ed Does completion of an SRC process with any System in any way impact the transaction Acknowledge Authorization and clearing are out of scope of the SRC Specification therefore any impacts to such processes are 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 36 SUBMITT ER USPF Clause/ Subclause/ Annex Paragraph/ Figure/ Table/ Note Type of comment2 Comment (justification for change) processing paths available for the transaction authorization and settlement? ed Is the SRC enrolment within the merchant/DSA checkout required or optional? USPF ed What data will be available from SRC for merchant fraud prevention systems? USPF ed How would SRC work with if a merchant uses acquirer tokenization processes? USPF ed Is the goal of the SRC specification to reduce fraud or increase authorization rates? USPF ed Please provide examples of use cases which do not involve the cardholder in the enrolment process. USPF USPF ed Please provide examples of how SRC could support Connected Commerce. ed How would SRC work with if a merchant uses an external P2PE processes? Proposed change Status Accept, Reject, In Progress, Acknowledge EMVCo observations on each comment submitted Acknowledge Acknowledge Acknowledge Acknowledge Acknowledge Acknowledge Acknowledge unknown. Consult implementation providers for details. The specification does not describe any specific requirement concerning this condition however such decision are implementation specific The contents of the payload response could be utilized as part of a merchant fraud prevention systems. A merchant’s implementation with an acquirer tokenization process is out of the scope of the EMV SRC Specification. EMVCo SRC strives to create an interoperable, secure specification that will improve the current CNP landscape. The specification describes enrolment as a process that can originate through an issuer who is ultimately responsible for the T&C’s of the service. The practices and policies of that issuer will dictate specific enrolment conditions Since Connected Commerce is not an established process, EMVCo cannot provide comment. However, SRC enables a broad range of use cases. How merchants use P2PE or other encryption solutions is currently not covered by this specification. 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 36 SUBMITT ER MAG 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 Concern re: flexibility for merchant to prioritize proprietary products within the SRC Candidate List. Additional Comment: Where are customer or merchant preferences are outlined in the specs? Ref - : Order of cards presented will be based on the data elements Date of Card Last Used and/or Date of Card Enrolment. Merchants are closest to the customer user preferences for payment within their websites/apps and the spec should not dictate a merchant choice of prioritization among payment choices for their customers. Accept Section 2.9.1 has been updated with more details about the Candidate List. MAG Lack of clarity on the priority for stakeholder preferences for the DCF Discovery process and the impact the customer experience based on those stakeholder preferences. Ref - : While multiple DCFs may be possible, the SRC Program will determine the criteria to enable Digital Card Facilitator selection. This may be driven by consumer preference, issuer preferences or Digital Shopping Application preferences. The exact criteria is implementation specific. Ref – : The SRC System uses the Digital Shopping Application’s acceptance preference and configured service options, the Issuer assurance preference and the Digital Card Facilitator configuration and capabilities, along with profile Acknowledge The revision 1.0 draft of the specification provides more clarity on the DCF Discovery process. However, the specific criteria involved in the DCF discovery process is not covered within the specification 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 36 SUBMITT ER 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 MAG MAG MAG information to qualify the Digital Card returned in response. Lack of clarity how the merchant checkout experience may change at a later date. Ref - : While merchant checkout is supported by the Specification, the current version focuses on SRC checkout. Further details on merchant checkout may be added in later versions of the Specification. Acknowledge Merchant Checkout is fully supported with the 1.0 Draft revision. Concern the specification is effectively requiring a merchant to share proprietary data with SRC participants that may or may not be applicable to such SRC participants. Section 9.8 Confirmation Data -Table 9.8.1: Event Reference Data, there is a data element called "Network Identifier" which represents the network the payment authorization request was completed through. This should be an optional business decision as to if the DSA/SRCI wants to support the passing of data that is not applicable to SRC process, This specification should not be prescribing network identifiers as required data elements. Accept The network identifier is now optional. Inconsistency in the consumer experience between the various SRC Checkout experiences under the SRC rails. The data exchange within each checkout regardless of SRC System or SRCi need to be consistent for merchant integration. Ref - : Merchant checkout experiences are controlled by the merchant. In this context, the merchant may use SRC Messages (i.e. "the rails") in order to drive to an SRC Candidate list and facilitate card selection. The final payload is delivered from the SRC System. Acknowledge Please refer to the section on Candidate list (2.9.1) 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 36 SUBMITT ER 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 Risk to consistency in the options presented to the consumer in checkout if the interface between the DSA and the SRCi is proprietary to the SRCi. Concerns around differentiation by SRC Systems causing risk of inconsistency in the customer experience of the presentation for the Candidate List. Ref - : The interface between the Digital Shopping Application and the SRC Initiator is proprietary to the SRC Initiator but may contain key SRC data elements that is necessary and present throughout the lifecycle of a single SRC interaction. Two data elements that may be included in the SRC Initiator’s proprietary interface are the SRC Correlation ID and SRC Digital Card Reference Identifier. MAG MAG MAG Does SRC allow for split shipment that involve multiple authorizations from but related to a single guest interaction. Scenarios resulting inconsistencies among Systems for support of shipping data which would require Digital Shopping Application (merchant) to have different requirements. How does the spec support user experiences and potential use cases for remote consumer Ref – Section 8.4.10.1: An SRC System Participant that presents an SRC Candidate List SHALL This should be a SHOULD not SHALL or MAY Ref – Section 8.4.10.2 [Req 148]: The SRC System Participant MAY: Present additional input data to the Consumer based on use case Acknowledge Reject Acknowledge The specification does not call out this specific use case however support of this use case is possible utilizing a payload request. The collection of additional input data may or may not be needed based on the specific use case. EMVCo's remit is to support Card Based payments, and thus the specification is 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 36 SUBMITT ER 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 MAG MAG payments beyond traditional card-based payments. The specification should not be limited to payment card issuers as the only party allowed to perform provisioning and dictate the assurances allowed or required. This function should be allowed to be performed by non-issuers to support other non-card payment alternatives. The specification limits the payment alternatives allowable for a merchant to accept. A global specification should not limit a merchant’s choice of payment alternatives to be accepted by its design. Acknowledge focused on the messages, data fields, security and processes associated with card-based interactions. As with any EMVCo specification, adaption by noncard payment solution is not precluded, however, the specification does not describe any unique consideration for such environments. The specification covers card payments which are managed by card issuers. Any use outside of card payment is not described nor precluded by the specification. Acknowledge The specification covers card payments and is silent on other payment alternatives. It does not prevent nor describe such payments as these are outside the remit of EMVCo. SRPC SRPC ed The Specification defines a single standard for the online checkout process, originally advocating for the use of a single checkout button for the global network brands but supporting different implementation options for achieving that functionality. ed The SRPc has concerns about the customer experience, as the process flow defined in the Specification takes the customer out of Acknowledge The EMVCo SRC Spec describes an SRC trigger for one or more SRC System(s) for consistency. Acknowledge The SRC specification does not provide any requirements on the need to enable 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 36 SUBMITT ER 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 SRPC SRPC SRPC the purchase transaction and redirects them for enrolment in the solution. Merchants have expressed concerns that redirection within the transaction process flow has the potential to increase shopping cart abandonment, as the industry experienced with the implementation of 3D Secure. ed The Specification also does not address how proprietary payments, such as private label cards, will be supported. Merchants have questions about how they integrate a single pay button on the checkout page and still maintain the ability to prompt for payment alternatives, particularly using their own proprietary checkout button. ed The Specification is also silent on how the global network model will seamlessly support cross channel experiences, namely mobile ed Limited details are available on the implementation plan for SRC, and the industry stakeholders have concerns that the global network brands will drive implementation plans and the timeline. enrolment in the transaction process. The decision of when an enrolment occurs is the discretion of the SRCPI. Acknowledge Acknowledge Acknowledge The specification is designed to support any form of Card Payment, inclusive of proprietary cards, such as those from private label cards. It up to an SRC Programme to establish business policies for card payments, and to work with one or more SRC Systems to support enablement. This specification can support a lot of possibilities as per the guidelines provided, the SRC ecosystem Participants will be providing consistent experience across the channels. The specification doesn’t limit the scope to any specific use case. The SRC specification outlines the overall architecture, the roles and functional requirements for the SRC System and the SRC Participants as well as common messages and APIs to support a variety of use cases for e-commerce. Any implementation plans are business related and not in scope for EMVCo. 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 36 SUBMITT ER 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 SRPC SRPC SRPC SRPC ed The SRPc shares a growing awareness and concern about the dates for the implementation of SRC, particularly if those deadlines are imposed without significant input from the payment systems at large, namely banks, merchants, domestic debit networks, and payment processors ed Questions remain about the ease of implementation, and how disruptive or difficult the deployment cycle will be. Industry stakeholders need reasonable timelines for development, testing and deployment of SRC. ed Greater detail is needed to define the functional requirements for the enrolment process, management of consumer credentials, and management of the transaction before the payment route has been established. For example, it is unclear whether the implementation of the SRC will place any restrictions on which entities can perform credential management. Some of these issues may be specified in the operating rules but these have not yet been released for review and comment. ed Among the biggest concerns is how the existing eCommerce gateways will incorporate the proposed API into their existing infrastructure to achieve interoperability. This is important because it Acknowledge EMVCo makes no business polices or defines any business implementation specific requirements regarding timelines or product definitions therefore EMVCo is unable to comment. Acknowledge Acknowledge The implementation details of SRC solution is will be different across SRC Programmes and is out of scope of this technical specification. For implementation plans, consult individual SRC Programmes. Any entity's establishment of, or participation in any SRC Programme is enabled and not limited by the SRC Specification. Specifically, the details of enrolment for each use case are expected to be covered independently by each SRC Programme. Acknowledge EMVCo SRC Specification provides the functionality of SRC. How existing gateways incorporate with the SRC prop