EMVCo EVOP Use Case - Disposition of Comments

Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA — 1.2.2 Functions te of the LCM where Consu mer can: “Renew the MO contract certificate - An existing MO contract certificate for EV open payment, which is bound to the Payment Card, is renewed and is updated within the EV in its local storage” Does the renewal mean deletion of the existing MO contract certificate, creation of a new one, rebinding it with the SRC Profile and storing it into the car? Please enhance if comment is correct. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge SRC system to only use new one which will be store in the car. We have clarified this in the revised use case document. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 1 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EA — 1.2.3 Bullet te point 2 “Completes authentication, which may be passive (biometrics) or active (Consumer entry of pin, password etc) either on the EV console or via a dedicated app (e.g. authenticator app on the Consumer’s mobile device)” – Who is responsible for the authentication? Is the SRC System involved? Does the authenticator app (or EV console) need to provide an authentication proof via the ISO to the SRC System? We assume not. Please clarify “Consumer” is a defined entity in the SRC spec/world; in EVOP, it may make sense to specifically distinguish between the driver/EV owner/P&C wallet and the consumer in the SRC context; Acknowle dge EMVCo Use Only EMVCo observations on each comment submitted - Proof of authentication currently cannot be added via ISO and is not required - Authentication is by EV – SRC system is trusting existing authentication - Consumer is the entity enabling payments. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 2 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) EA — 2.1.1 te “Creates the MO Root CA public and private key pair” Proposed change We have an internal disagreement on whether or not the SRC System acts in the role of an MO. Pls explain. So, some of us interprets 2.1.1 as the SRC System being the MO in 2.1.1 and others think of an independent MO entity, like OEMs etc. The former suggest replacing the sentence “Creates …” with “Acts as a trusted certificate authority (CA) by owning the MO Root CA with the corresponding public and private keys. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge 2.1.1 describes existing Plug and Charge responsibilities without SRC system. Further language clarification has been updated 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 3 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) EA — 2.1.1 EA — 2.1.1 te “Creates the MO contract certificate” – does it create the MO contract certificate directly? Not in line with Figure E.1: ISO 15118 Public Key Infrastructure te New bullet point to support the 2.2.2 & Annex E ISO 15118 Public Key Infrastructure. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted “Facilitates creation of the MO contract certificate by enabling the intermediaries with the sub CA’s” Accept We have updated language Enables a 3-rd party entities (acting on behalf of the MO, e.g. Plug & Charge services) for creating MO contract certificate by issuing an intermediate signing certificate (MO Root Sub CA) to them. This MO Root Sub CA can be used for creating the MO contract certificate as well. Acknowle dge This is not required as MO role could be a 3rd party. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 4 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA — 2.1.1 ed “Ensures the provisioning of the MO Ensures the provisioning of the MO contract Accept Language modified contract certificate and the private key certificate and its private key to the to the designated EV” – the private designated EV key that is the counterpart of the MO contract certificate’s public key. EA — 2.1.1 ed “MO contract certificate provisioning to the Add the ‘the’ to the sentence EV is implementation-specific and is the responsibility of the Plug and Charge wallet service provider and the EV OEM.” Accept Language modified 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 5 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA — 2.2.2 Acknowle 1) Upto SRC system te “Add a Payment Card using the Card For case (3), if EVOP indeed creates a dge implementation on whether to Enrolment API. The SRC System separate SRC Profile just for the EVOP create a different profile or existing returns the Digital Card Identifier for use case (MOCC binding), we would SRC profile the enrolled card, which is included in the MO contract certificate” advise to change the SRC API to allow use cases like EVOP on a card level, Multiple ways to associate existing SRC profile to EV use case not only profile level. Question: (1) does the enrollment create a Binding will need to be unique to proper SRC Profile or does it enroll We think that this will future proof the SRC EV. the card in the so-called unbound protocol. Refer to SRC updated document for state? further clarity on profiles. (2) does the enrollment store all the Consumer identifiers like email/phone number in the SRC Profile (if one is created)? (3) General question: does EVOP enrollment mean that, even if the Consumer already has an SRC Profile with one or more cards, a 2) same as in SRC 3) No not usually. Upto SRC system but existing profile can be used. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 6 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change separate SRC Profile is always created for the EVOP use case? EA — 2.2.2 te “Bind an MO contract certificate for the EV Clarification needed to a given Digital Card using the Add Consumer Identities API” Add Consumer identity performs operations on SRC Profile level, not card level. It means that the whole profile (containing only one card) is bound with the MO contract certificate (as per SRC API spec 5.4.2). EA — 2.2.2 te “Delete MO contract certificates using the Delete Card API” – This option should not be allowed without previously unbinding the MOCC? Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge Language clarification added to incorporate device ID In EV context, binding is at card level as the contract for the EV is for specific card Acknowle dge Updated language to deletion of payment card with associated contract 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 7 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA — 3.1.2 Bullet te point 1 “The Consumer has been successfully authenticated, allowing access to the Plug and Charge wallet” Please refer to our comment further up under 1.2.3 about name choices for Consumer. Clarify and be more specific. Status (Accept, Reject, In progress) Acknowle dge EMVCo Use Only EMVCo observations on each comment submitted - Authentication is by EV – SRC system is trusting existing authentication 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 8 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA — 3.1.2/ Bullet te 3.1.3 point 2 / Figure 3.1 “The payment card has not previously been enrolled in the SRC System” – We assume that the binding should also be possible for existing cards in an SRC Profile. Please include this in the use case document. Technical: An SRC System may allow creation of a new digital card in “unbound” state regardless of whether there is already one (based on the same PAN) available and associated with an SRC Profile. Acknowle dge In our opinion, for this use case, it is important that the SRC System creates an “unbound” digital card that can later be added into a fresh new SRC Profile (together with the MO contract certificate and EV_ID) via the call Add Consumer Identities. Existing cards in SRC profile could be made available for the use case. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 9 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) EA — 3.1.3 Step 04 EA — 3.1.3 Step 06, Step 08 The created card is not associated with a SRC Profile (as no consumer identity is provided), so it is created in an “unbound” mode. The actual binding is performed on the SRC Profile which houses the digital card, not Payment Card as “Add Consumer Identities” binds a Device Identity to an SRC Profile (SRC API spec 5.4.2) Proposed change Enhance the description in the step. See our question (1) and (2). See above; this would need to be corrected at multiple locations within the doc. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge Consumer Identity is provided during enrolment. Acknowle dge Binding related language has been updated. Please also refer to updated SRC spec 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 10 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA — 3.2 Binding and unbinding are performed on a SRC Profile level; deletion is performed on card level. The EVOP use case document assumes that the SRC Profile always has only one card. Mention this as a fact/consequence of having this approach. EA — 3.2.3 Figure 3.2 ed Option 2: Binding Option 2: Unbinding EA — 3.3.3 Figure 3.3 te step 05 “Binding of the digitalCardId to the EV_ID” See above EV_ID is stored in the device identity, which is bound with the SRC Profile (not the digital card, again emphasize the fact the profile has only one digital card id). Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge Language changes to be done for Delete vs Unbind functions Accept Updated Acknowle dge Binding related language has been updated. Please also refer to updated SRC spec 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 11 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA — 3.3.3 Figure 3.3 te step 05 NOTE: Which methods are supported for an SRC System to perform additional authentication? We don’t see how the current SRC specification could support such a cardholder authentication. Provide clarification EA — 3.1.4 ed “EV EV” double word EA — Annex 2nd “Note:” ed There may be a ‘to’ missing in “Data B in objects in this Annex are related to before OCPP data objects schema”? B.1 Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Reject This would be implementation specific. Accept Accept Updated Updated 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 12 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA — ed We are no Plug & Charge (wallet) experts and are wondering whether an introductory section on typical P&C topics would be beneficial. Reject We refer you to applicable ISO documentation EA 1.2.3 te Completes authentication, which may be We have some doubts regarding MFA and Acknowle - Authentication is by EV – passive (biometrics) or active (Consumer how it can be practically implemented in a dge SRC system is trusting entry of pin, password etc) either on the EV console or via a dedicated app (e.g. PnC Flow as seemless as possible. After all, existing authentication a_u_t_h_e_n_t_i_c_a_t_o_r_ _a_p_p_ the simplicity of Plug & Charge lies in just _o_n_ _t_h_e_ _C_o_n_s_u_m_e_r_’s_ _m_o_b_i_l_e_ _d_e_v_i_c_e_)_ _ plugging in. Any conscious action required from the customer in that flow will lead to criticism from the involved parties. Ultimately, customers might see no benefit over just tapping their watch or phone to a reader. EA 1.2.3 te What is a “plug and charge wallet”? explain the emvco’s understanding of a Accept Language has been updated and „Plug & Charge wallet“, the first time you use of wallet has been removed. mention it here. Please refer to EVOP eMSP 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 13 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change EA Table 1.4 Ed EMAID E-Mobility Account Identifier (definition) EA 2.1.1 te the CSO not only needs to trust the MO Be more precise root, but also have contractual relationship (for billigen, i.e. roaming) with the eMSP issuing the eMAID of the contract cert. Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge Acknowle dge Updated Language reflects CSO and eMSP functions. Contractual relationship is different for EVOP solution and not required directly between eMSP and CSO 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 14 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted PU Add means that EV will know that EVOP is in -2 a VAS identifier could be used. In EVOPTF is continuing discussions available at this CS. Otherwise the EV will not know if this “PaymentService” is supported. In -2 only one Contract can be shown. But -20 would need something else, because serviceselection comes after Progress with JWG1 on updated changes in 200 for ISO 15118 authorization. Preferable use: -202 ESDP and add extension to advertise service before entering a protocol. Please circulate/discuss proposed changes regarding ISO 15118 with PT2 of JWG1 directly. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 15 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA 2.1.1, Figure 2.1 Major te Depending on the section/paragraph of the Could you please clarify if the Figure 2.1 Acknowle Updated document to clarify the 3.2.1, document it is indicated that the 'MO PKI should be corrected so that the 'MO PKI dge role for both MO PKI SP a 3.3.1 and Service Provider' operates the 'SRC MO Service Provider' is represented as a sub- Annex E Root CA' (e.g. in section 2.1.1) or that the entity of the SRC System or if sections 3.1.1, 'SRC System' acts as the MO Root 3.2.1, 3.3.1 and Annex E should be Certificate (e.g. in sections 3.1.1, 3.2.1, corrected to indicate that "the SRC System 3.3.1, Annex E) ; while in Figure 2.1 the is responsible of the 'MO Root CA' operated 'MO PKI Service Provider' and the 'SRC by the 'MO PKI Service Provider' ? System' are represented as 2 distinct entities. EA Annexe C.1 Minor te In section C.1, it is indicated that the “Organization field contains the SRC System (which is the issuer of the MO root certificate)", while in the ‘Mobility Operator Leaf Cetitificate Table’, the example of Could you please clarify is which case are several URIs listed in this field? Acknowle dge It is for use cases where multiple SRC systems are associated with the digital card such as Cobadge cards value for this field lists 2 URIs (= ). 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 16 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA — Fig 2.1 ge It is hard to understand the flow in this figure. E.g. all the green arrows indicate circular flows. Which Is confusing. There should be added numbers or letters to indicate where to start and end. Like the FIG 2.1 in the “old” version of the document. Acknowle dge Figure has been updated to better clarify EA — 3.2 Acknowle ge For LCM, it is supposed to unbind and State somewhere that this issue should be dge LCM related language is updated to delete cards. If this is not done addressed in some terms and clarify between unbind and correctly the card is used for charging conditions in the agreement between delete fx. after the car has been sold, who participants will be responsible for transactions which have been performed without Authentication (Frictionless) 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 17 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted PU — 2.1 Section 2.1 suggests that the SRC system GE issues contract certificates and then later says that the MO PKI SP does this. Which is it or can it be both? Neither of these flows are shown on Fig 2.1, can this be clarified? Accept Figure has been clarified and the responsibilities is better documented Acknowle PU — 3.3.3 Fig 3.3 GE The sequence shows charging taking Could the diagrams be updated to show this dge Updated document reflects place before authorization. I believe it sequence? authorization / pre- is more normal to authorize the card authorization information before allowing charging to start and then send an advice with the final amount once charging finishes. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 18 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted PU Annex C C.1 teMA JO R The Subject DN fields (CN, O, OU, L, ST, C) must not be used to store device metadata or implementation-specific identifiers. Per RFC 5280 and its updates, these attributes have defined semantic meaning and are intended for human-readable identity, not machine-readable metadata. Using them for arbitrary values introduces interoperability issues, breaks relyingparty validation logic, and creates long-term compatibility risks. For this use case, metadata should instead be encoded within the Subject Alternative Name (SAN) extension— preferably using otherName with a welldefined ASN.1 structure—or included as non-critical custom extensions identified by an OID. There is no indication in the ISO 15118 standards that prohibits the inclusion of additional non-critical custom extensions, and doing so maintains interoperability while keeping certificate identity fields standards-compliant. Acknowle dge We continue to seek feedback on the utilization of the fields mentioned. Based on current feedback and initial testing, the current documentation can be implemented. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 19 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) EA — 3.3 3.3 EA — 3.3 3.3 In the flow & the steps text. It’s unclear if ge the pre-auth is always required. It appears to be optional. Without a pre-auth and only a completion message, if the transaction is declined, there is no recourse. The charge has been completed and can’t be taken back. ge Along the same lines as above, there appears to be no recourse for additional, incremental auths. Some retailers sell EV charging under occupying a parking space. If a vehicle is left unattended (something happens and they do not return to car), there needs to be additional authorization for additional $$. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge Updated document highlights getting approval before charging Acknowle dge The scope of this solution is for enabling card based payments within the ISO 15118 plug and charge. Incremental auths will be handled by CSO as per its requirements and is outside the scope of this solution 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 20 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) EA — EA — It’s not clear how timely the “Payment ge Notification” will be. The way these things work today, it might be a daily summary. We’d like the notification to >the store< to be real-time, so that we can align the reporting of events, i.e. the merchant needs to know the transaction details of an EV charge on their site is real time. The lack of ability to collect user data for ge fleet, loyalty and the exclusion of offering promos is a concern to retailers. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge Payment Notification is a real time API call to consumer. If this question for notifying the merchant, we would need some more additional information. Notification from CSMS to forecourt or other entities is outside EMVCo scope Acknowle dge We have added custom data fields for allowing additional data in contract 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 21 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) EA — The ability to add additional goods & ge services to the transaction needs to be considered. Ex. Car wash, or mobile order goods from inside to be collected with one payment transaction. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge The scope for this document is interaction EV charger to EV. Forecourt system to CSMS is outside scope 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 22 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 EA - - ge Comment (justification for change) Hello, thanks a lot for taking into account the review comments that we provided on the DRAFT versions of the EMV SRC EVOP Use Case v1.0. We are particularly pleased that the latest changes applied to this guide provide clarifications regarding the use of co-badged cards during the EMV SRC EVOP flows. And we confirm the need to continue improving the co-badging coverage in future EMV SRC specifications and guides (in order to guarantee C2P UX flows as close as possible to that of F2F/in-store payments, and ensure fair treatment of co-badged brands). Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge We are continuing to evolve EV use case document and overall SRC documentation for co-badging 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 23 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted EA - - ge Rationale This specification represents a significant advancement in EV charging payments by bridging payment card networks with charging infrastructure. The standards- based approach provides a solid technical foundation for addressing a real market need. Critical Success Conditions - Phased Rollout: Begin with pilot markets before global deployment - Interoperability Testing: Extensive testing across OEM/charging operator/payment network combinations - Fallback Mechanisms: Define clear procedures for system failures or certificate issues - Privacy In progress We are building more detailed requirements and evaluating detailed testing needs for the success of the EV use case. We will be releasing documentation around testing requirements in the future 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 24 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Framework: Develop transparent data handling and retention policies - Certification Program: Establish EMVCo certification for participants - Monitoring Framework: Real-time tracking of authentication success rates and transaction failures - Regional Adaptation: Create implementation guides for different regulatory environments Bottom Line The specification is technically sound and addresses genuine market friction. Success depends on coordinated industry execution, systematic resolution of implementation challenges, and strong commitment from all ecosystem participants (OEMs, 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 25 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 EA ge Comment (justification for change) payment networks, charging operators). The consumer convenience and market expansion benefits outweigh the complexity concerns, provided the conditions above are met Two typos/errors found: 1.1 "anISO" and 3.2 still mentions the "Plug and Charge wallet". The authentication use case needs to be addressed next, also in the EU / PSD2 context. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge Authentication is by EV and we will continue to evaluate based on latest requirements 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 26 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 EA ge Comment (justification for change) We support approval of the EVOP Use Case as a practical, adaptable foundation for industry deployment. EMVCo’s existing security working group should continue monitoring emerging threats, particularly quantum computing and AI driven attack vectors, and the Use Case’s security posture should be revisited and updated as needed to remain resilient and interoperable. In addition, the working group should evaluate cross domain standards for EV chargers and vehicles as they relate to the open payments infrastructure and assess evolving Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted Acknowle dge We continue to evaluate other standards specific to the domain and have been setting up liaisons as per required collaboration. Overall EMVCo will continue to evaluate AI and quantum impact to all EMV technologies and make updates accordingly. 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 27 of 28 Internal Draft Specification & Bulletin Industry Feedback Form Company Name: Consolidation of all Comments Primary Contact Name: Working Group or Task Force: EVOPTF Document: EVOP Use Case Document v1.0 Date: March 2026 EA/Sub1 Clause No./ Subclause No. /Annex) Paragraph/ Figure/Tabl e/Note Type of comment2 Comment (justification for change) end to end risks across the payment and device domains. Proposed change Status (Accept, Reject, In progress) EMVCo Use Only EMVCo observations on each comment submitted 1 EA/Sub = EMVCo Associate or Subscriber company (enter a 2-3 letter abbreviation for commenting) 2 Type of comment: ge = general te = technical ed = editorial – For technical comments, please indicate whether your comment is a MAJOR or MINOR technical comment. Completed form should be forwarded to the appropriate Working Group or Task Force. Click on: https://www.emvco.com/contact/ to submit feedback. 26-Mar-2026 Page 28 of 28 Internal