EMV® Secure Remote Commerce Disposition of Comments

2019-03-22T00:00:00+00:00 v1.0

Secure Remote Commerce

Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.7 8.2.1 [Req 058] Te "SRC System SHOULD provide SRC Clarify who else might be able to Accept The ‘SHALL’ was changed to System SW to SRCI"; used to be provide SRC System Software if not the ‘SHOULD’ to address scenarios SHALL; why the change? SRC System; where there is no consumer device enabling the functions associated with System Software. The intent was not to imply System Software could be provided by entities other than the SRC System. For 1.0 Draft Section 8 has been reworked. 0.7 8.3.4 Te Assurance steps missing Please explain when assurance Accept EMVCo 1.0 Draft SRC spec happens and how it is handled between describes assurance and in multiple SRC Systems Section 2.8 Assurance may occur at a variety of times based on the SRC Programme. Assurance between SRC Systems is not defined in the SRC specification.

0.7 B API1 vs

Te The scope of the two APIs is not the Make sure both APIs cover the full Accept 1.0 API Specification Draft will API2 same. Accordingly, they are difficult to extent of the use cases from DSA- include more detail on all APIs. compare: API 1 supports the Registration to consumer "discovery", consumer "detection" for new binding (unbinding), checkout etc. consumers (/identities endpoint) which is crucial, but API2 includes aspects of risk handling, which is also important. Also, API2 includes an endpoint for DSA registration, which is great. 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. 3/14/2019 AXP Public

0.7 B.1-B.9 API1 Te API1 does not define versioning. API2 Include how versioning of the API is Accept 1.0 API Specification Draft will proposes version number in URL, done (e.g. using version number in include more detail on all APIs. which is a good idea URL) The SRCTF will include industry best practices of the protocols and api associated with the platforms supported.

0.7 B.5 API1 Te Naming of endpoints is not consistent Rename /transactionCredentials to Accept 1.0 API Specification Draft will yet /checkout (to align better with the rest of include more detail on all APIs. the documentation) The endpoint naming will be Rename /bind to /bindings and allow updated (may not use the DELETE method to unbind (drop the suggested names) in an EMV /appInstances endpoint, as it introduces SRC API specification 1.0 Draft a new name, which is not needed when /bindings allows the DELETE method… 0.7 B.1-B.9 API1 Te Some context is still missing: which Please include full life cycle sequence Reject 1.0 API Specification Draft will participant calls which API provided diagrams (or similar) so that it’s clear include more detail on all by which other participant? who calls what when. APIs.The release of 1.0 Draft will not include sequence diagrams. Sequence diagrams will be considered for future versions. 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.7 B.1-B.9 API1 Te Please describe how the results of the More context needed to understand the Accept 1.0 API Specification Draft will /identities call(s) will enable to API include more detail on all APIs. ultimately call /bind and then allow to use the /customerProfile endpoints 0.7 B.9.2 Channel Ed Typo in name "rpc IentitydVerification" Should be "rpc IdentityVerification" Accept 1.0 API Specification Draft will Agnostic include more detail on all APIs.. Definition 0.7 B.9.4 Te Unclear, why a Please provide some context Accept 1.0 API Specification Draft will IdentityValidationCancel would be include more detail on all APIs. used 0.7 B.10- API2 Te API doesn’t provide functionality to Complete all use cases Accept 1.0 API Specification Draft will B.13 discover unrecognized consumers include more contextual detail (e.g. /identities endpoint from API1 on all APIs.to clarify the ability to recognise consumers is available in the Identity Lookup message 0.7 B.10- API2 Te A few endpoints are not provided with Consolidate endpoints and put more Accept 1.0 API Specification Draft will B.13 enough context yet. And it’s unclear functionality into a few relevant ones include more detail on all APIs. why there are 3 endpoints for (that’s why API1 is preferred) Addressed in 1.0 Draft. /digitalcards, /card /digitalcardsreferences etc. 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. 3/14/2019 AXP Public

0.7 B.12.3- Te Unclear how the ID messages relate Please, explain/document the related Reject 1.0 API Specification Draft will B.12.10 to each other and where they are use cases and the involved participants; include more detail on all applied/used; APIs.The release of 1.0 Draft will not include sequence diagrams. Sequence diagrams will be considered for future versions. 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. 3/14/2019 AXP Public

0.7 B.13.4 Te Why only supporting HTTP1.x? Make HTTP1.x mandatory but allow Acknowl 1.0 API Specification Draft will HTTP2 edge include more detail on all APIs. Accept in principle to not only support 1.x by removing the requirement on the HTTP Protocol. Reject the proposed change to provide mandatory requirement on protocol 0.7 B.13.15 Te What does the /certificates endpoint Please explain (it’s not referenced Accept 1.0 API Specification Draft will provide? anywhere in the document); include more detail on all APIs. 0.7 2.5.1 Paragrap Te It is not clear how the SRC Candidate Describe how the SRC Candidate List Reject Section 3 for 1.0 draft describes h 2 List presentation layer and its criteria presentation layer and its criteria for the recommendations for for card presentation will be enforced card presentation will be enforced management of the candidate through multiple SRC systems. Will through multiple SRC systems. list. The specification is not there be enforcement or governing meant to describe enforcement controls, or will it be left to the on the SRC Candidate list discretion of the SRCI serving up the presentation. The requirements candidate list? focus on the presentation of Digital Cards. 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. 3/14/2019 AXP Public

0.7 Ge The document would be clearly with Add clear sequence diagrams

Reject The release of 1.0 Draft will not sequence diagrams, without these it is include sequence diagrams. very hard to follow and understand Sequence diagrams will be the experience we are trying to get to. considered for future versions. 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.7 ge The specification does not offer Build into the specification enhanced Reject While the specification provides confidence in an ideal user confidence around the user experience the constructs to bring about experience. The introduction of for both enrolment and checkout SRC experiences, and also multiple calls results in increased including flexible alternatives to reduce indicates the possibility for a failure points with potential the number of hops or calls required for variety of checkout scenarios, implications to the speed of checkout an SRC enrolment or checkout as well for instance, when an SRC and the user experience. as alternatives to reduce the number of Profile is fully bound for a actions the user must take to enrol or remembered and trusted device checkout. The specification should where additional verification reflect the user experience expected for may not be required, it will be all potential use cases of consumer up to individual SRC cards enrolled, merchant payment implementations to provide alternatives available to those SRC detailed user journeys and enrolled consumers, and the SRC optimize user experiences Participants (or non-participants such as accordingly. a browser DSA under W3C not participating in SRC) including but not limited to domestic/local payment networks potentially involved. 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.7 ge The specification does not offer Build into the specification enhanced Reject Any entity's establishment of or confidence in an ideal user confidence around the user experience participation in any SRC experience. The introduction of more for both enrolment and checkout Programme is enabled and not taps/clicks or general user actions including flexible alternatives to reduce limited by the SRC required to checkout increase the the number of actions the user must Specification. opportunity for user drop- take to enrol or checkout. The off/abandonment. specification should reflect the user experience expected for all potential use cases of consumer cards enrolled, merchant payment alternatives available to those SRC enrolled consumers, and the SRC Participants (or non- participants such as a browser DSA under W3C not participating in SRC) including but not limited to domestic/local payment networks potentially involved. 0.7 ge The SRC specification does not Include within the specification a Reject Any entity's establishment of or provide clarity as to the flexibility and detailed use case that reflect the participation in any SRC openness for payment networks that flexibility for a domestic payment Programme is enabled and not are not also owners of EMVCo to network in any region across the globe limited by the SRC participate in the SRC framework. to participate in the SRC framework. 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.7 ge The SRC specification does not reflect Include in the specification details and Reject The SRC Specification 1.0 Draft clarity regarding the interoperability of use cases that reflect how payment will not include use case tokens across multiple payment tokens would be interoperable across all examples. The use of payment networks that participate in SRC participants within the SRC system tokens by an SRC system is whether global or domestic. including but not limited to full support of defined as optional. It’s the cryptogram and domain control responsibility of the SRC validation among payment networks system to work with appropriate participating in SRC. TSPs to facilitate any token data necessary for processing. 0.7 ge When does an SRC Correlation ID Include in the specification where this Accept The specification provides need to be used? would be required for follow on details for the creation and use transactions. of SRC Correlation ID. 0.7 ge The disposition of comments notes Please add omni-channel use cases to Reject The SCRTF acknowledges that that the WG is reviewing additional the next version of the specifications. the use cases suggested exist use cases for the next specification and believes that the update. As input, please consider specification does not preclude omni-channel scenarios, and multiple them. The Specification authorizations flowing from a single provides the toolset to enable guest interaction. many use cases for a variety of SRC Participants. The SRC Specification does not include use cases. 0.7 ge Request for the Framework to be Please update the SRC Framework. Accept The relevant framework content updated to reflect assumptions which has been incorporated in have evolved in the spec. Section 2 of 1.0 Draft. The Framework will be sunset after the publication of 1.0 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.7 ge Does SRC allow for split tenders Please include clarity regarding this use Reject The SCRTF acknowledges that (using two or more tenders to case in the specification. the use cases suggested exist complete the transaction)? Multiple and believes that the SRC tenders could include some payment Specification provides the accounts from outside SRC, and one toolset to enable many use or more from the SRC eligible cases for a variety of SRC payment accounts. Participants. 0.7 ge If the Programme defines the common Please clarify if this is an accurate Accept The SRC Common Software is software, then do all participating consequence of the Programme provided by the SRC Initiator, systems also need to follow the rules defining the common software, or if and the SRC Initiator is of that Programme? provisions elsewhere govern the scope responsible for following of Programme rules. guidelines and policies instituted by the SRC Programme(s) in which they participate. Refer to Section 4.3.1 and 8.3 which provides details of Common Software 0.7 ge If a DSA integrates with more than Please clarify the prioritization of SRCi Reject Implementation details are out one SRCi (where the same account implementations where more than one of scope for EMVCo. may be provisioned in more than one is implemented by a DSA. SRCi), what SRC controls the SRC experience? 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.7 5.3 0.7 ge "The second paragraph states, "The Elaborate on the impact this has on an Accept SRC System will evaluate compatible acquirer's ability to make a routing brand acceptance based on Digital decision after the SRC flows are Shopping Application configuration completed and it is time to submit an and Digital Card Facilitator eligibility." authorization request. The exact same language quoted to the left still exists in the document and the section does not materially address the question. 3.3.6.3 p 52 Ge/Te "SRC System can elect to participate in one or more Token Programmes as part of the creation of the Customer Profile. In this instance, the SRC System will act as a Token Requestor and will interface with relevant TSPs": Please clarify the interactions when a SRC System is token requestor for several TSPs: Several processes are involved (ex: Payload). Which Payment Network should be considered by SRCI System /Acquirer in this case ? Accept The SRCI is responsible for managing the DPA’s acceptance profile. 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. The SRC system will act as a Token Aggregator and will interface with all relevant TSPs. 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.7 p 44 3.2.4.1 0.7 p50 3.3.6 Interface between 3DS server and SRC Initiator is proprietary to the 3DS Server and outside this scope of spec. (Payload response can be used at a source of information. If a cardholder /Consumer does not accept terms and conditions that enable the Consumer Identity to be remembered, then the SRC Profile should not be maintained, however, information will be created to enable transactional data retrieval. A profile generated during guest experience, where T&Cs has not been provided, is not considered enrolled" Difficult to understand if EMVco tries to rationalize a UX under the ‘brand’ SRC and if so, the auth process is a major element which pave the UX (so to be further described). In order to ensure a consistency of SRC UX, EMVCo must define main interactions/events between SRC environments and 3DS server Please clarify the relevant principles applying to relationship assurance ? Especially when a guest user makes several SRC transactions as a guest ? The deleting of guest consumer data must be possible and explained. Who is responsible of the writing of the T&Cs about Consumer Identity with the Consumer ? SRC System ? (cf table 9.5.8 p161 and p 162) Acknowl edge Accept Currently EMVCo SRC and EMVCo 3DS can co-exist when SRC System is the 3DS server. The service provider will conform to implementation requirements defined by 3-D Secure implementations. The Specification supports the idea that a relationship can be established and verified during an SRC interaction, it does not describe what this relationship is as the specifics concern implementation logic. The Specification provides the data fields to communicate T&C but will not provide the details of the T&C or the entity that establishes the terms. 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.7 Annex C 0.7 P119: Consumer Profile and Customer Profile are 2 terms used in the spec and as far as we understand, Consumer Profile is a consolidation of several kinds of customer data get via Enrolment /Binding and /or Payment Process. The Consumer Profile Data are stored in the SRC System. So that p37, it is written that Protection of personal Consumer Data is a security principle. the Consumer Profile Data Storage is a highly sensible component. But no kind of encrypted area is described in this spec. It is a major concern for at least 3 actors since TODAY, the Consumer is the Customer of 3 entities (Merchant, Issuer, DCF). SRCI is authorised to receive payment credentials in the Payload Rep – (SRC Paymt/SRC Non paymt) Develop the security approach concerning the storage of Consumer Data in Annex C What is the difference between SRCI payment and SRCI none payment Reject The specific method by which SRC Systems store consumer data is up to policies of SRC Programme. Acknowl edge Section 2.3.3 has been updated to describe the differences between the functions carried out by SRCI either frontend or backend capabilities. Payment corresponds to backend and non-payment corresponds to frontend only. An SRCI may support some or all of the functions. 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.7 9.6 0.7 9.1 The bullet list at the beginning of the 9.6 section indicates that Table 9.6.9 describes the Payload Response Content Type that "identifies the merchants (DSA) ability to support Payment Token information. the Payment Method Requested in the Payload on behalf of the DSA (indicates whether Token Data is Add additional description of the supported by the DSA)". However, the Payload Response Content Type (table Table 9.6.9 "SRC Payload Type 9.6.9) to clarify the link between the Indicator", indicates "the level of data merchant ability to support Payment Section 9 is intended to convey to be included in the payload" (full or Tokens and the possible values of the the data elements possible Table summary), which does not seem SRC Payload Type Indicator data within an interaction 9.6.9 Ed. related to Payment Tokenisation. element. Accept Table 9.1.3 indicates that the DCF Tokenisation Preference data element is used to indicate "if the DCF supports Payment Tokens". However, the specification does not describe how DCF use Payment Tokenisation. Maybe it is part of the "SRC Token Any SRC Participant including Request Data" element of the the DCF that plays the role of a Payment Response (Table 11.14), but Token Requestor will follow it is unclear since the specification Clarify the use of tokenisation by DCF Token Requirements as Table does not describe the content of this and relations with the SRC Token Acknowl specified in EMV Payment 9.1.3 Te. data element. Request Data data element. edge Tokenisation Specifications. 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted The SRC Digital Card Reference Identifier can identify a PAN or a Payment Token, as explained in Table 9.3.2. The fact that the SRC Digital Card Reference Identifier can also can also identify a Payment Token is unclear because the document often SRC Digital Card Reference 2d refers to the PAN only, for instance: Identifier refers to the Digital paragrap - Section 4.4, 2d paragraph, 2d Card which is associated with a h, 2d bullet point Modify the text to precise that the SRC Payment Card. bullet - Section 4.5, 5th paragraph, Digital Card Reference Identifier can Acknowl Payment Card may refer to the 0.7 4.4 point Ed. - Section 6.2.1, 3rd paragraph also be assigned to a Payment Token. edge PAN or Token. Associate would like to have EMVCo SRC Initiators choose the SRC consider the notion of an SRC initiator Systems they participate with having the ability to choose between during onboarding. Prior to card SRC systems associated with the card, Acknowl selection eligible SRC systems 0.6 General ge prior to selecting the SRC edge will be identified. The UX sketches show a "Guest Checkout" and an "SRC Checkout" Button on the DSA screen where the This should be avoided at all cost: The SRC Specification will not "SRC Mark" is to be shown. We’re not There SHALL be only one SRC Mark for define requirements for the too sure, but it seems that both Checkout. If consumer and device are number buttons a DSA, SRCI or buttons provide SRC functionality or not recognized, the consumer must be SRC System choose to enable. allow an unrecognized (guest) able to access their enrolled cards However, EMVCO will provide consumer to bind to the DSA to later (somehow) and the DSA must additional guidance on the use the SRC Checkout. (Not sure remember this Binding for later elements of SRC Trigger that whether we actually understood Checkouts. But providing two entry Acknowl can be incorporated into various 0.6 General te correctly.) points would be nothing but confusing. edge button type configurations. 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.6 General 0.6 General 0.6 General Considering that a consumer must first retrieve his enrolled card(s) in a DSA (which triggers card Accept in principle. Currently in authentication), the Checkout request the specification there is a that follows will likely ask for 3DS possibility of double authentication. However, the first Auth authentication. However, the will not generate an AAV, but only specification does not require prove "cardholdership". 3DS will Elaborate on the process of nor prevent the use of 3DS. Any require a second authentication step unrecognized consumer/device in a consideration resulting in double even if the actual auth method is the Checkout that requires 3DS or any other step up is a business policy same. How can this double auth be authentication method available to the established by the SRC te avoided? cardholder Accept programme It is not clear how an SRC PI can The specification is meant to be leverage its existing strong customer globally interoperable and is not authentication (as imposed by PSD2 intended for specific regions in Europe) for use when however the authenticating consumers in SRC. Unique considerations for Shouldn’t there be an interface from regional requirements are the the SRC System that can trigger such responsibility of the SRC an authentication on the Issuer side programme implementations when Assurance of consumer / Please provide an example that show and regional compliance is not te cardholder is needed? how this would be implemented. Reject detailed in the specification. The specification does not preclude the adding of a card The consumer should have a choice Please specify how a user can add an however the business policies of whether to be recognized or not or additional card or retrieve an already and requirements for such a of whether to use a card that was enrolled additional card when one or feature is implementation found or whether to add another one. multiple cards (candidate list) have been Acknowl specific. ed The specs don’t seem to cover this. found and are displayed already. edge 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. 3/14/2019 AXP Public

of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.6 General 0.6 General The EMVCo SRC framework and Specifications seem to ignore the existence of the co-badging model (card bearing several brands from different payment schemes). This model concerns hundreds of millions payment card across the world accepted under by millions of EMVCo Standardisation activities in The concept of co-badging is a merchants and these cards, the general and the SRC standard in business construct that is not merchants that accept them should be particular must take into account this globally interoperable across all able to benefit from the SRC reality by geographies. Therefore, it is not standards irrespective of the different TAKING INTO ACCOUNT AND defining described within the brands Co-badging Card in the Definition specification. However, the Otherwise the implementation of SRC chapter, incorporating this model in the specification does not preclude standards by market players could be SRC framework and specifying when support for geographical unique considered as obstacles to co- appropriate how these co-badging cards conditions. Such considers are badging that are prohibited by will be processed through SRC implementation and outside the European Card MIF regulation. standards. Reject remit of EMVCo. I need more clarity on how SRC and The specification 1.0 Draft has payment tokenisation and EMV 3DS Acknowl been updated to include more ge all work together edge clarity. 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. 3/14/2019 AXP Public

From a user experience perspective, when the user selects the SRC mark for payment, can they be presented with all available cards across all SRC programs? Or, will they select an SRC program and then be presented with cards only available from that program? Additionally, when adding a new card. Are all SRC programs made available to enroll new card?
Are merchants able to process a transaction via debit network when the consumer pays via a card linked to their debit account? This choice is available to merchants today. Tokenization in SRC may prevent this, and it is unclear if it’s still possible.
What is the user experience if the same card is available in multiple SRC programs? Will the user see the same card many times? Also, is there a "cap" on the number of cards the user could see across all programs?
Will users recognize the SRC mark? Or will it drive more traffic toward "disruptive" payments like PayPal and Alipay Acknowl edge The SRC Specification enables SRC Programmes and SRCI to enable card selection across all SRC Programmes. The SRC Specification enables any enrolled card from any available and participating SRC System to be selected during an SRC experience. Merchants will continue to process transactions as they do today. The SRC Specification enables the merchants to have the same level of information available today. When a Cardholder and SRCPI choose to enrol a single card to multiple SRC Systems that single card may be presented multiple times in the candidate list. There are no caps for cards in the specification. The SRC Mark will be presented to consumers at checkout. 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. 3/14/2019 AXP Public of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.6 2.6 0.6 3.1 0.6 4.2 SRC must be able to thwart attackers who pose malicious ‘Marks’ for cardholders to enter the PAN information, which customers would Please describe how SRC could ‘perceive’ secure due to trust mark. prevent spoofing and MITM attacks Please define compensating controls to Spoofing & phishing attacks for both SRC and non-SRC advise the cardholder it is a legitimate cannot be prevented by the 1 te implementations. SRC mark vs a fraudulent mark. Reject SRC specification. W3C specifications are outside Under W3C WebPayments, the DSA the scope and remit of EMVCO will be the browser: The text, "The as such any consideration SRC Programme defines would be implementation requirements for display, placement or specific. Please note the activation of the SRC Trigger.", would EMVCo SRC specification is only be enforceable under W3C intended with variety devices, should the browser (which implements Consider an Appendix to show how operating systems and the SRC trigger button) be part of the W3C WebPayments is expected to platforms 1 ge SRC programme. surface SRC implementations. Reject "SRC System maintains an enrolment service for payment cards." The SRC framework explained p12 that the SRC System is responsible for enrolling cardholders either directly or Is the word "directly" to be suppressed indirectly. from the framework? If not, it is The spec doesn’t define if and how a important to explain this in the spec (or The relevant framework content SRC System could directly enrol a where we can find it in the current spec has been incorporated in P 25 cardholder? if we missed this point) Accept Section 2 of 1.0 Draft. 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. 3/14/2019 AXP Public of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted The language has been updated in 1.0 Draft of the specification clarifies the The SRC Initiator interacts with Digital language describing the First sentence of 2d paragraph does Shopping Applications to select the relationship between DPA and 0.6 4.1.2 ed not seem to be correct appropriate the SRC System to:… Accept SRCI and SRC system Why does the SRC system create an The SRC Specification has "SRC Consumer Identity reference been updated in 1.0 Draft to value" rather than just the "Consumer clarify the distinction between Bullet Identifier"? Is there any case where consumer identifiers (e.g. email, "Consum the reference value can be used, but Could this be simplified by only having a phone number) and the e r the Consumer Identifier would not be Consumer Identifier rather than also a reference identifiers associated 0.6 5.5. Identity" te good enough? Consumer Identity reference value? Accept with each consumer identifier. What does replicate mean in the current context? (A copy is also a In the current version of the replication; the assumption however is SRC Specification 1.0 Draft, 1st para that it refers to "reproduction". If the section 5.5 (Binding) has been after meaning was "copied", use of cookies completely rewritten to clarify 0.6 5.5 bullets te/ed in Browsers would not be possible. Use "reproduced" instead of "replicated" Accept the terminology. Table 5.1 describes the Digital Card Personalization Data and the priority order of the digital card, though it is not a visible field for the customer to use and select. How will Priority order Section 3 for 1.0 draft describes of digital cards be managed by the recommendations for te - cardholders if they can’t view the Describe process for cardholders to management of the candidate 0.6 5.4.2 Table 5.1 MINOR field? manage priority order of digital cards. Accept list. 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. 3/14/2019 AXP Public of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.6 5.4.2 0.6 5.4.2 0.6 5.4.2 te + ed Card Brand is not defined while it is an ambiguous term. Only an example is provided (= Payment System brand name) and it does not refer to an SRC actor. Card Art is not defined. It is introduced as a pixelated version of a Payment Card which is ambiguous. The indication that it is a commonly referred term does not seem sufficient. "The image may be defined by the individual SRC PI level or a default by Payment System" Please define "Card Brand". Reject Please define ’Card Art’. Please rewrite this sentence (editorial correction + technical recommendation). Proposal: "The image should be defined by the individual SRC PI or by default by the SRC Programme" Accept Accept The SRC Specification has been updated in 1.0 Draft to remove the term "card brand" and the branding associated with a SRCPI enrolment is not dependent on the SRC specification. The SRC Specification has been updated in 1.0 Draft to define card art. The SRC Specification has been updated in 1.0 Draft for clarity. 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. 3/14/2019 AXP Public of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted 0.6 6.1 0.6 6.1 0.6 6.2 0.6 6.2 5 2nd sentence 1st paragrap h, 2nd sentence 2nd paragrap h, 1st sentence te – MAJOR Section 6.1 states, 5th paragraph states, "If the SRC System cannot recognise the Consumer, the SRC System will facilitate an Enrolment Request prior to completion of the SRC Checkout Event." However, as far as I can tell, the Enrolment section (5.4) makes no mention of a process for enrolling consumers. Other sections refer to creating a relationship between a payment card and a consumer identity or binding, but again no details on how the consumer identity is created. te/ed This is the only reference to "Consumer enrolment" while the normal reference is "Cardholder enrolment"; is there a difference? Why would this be a proprietary decision of the SRC program rather than a decision by each SRC PI so long as the DCF meets SRC Program requirements? Does the identification of a default DCF suggest a specific brand? Develop content on the consumer enrolment process. If there is no difference stay with "Cardholder enrolment" Accept Accept Acknowl edge Acknowl edge The referred section has been completely rewritten to clarify the terminology. The current version 1.0 Draft of the specification explains the enrolment process in section 5.4 The SRC Specification has been updated in 1.0 Draft to describe enrolment with more clarity on the role consumers and cardholders play. The SRC Specification (Section 7.2) has been removed in 1.0 Draft and additional clarity between DCF And enrolled cards has been added. The SRC Specification has been updated in 1.0 Draft to remove the suggestion that a DCF is associated with a specific brand. 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. 3/14/2019 AXP Public of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted Co-badging is not described "The SRC System MUST establish To be kept in mind: When a Payment within the specification since proprietary criteria that defines the Card is cobadged, the merchant there is no uniform global selection of a specific DCF". acceptance solution can also support interoperable approach as "The SRC System will evaluate both card brands. geographical differences exist. compatible brand acceptance based Can you explain how the principle of Implementations will need to on DSA configuration and Digital Card proprietary criteria could work with consider and describe how this 0.6 6.2 P 39 te Facilitator eligibility". cobadged Payment Cards? Reject use case would be supported. The description of the payload in section 7.4.4 and support of tokenization describes that a cryptogram will be The SRC Specification (Section provided by the TSP and delivered in 9) has been updated in 1.0 draft the payload if a token is requested. The to clarify the support for various following pages defining the payload types of dynamic data including data elements, descriptions and details token cryptograms. However, does not specify where the cryptogram storage of cryptograms is not te – Support for tokenization cryptogram in will be stored in the payload. If it is, it is contemplated or expected 0.6 7.4.4 MAJOR payload not called out directly and should be. Accept within the specification Change by: Value is interdependent on Accept in principle. The SRC whether the SRC Programme chooses Specification has been updated "Value is interdependent on whether to provide a PAN or Token in this field in 1.0 Draft to remove ambiguity P170 the SRC System chooses to provide a and on whether the ISO Block holder between PAN and Payment 0.6 12.1 Line 1 PAN or Token in this field" supports tokenisation Accept Token. 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. 3/14/2019 AXP Public of 32 Draft Specification & Bulletin Industry Feedback Form Secure Remote Commerce – Draft Specification v0.7, 0.6 October 2018 Dual/BA/T A/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, Acknowledge In progress) EMVCo Use Only EMVCo observations on each comment submitted Does the mention of "encryptedPayload" imply that there is message encryption on top (well, underneath) TLS encryption of the communication? What for? And if so, The entire API and Security why is "Card" in A.4 ( ) not sections of the SRC also encryptedCard? (After all it’s the Specification 1.0 draft have only place where a plain PAN is sent Please explain the reasoning behind been reworked to provide more 0.6 15_A.3 te across the system.) this. Accept clarity. Consider a notification API similar to The checkout API is a ‘one shot’ API. W3C WebPayments, such that total Therefore, it is expected that amount can be recalculated on notification are not received back from important events, see The payload information te – the SRC system on things such as https://www.w3.org/TR/paymentrequest/ includes the most recent 0.6 15_A.2.4 MAJOR shipping address changed. #onshippingaddresschange-attribute Reject information. 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. 3/14/2019 AXP Public of 32