SIST EN ISO 15118-20:2022/oprA1:2025

Road vehicles - Vehicle to grid communication interface - Part 20: 2nd generation network layer and application layer requirements - Amendment 1: AC DER service, MCS service, and improved security concept (ISO 15118-20:2022/DAmd1:2024)

Straßenfahrzeuge - Kommunikationsschnittstelle zwischen Fahrzeug und Ladestation - Teil 20: Anforderungen der 2. Generation an das Netzwerk- und Anwendungsprotokoll - Ergänzung 1 (ISO 15118-20:2022/DAmd 1:2024)

Véhicules routiers - Interface de communication entre véhicule et réseau électrique - Partie 20: Exigences des couches réseau et application de 2ème génération - Amendement 1: Titre manque (ISO 15118-20:2022/DAmd1:2024)

Cestna vozila - Komunikacijski vmesnik med vozilom in omrežjem - 20. del: Zahteve za omrežno in aplikacijsko plast druge generacije - Dopolnilo A1 (ISO 15118-20:2022/DAmd1:2024)

General Information

• Status: Not Published
• Public Enquiry End Date: 27-Feb-2025
• ICS: 35.100.05 - Multilayer applications
• ICS: 43.040.15 - Car informatics. On board computer systems
• ICS: 43.120 - Electric road vehicles
• Technical Committee: CEV - Electric passenger and commercial vehicles
• Current Stage: 4020 - Public enquire (PE) (Adopted Project)
• Start Date: 19-Dec-2024
• Due Date: 08-May-2025
• Completion Date: 03-Mar-2025
• Directive: 2023/1804 - Regulation (EU) 2023/1804 of the European Parliament and of the Council of 13 September 2023 on the deployment of alternative fuels infrastructure, and repealing Directive 2014/94/EU
• Directive: 2023/1804-1 - Regulation (EU) 2023/1804 of the European Parliament and of the Council of 13 September 2023 on the deployment of alternative fuels infrastructure, and repealing Directive 2014/94/EU
• Mandate: M/581 - Standardisation Request as regards communication exchange, electricity, and hydrogen supply for road, maritime transport and inland navigation in support of Directive 2014/94/EU and its planned revision under the ‘Fit for 55’package
• Ref Project: EN ISO 15118-20:2022/prA1:2024 - Road vehicles - Vehicle to grid communication interface - Part 20: 2nd generation network layer and application layer requirements - Amendment 1: AC DER service, MCS service, and improved security concept (ISO 15118-20:2022/DAmd1:2024)

Relations

• Amends: SIST EN ISO 15118-20:2022 - Road vehicles - Vehicle to grid communication interface - Part 20: 2nd generation network layer and application layer requirements (ISO 15118-20:2022)
• Effective Date: 11-Oct-2023

Overview

SIST EN ISO 15118-20:2022/oprA1:2025 is a key amendment to the international standard for the vehicle-to-grid (V2G) communication interface, focusing on the 2nd generation network layer and application layer requirements. This Amendment 1 introduces significant updates including the integration of the AC Distributed Energy Resource (DER) service, the Megawatt Charging System (MCS) service, and enhanced security concepts to improve vehicle-grid interoperability and safety.

Developed under the ISO/TC 22/SC 31 committee and maintained in collaboration with the International Electrotechnical Commission (IEC), this standard plays a vital role in defining how electric vehicles (EVs) and electric power systems communicate and interact securely, enabling efficient energy exchange and smart charging strategies.

Key Topics

• AC DER Service
  This service standardizes the communication and operational requirements for distributed energy resources connected via alternating current. It supports EVs acting as energy providers or consumers in energy systems, facilitating bidirectional power flow and grid support functionalities.

• Megawatt Charging System (MCS) Service
  MCS is designed for ultra-fast charging applications with power levels in the megawatt range. This amendment clarifies network and application layer needs for integrating MCS into the existing V2G communication framework, ensuring scalable and reliable high-power charging infrastructure.

• Improved Security Concept
  Security enhancements include rigorous certificate validation rules, optimized certificate sizes for embedded systems, and robust online certificate status protocols such as OCSP (Online Certificate Status Protocol). Updated trust anchor management and certificate chain requirements reinforce the integrity and confidentiality of V2G communications.

• New Terms and Definitions
  The amendment introduces important technical concepts such as:

  • Charge Enable State (CE state)
  • Cease to Energize
  • Distributed Energy Resource (DER)
  • Frequency Droop Curve
  • Ride-through capabilities
  • Levels 1 and 2 Charging definitions
    These terms standardize communication, ensuring clarity and alignment between EVs and electric grids.

• Certificate and Cryptographic Updates
  Detailed guidelines on certificate usage, size constraints (≤ 1600 bytes recommended to accommodate embedded systems), and certificate chain structures ensure compatibility and security for digital signatures and authentication in V2G communications.

Applications

• Smart Charging Infrastructure
  Standardization of AC DER and MCS services enhances the deployment of EV chargers integrated with renewable energy sources, enabling grid-supportive charging strategies such as peak shaving and load balancing.

• Grid Stability and Energy Management
  EVs acting as distributed energy resources can provide frequency regulation, voltage support, and demand response services, improving overall grid resilience and facilitating the integration of intermittent renewable energies.

• Ultra-Fast Charging Stations
  The MCS service specifications cater to future-proofing charging stations that support very high power delivery, essential for commercial EV fleets and long-distance travel infrastructure.

• Secure V2G Communications
  Strengthened security protocols protect against unauthorized access and data tampering, crucial for maintaining trust and reliability in vehicle-grid interactions.

• Regulatory Compliance and Standard Adoption
  Facilitates harmonized implementation benefiting automakers, charging station manufacturers, utility operators, and regulators aiming to promote interoperable and secure EV infrastructure.

Related Standards

• ISO 15118 Series
  Other parts of the ISO 15118 series cover physical and data link layers, message formats, and use cases essential for the complete V2G ecosystem.

  • ISO 15118-10: Physical layer and data link layer requirements for single-pair Ethernet, referenced in this amendment.

• IEC 61851-23-3
  Electrical power and energy transfer standards relevant to electrically propelled road vehicles and industrial trucks, especially for MCS and AC DER services.

• X.509 and PKI Standards
  For certificate management, validation, and public key infrastructure (PKI) used in secure communications within V2G frameworks.

---

Keywords: Vehicle to grid communication, EN ISO 15118-20, AC DER service, Megawatt Charging System, MCS, security concept, certificate validation, electric vehicles, smart charging, V2G protocol, grid stability, IEC 61851, distributed energy resource, EV charging standards.

Standards Content (Sample)

SLOVENSKI STANDARD
01-februar-2025
Cestna vozila - Komunikacijski vmesnik med vozilom in omrežjem - 20. del:
Zahteve za omrežno in aplikacijsko plast druge generacije - Dopolnilo A1 (ISO
15118-20:2022/DAmd1:2024)
Road vehicles - Vehicle to grid communication interface - Part 20: 2nd generation
network layer and application layer requirements - Amendment 1: AC DER service, MCS
service, and improved security concept (ISO 15118-20:2022/DAmd1:2024)
Straßenfahrzeuge - Kommunikationsschnittstelle zwischen Fahrzeug und Ladestation -
Teil 20: Anforderungen der 2. Generation an das Netzwerk- und Anwendungsprotokoll -
Ergänzung 1 (ISO 15118-20:2022/DAmd 1:2024)
Véhicules routiers - Interface de communication entre véhicule et réseau électrique -
Partie 20: Exigences des couches réseau et application de 2ème génération -
Amendement 1: Titre manque (ISO 15118-20:2022/DAmd1:2024)
Ta slovenski standard je istoveten z: EN ISO 15118-20:2022/prA1:2024
ICS:
35.100.05 Večslojne uporabniške Multilayer applications
rešitve
43.040.15 Avtomobilska informatika. Car informatics. On board
Vgrajeni računalniški sistemi computer systems
2003-01.Slovenski inštitut za standardizacijo. Razmnoževanje celote ali delov tega standarda ni dovoljeno.

DRAFT
Amendment
ISO 15118-20:2022/
DAM 1
ISO/TC 22/SC 31
Road vehicles — Vehicle to grid
Secretariat: DIN
communication interface —
Voting begins on:
Part 20:
2024-12-13
2nd generation network layer and
Voting terminates on:
application layer requirements 2025-03-07
AMENDMENT 1: AC DER service, MCS
service, and improved security concept
ICS: 43.120
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
BE CONSIDERED IN THE LIGHT OF THEIR
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
NATIONAL REGULATIONS.
RECIPIENTS OF THIS DRAFT ARE INVITED
TO SUBMIT, WITH THEIR COMMENTS,
NOTIFICATION OF ANY RELEVANT PATENT
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Reference number
ISO 15118-20:2022/DAM 1:2024(en)

DRAFT
ISO 15118-20:2022/DAM 1:2024(en)
Amendment
ISO 15118-20:2022/
DAM 1
ISO/TC 22/SC 31
Road vehicles — Vehicle to grid
Secretariat: DIN
communication interface —
Voting begins on:
Part 20:
2nd generation network layer and
Voting terminates on:
application layer requirements
AMENDMENT 1: AC DER service, MCS
service, and improved security concept
ICS: 43.120
THIS DOCUMENT IS A DRAFT CIRCULATED
FOR COMMENTS AND APPROVAL. IT
IS THEREFORE SUBJECT TO CHANGE
AND MAY NOT BE REFERRED TO AS AN
INTERNATIONAL STANDARD UNTIL
PUBLISHED AS SUCH.
This document is circulated as received from the committee secretariat.
IN ADDITION TO THEIR EVALUATION AS
BEING ACCEPTABLE FOR INDUSTRIAL,
© ISO 2024
TECHNOLOGICAL, COMMERCIAL AND
USER PURPOSES, DRAFT INTERNATIONAL
All rights reserved. Unless otherwise specified, or required in the context of its implementation, no part of this publication may
STANDARDS MAY ON OCCASION HAVE TO
ISO/CEN PARALLEL PROCESSING
be reproduced or utilized otherwise in any form or by any means, electronic or mechanical, including photocopying, or posting on
BE CONSIDERED IN THE LIGHT OF THEIR
the internet or an intranet, without prior written permission. Permission can be requested from either ISO at the address below
POTENTIAL TO BECOME STANDARDS TO
WHICH REFERENCE MAY BE MADE IN
or ISO’s member body in the country of the requester.
NATIONAL REGULATIONS.
ISO copyright office
RECIPIENTS OF THIS DRAFT ARE INVITED
CP 401 • Ch. de Blandonnet 8
TO SUBMIT, WITH THEIR COMMENTS,
CH-1214 Vernier, Geneva
NOTIFICATION OF ANY RELEVANT PATENT
Phone: [phone]
RIGHTS OF WHICH THEY ARE AWARE AND TO
PROVIDE SUPPORTING DOCUMENTATION.
Email: [e-mail]
Website: www.iso.org
Published in Switzerland Reference number
ISO 15118-20:2022/DAM 1:2024(en)

ii
ISO 15118-20:2022/DAM 1:2024(en)
Foreword
ISO (the International Organization for Standardization) is a worldwide federation of national standards
bodies (ISO member bodies). The work of preparing International Standards is normally carried out through
ISO technical committees. Each member body interested in a subject for which a technical committee
has been established has the right to be represented on that committee. International organizations,
governmental and non-governmental, in liaison with ISO, also take part in the work. ISO collaborates closely
with the International Electrotechnical Commission (IEC) on all matters of electrotechnical standardization.
The procedures used to develop this document and those intended for its further maintenance are described
in the ISO/IEC Directives, Part 1. In particular, the different approval criteria needed for the different types
of ISO documents should be noted. This document was drafted in accordance with the editorial rules of the
ISO/IEC Directives, Part 2 (see www.iso.org/directives).
Attention is drawn to the possibility that some of the elements of this document may be the subject of patent
rights. ISO shall not be held responsible for identifying any or all such patent rights. Details of any patent
rights identified during the development of the document will be in the Introduction and/or on the ISO list of
patent declarations received (see www.iso.org/patents).
Any trade name used in this document is information given for the convenience of users and does not
constitute an endorsement.
For an explanation of the voluntary nature of standards, the meaning of ISO specific terms and expressions
related to conformity assessment, as well as information about ISO's adherence to the World Trade
Organization (WTO) principles in the Technical Barriers to Trade (TBT), see www.iso.org/iso/foreword.html.
This document was prepared by Technical Committee ISO/TC 22, Road vehicles, Subcommittee SC 31, Data
communication.
A list of all parts in the ISO 15118 series can be found on the ISO website.
Any feedback or questions on this document should be directed to the user’s national standards body. A
complete listing of these bodies can be found at www.iso.org/members.html.

iii
ISO 15118-20:2022/DAM 1:2024(en)
Road vehicles — Vehicle to grid communication interface —
Part 20:
2nd generation network layer and application layer
requirements
AMENDMENT 1: AC DER service, MCS service, and improved
security concept
Clause 2
Add the following references at the end of this clause:
ISO 15118-10:202X, Road vehicles – Vehicle-to-grid communication interface – Part 10: Physical layer and data
link layer requirements for single-pair Ethernet.
IEC 61851-23-3:202X, Electrical power/energy transfer systems for electrically propelled road vehicles and
industrial trucks.
Clause 3
Add the following terms and definitions at the end of this clause:
3.72
charge enable state
CE state
state according to the charge enable function defined in IEC 61851-23-3
3.73
megawatt charging system
MCS
charging system according to IEC 61851-23-3
3.74
cease to energize
cessation of active power delivery under steady-state and transient conditions and limitation of reactive
power exchange
Note 1 to entry: After the cessation is over, the EV is allowed to return immediately into service without following the
enter service rules.
3.75
distributed energy resource
DER
source of electric power that is not directly connected to a bulk power system.
EXAMPLE Generators and energy storage technologies capable of exporting active power to the electrical grid.
Note 1 to entry: An interconnection system or a supplemental DER device that is necessary for compliance with this
document is part of a DER.
ISO 15118-20:2022/DAM 1:2024(en)
3.76
enter service
set of parameters that defines how to start energizing or re-energizing the electric power system
Note 1 to entry: If voltage and frequency values are not within the desired range, the DER will not be allowed to start
injecting power to the grid/electric power system.
3.77
frequency droop curve
parameterized curve of the frequency-watt function
Note 1 to entry: The parameters include a frequency dB (dead band) and a unitless factor k which defines the rate
of power output change due to the frequency change. This operation limits active power generation or consumption
when the line frequency deviates from nominal by a specified amount.
3.78
level 1 charging
charging with a maximum power between 1 kW and 1,8 kW, via a standard 120 Vrms AC single phase outlet
Note 1 to entry: This power limit is only applicable in the US.
3.79
level 2 charging
charging with a maximum power between 3 kW and 22 kW, via a dedicated AC charger
Note 1 to entry: In the US the voltage supplied is typically 240 Vrms AC whereas in Europe is 230 Vrms AC.
3.80
may trip region
region of voltage or frequency within which the EV is allowed to cease to energize and to trip the connection
Note 1 to entry: The region is defined by a piecewise linear curve demarcating the boundary for voltage or frequency.
3.81
momentary cessation region
region of voltage or frequency within which the EV will temporarily cease to energize (inject power to) an
electric power system in response to a disturbance of the applicable voltages or the system frequency
Note 1 to entry: When entering this region, the EV will retain the capability of immediate restoration of the output of
operation when the applicable voltages and the system frequency return to within the defined ranges.
Note 2 to entry: The region is defined by a piecewise linear curve demarcating the boundary for voltage or frequency.
3.82
must trip region
region of voltage or frequency within which the EV must cease to energize and must trip the connection
Note 1 to entry: The region is defined by a piecewise linear curve demarcating the boundary for voltage or frequency.
3.83
open loop response time
time to ramp up to 90 % of the new target in response to the step change of the control input signal
3.84
over-excited excitation type
excitation type, where a DER injects/supplies reactive power to the system
Note 1 to entry: An over-excited DER injects/supplies reactive power to the system. The term is usually associated
with synchronous machines (motors or generators). In generator sign convention, an over-excited DER has its current
lagging the voltage (reactive power > 0) and the reactive power injection tends to increase the system voltage.
3.85
permit service
setting that indicates whether a DER is allowed to enter or remain in service

ISO 15118-20:2022/DAM 1:2024(en)
3.86
return to service
enter service following recovery from a trip
3.87
ride-through
ability to withstand voltage or frequency disturbances inside defined limits and to continue operating as
specified
3.88
trip
inhibition of immediate return to service
Note 1 to entry: Once the DER has permission to come back to service, it must follow the enter service rules.
3.89
under-excited excitation type
excitation type, where a DER absorbs/consumes reactive power from the system
Note 1 to entry: An under-excited DER absorbs/consumes reactive power from the system. The term is usually
associated with synchronous machines (motors or generators). In generator sign convention, an under-excited DER
has its current leading the voltage (reactive power < 0) and the reactive power absorption tends to decrease the
system voltage.
Clause 6
Replace Figure 2 with this figure:

ISO 15118-20:2022/DAM 1:2024(en)
Figure 2 — Vehicle to grid communication document overview

Clause 7.3.2
Replace Table 2 with this table:

ISO 15118-20:2022/DAM 1:2024(en)
Table 2 — Certificate extension examples
Certificate extensions Description
Usage of the corresponding private key (e.g. Digital Signature, non-repudia-
Key usage
tion, key encipherment, …)
Further specification of key usage using OIDs, e.g.:
— server authentication (1.3.6.1.5.5.7.3.1)

— client authentication (1.3.6.1.5.5.7.3.2)
NOTE Sometimes the following values are encoded here:
— Netscape SGC (1.3.6.1.4.1.311.10.3.3)
Extended Key Usage
— Microsoft SGC (2.16.840.1.113730.4.1)
SGC stands for server gated crypto and indicates that the
server can also use strong cryptography for the connection
with the client’s browser. This extension was used at the time
of strong crypto export control to enable financial web site to
provide appropriate protection of the data transfer.
CRL distribution point Location to retrieve certificate revocation lists
OCSP Location to retrieve OCSP. Refer to IETF RFC 6960 as updated by
IETF RFC 8954 for details.
Authority information Additional authorization information
Subject alternative name Alternative names of the entity
Basic constraint = CA True if the certificate is a root certificate or a Sub-CA certificate.
Subject information Additional information about the subject
Add the following new paragraph below NOTE 14 to requirement [V2G20-1234]:
In this document, the size of certificate is less than or equal to 1600 bytes. This limit considers resource
constraints in embedded systems and complying secondary actors must be aware of this when they generate
certificates. For example, it is recommended to be cautious when adding long URLs, 4-byte characters
in distinguished names, or multiple certificate policies as these may increase the size of the certificate
significantly. It can be necessary to use only one, either CRLDistributionPoints or AuthorityInfoAccess, and
not both, if including both makes the certificate larger than 1600 bytes.
Replace requirement [V2G20-1004] with the following new requirements and NOTE:
[V2G20-3000] The relying parties shall ensure that the certificates are valid exclusively within the
validity of their issuer's certificate.
NOTE 15 The CA is expected to only issue certificates that are valid exclusively within the validity of its own
certificate.
[V2G20-3001] While validating certificates, EVCC and SECC shall ensure that [V2G20-3000] is fulfilled.
Replace first bullet point in NOTE 20 (old numbering) with:
NOTE 20 […].
— The content of the leaf certificate has not been altered after issue. This means it is possible to check and
confirm the signature up to the trust anchor level and thus the integrity of the signed content.
— […].
Renumber old NOTE 15 and following notes, starting with number 16.

Clause 7.3.2.1
ISO 15118-20:2022/DAM 1:2024(en)
Replace requirement [V2G20-2327] and NOTE 3 with:
[V2G20-3002] OCSP signer certificate used to sign the OCSP response for SECC certificate status shall be
generated using a certificate chain that either uses the same V2G Root CA certificate as
the trust anchor as the SECC certificate whose status is being checked or uses one of the
V2G Root CA certificates, as the trust anchor, whose DN was included by the EVCC in the
“certificate_authorities” extension sent by the EVCC in the “ClientHello” message. Refer to
Figure 5 for a pictorial representation. Refer to Annex H for further details. Refer to H.1.6
for examples of certificate structure. Refer to Annex B for details of the certificate profile.
NOTE 3 This document does not mandate usage of a particular V2G Root CA. In case multiple V2G Root CAs are
available in a region, a good practice would be that the OCSP signer certificate that signs the OCSP response for the
SECC certificate (or the sub-CA certificate(s) in the SECC certificate chain) chains up to the same V2G Root CA that
signs the SECC certificate chain that the SECC is transmitting to the EVCC for this particular TLS handshake. This is
however out of scope of this document.
Replace requirements [V2G20-2330] and [V2G20-2332] with:
[V2G20-3003] OCSP signer certificate used to sign the OCSP response for contract certificate status shall
be generated using a certificate chain that uses either the same eMSP Root CA certificate
or the same V2G Root CA certificate as the trust anchor as the contract certificate whose
status is being checked. Refer to Figure 6 for a pictorial representation. Refer to Annex H
for further details. Refer to H.1.6 for examples of certificate structure. Refer to Annex B
for details of the certificate profile.
[V2G20-3004] OCSP signer certificate used to sign the OCSP response for vehicle certificate status shall
be generated using a certificate chain that uses either the same OEM Root CA certificate
or the same V2G Root CA certificate as the trust anchor as the vehicle certificate whose
status is being checked. Refer to Figure 7 for a pictorial representation. Refer to Annex H
for further details. Refer to H.1.6 for examples of certificate structure. Refer to Annex B
for details of the certificate profile.
Replace NOTE 10 with:
NOTE 10 This document does not mandate usage of a particular V2G Root CA. In case multiple V2G Root CAs are
available in a region, a good practice would be that the OCSP signer certificate that signs the OCSP response for the
vehicle certificate (or the sub-CA certificate(s) in the vehicle certificate chain) chains up to the same V2G Root CA that
signs the vehicle certificate chain whose status is being checked. This is however out of scope of this document.
Replace requirement [V2G20-2334] and NOTE 12 with:
[V2G20-3005] OCSP signer certificate used to sign the OCSP response for OEM provisioning certificate
status shall be generated using a certificate chain that uses either the same OEM Root CA
certificate or the same V2G Root CA certificate as the trust anchor as the OEM provisioning
certificate whose status is being checked. Refer to Figure 7 for a pictorial representation.
Refer to Annex H for further details. Refer to H.1.6 for examples of certificate structure.
Refer to Annex B for details of the certificate profile.
NOTE 12 This document does not mandate usage of a particular V2G Root CA. In case multiple V2G Root CAs are
available in a region, a good practice would be that the OCSP signer certificate that signs the OCSP response for the
OEM provisioning certificate (or the sub-CA certificate(s) in the OEM provisioning certificate chain) chains up to the
same V2G Root CA that signs the OEM provisioning certificate chain whose status is being checked. This is however
out of scope of this document.

Clause 7.3.4
Delete the following requirements: [V2G20-1235] and [V2G20-2646].

ISO 15118-20:2022/DAM 1:2024(en)
Clause 7.4
Add the following new requirements and note at the end of this clause (below Figure 9):
[V2G20-3006] [MCS] In case of MCS and MCS_BPT: If the EVCC sent the message SessionStopReq with
parameter ChargingSession equal to "Pause" it shall pause the Data-Link (D-LINK_
PAUSE.request()) after receiving the message SessionStopRes with ResponseCode
set to "OK" and follow the sleep and wake-up requirements defined in ISO 15118-
10:202X, 7.6.
[V2G20-3007] [MCS] In case of MCS and MCS_BPT: If the SECC received the message SessionStopReq
with parameter ChargingSession equal to "Pause" it shall pause the Data-Link
(D-LINK_PAUSE.request()) after sending the message SessionStopRes with Re-
sponseCode set to "OK" and follow the sleep and wake-up requirements defined in
ISO 15118-10:202X, 7.6.
NOTE 3 Requirements [V2G20-1227] and [V2G20-1777] are not applicable for MCS and MCS_BPT.

Clause 7.5
Replace second sentence of the first paragraph with:
ISO 15118-3, ISO 15118-8, and ISO 15118-10 define additional details on data link layer to be covered.
Add the following new requirement above subclause 7.5.1:
[V2G20-3008] [MCS] If a V2G entity communicates by 10BASE-T1S, the V2G entity shall comply with
ISO 15118-10.
Clause 7.5.1.2
Replace Figure 10 with this figure:

ISO 15118-20:2022/DAM 1:2024(en)
Key
1 App layer communication protocol
2 IEEE 802.1X communication protocol
Figure 10 — IEEE 802.1X example with backend authentication for WPT
Add the following new NOTE after NOTE 8 below [V2G20-2368]:
NOTE 9 Although this requirement specifies using RDNs from Issuer field of the root certificates, per IETF RFC
5280, 4.1.2.4 (as updated by IETF RFC 6818, IETF RFC 8398 and IETF RFC 8399) for root certificates these RDNs
should be the same between the Issuer field and the Subject field.
Delete the following requirement: [V2G20-2371]
Replace NOTE 21 below [V2G20-1008] with:
NOTE 21 As defined in IETF RFC 6960 (as updated by IETF RFC 8954), an OCSP responder might either be the Sub-
CA itself, or it might be an entity which is directly signed by the corresponding Sub-CA/Root CA using a key pair with
a special extended key usage flag in the certificate.
Add the following new NOTE after NOTE 29 below [V2G20-2403]:
NOTE 30 Although this requirement specifies using RDNs from Issuer field of the root certificates, per IETF RFC
5280, 4.1.2.4 (as updated by IETF RFC 6818, IETF RFC 8398 and IETF RFC 8399) for root certificates these RDNs
should be the same between the Issuer field and the Subject field.
Renumber all NOTEs starting from the original NOTE 9.

ISO 15118-20:2022/DAM 1:2024(en)

Clause 7.7.3.10
Add the following new requirements and note at the end of clause 7.7.3.10:
[V2G20-3009] [MCS] Backwards compatibility with ISO 15118-2 shall not be implemented for an EVCC
using MCS.
[V2G20-3010] [MCS] Backwards compatibility with ISO 15118-2 shall not be implemented for a SECC
using MCS.
NOTE 10 Requirements [V2G20-2054] through [V2G20-2070] are not applicable for MCS and MCS_BPT.

Clause 7.8.3.1, Table 14
In Table 14: Replace the table row with payload type value 0x8007 - 0x8100 with the following new rows:
Payload type value Payload type identifier Explanation
0x8007 - 0x8009 Not applicable Reserved for future use
EXI encoded V2G messages of this document
which are exchanged as part of the main
stream of the communication flow and are
specific to AC BPT DER. This set of messages
0x8010 Part20ACDERMainstreamPayloadID
is using the XSD schema with the namespace
"urn:iso:std:iso:15118:-20:AC-DER".
Refer to Annex L for the definition of this
message set.
0x8011 - 0x8100 Not applicable Reserved for future use

Clause 7.9.1.3
Add the following new requirement below requirement [V2G20-5125]:
[V2G20-3011] [DER] The XML schema with the namespace "urn:iso:std:iso:15118:-20:AC-DER" shall be
used for encoding and decoding EXI streams sent or received with Part20ACDER-
MainstreamPayloadID and defined in Annex L.

Clause 7.9.2.4.2
Replace the text below the requirement [V2G20-2476] with the following text:
[V2G20-3012] NIST FIPS PUB 202 defines SHAKE256 as an extendable-output function (XOF). Hence the
output length of SHAKE256 (referred as ‘d’ by NIST FIPS PUB 202) can be configured to
any necessary value as needed by the application. For signatures as defined by [V2G20-
2476], the output length ‘d’ of SHAKE256 shall be 114 bytes (912 bits).
NOTE 2 IETF RFC 8032, 5.2 specifies using 114 bytes (912 bits) as the output length of SHAKE256. This requirement
keeps the SHAKE256 output length consistent between the IETF RFC 8032 and this document.

ISO 15118-20:2022/DAM 1:2024(en)
[V2G20-771] The following message elements of the XML signature framework shall not be used when
transmitting signatures in the header of the V2G message:
— Id (attribute in SignedInfo)
— ##any in SignedInfo – CanonicalizationMethod
— HMACOutputLength in SignedInfo – SignatureMethod
— ##other in SignedInfo – SignatureMethod
— Type (attribute in SignedInfo-Reference)
— ##other in SignedInfo – Reference – Transforms – Transform
— XPath in SignedInfo – Reference – Transforms – Transform
— ##other in SignedInfo – Reference – DigestMethod
— Id (attribute in SignatureValue)
— Object (in Signature)
— KeyInfo
NOTE 3 This allows to determine an upper bound for the size of the signature header.
For the application of XMLDsig, any element which should be signed is addressable. In this document, this
is achieved by a URI referencing the ID attribute of such an element. Therefore, any message element that is
signed carries an ID attribute. If a specific element is to be signed in all use cases, the ID attribute is marked
mandatory in the XSD. Otherwise, if it is signed in only some use cases, the ID attribute is marked optional
and can be omitted when not needed.
NOTE 4 Presence of an ID attribute does not necessarily indicate that a signature is used, i.e. if no signature is used,
an ID can be present nevertheless.
NOTE 5 Refer IETF RFC 3986 as updated by IETF RFC 6874 and IETF RFC 7320 for details of URI.

Clause 7.9.2.4.3
Replace Table 17 with this table:

ISO 15118-20:2022/DAM 1:2024(en)
Table 17 — Overview of applied XML based signatures
Verifying
XML message Protected fields Signing entity (sender) entity (re-
ceiver)
EVCC; signed with private key
associated with the contract
AuthorizationReq PnC_AReqIdentificationMode SECC
certificate provided within
PnC_AReqAuthorizationMode
EVCC; signed with private key
associated with OEM provision secondary
CertificateInstallationReq OEMProvisioningCertificateChain
certificate (transmitted in mes- actor
sage body element)
secondary actor; signed with
the private key associated with
CertificateInstallationRes SignedInstallationData EVCC
the leaf certificate of the certifi-
cate provisioning service
EVCC; signed with private key
associated with the contract
MeteringConfirmationReq SignedMeteringData certificate (certificate is trans- SECC
mitted in AuthorizationReq
message)
secondary actor; signed with
AbsolutePriceSchedule + PriceLev-
ScheduleExchangeRes the private key associated with EVCC
elSchedule
the eMSP Sub-CA2 certificate
Replace NOTE 1 below the requirement [V2G20-2479] with:
NOTE 1 The key in the ‘value’ field of ‘generalName’ parameter of ‘accessLocation’ field of ‘accessDescription
(x448PublicKey)’ parameter in the extension ‘subjectInfoAccess’ is encoded for use only in ECDH algorithm. It is not
possible to use it to verify signatures using the Ed448 algorithm.

Clause 7.9.2.5.3, Figure 25
Replace Figure 25 with this figure:

ISO 15118-20:2022/DAM 1:2024(en)
Figure 25 — Process for CertificateInstallationRes for EVCC equipped with TPM 2.0

Clause 7.9.2.5.3.3, Figure 26
Replace Figure 26 with this figure:

ISO 15118-20:2022/DAM 1:2024(en)
Figure 26 — Contract key encryption for direct import into EVCC’s TPM 2.0 (for (elliptic curve) EC
P-521/secp521r1)
Clause 7.9.2.5.4
Replace requirement [V2G20-2530] and NOTE 5 with:
[V2G20-3013] When the mechanism defined by [V2G20-2320] indicates usage of the (elliptic curve) EC as
specified by [V2G20-2319], the “Contract Transport Public Key” of the OEM provisioning
certificate shall be used as static public key for calculation of the session key as defined
by [V2G20-2535].
NOTE 5 Refer to B.7.2 for further details of “Contract Transport Public Key” stored in the ‘value’ field of
‘generalName’ parameter of ‘accessLocation’ field of ‘accessDescription (x448PublicKey)’ parameter in the extension
‘subjectInfoAccess’ of the OEM provisioning certificate.
Replace requirement [V2G20-2534] and NOTE 9 with:
[V2G20-3014] If the EVCC receives the parameter ECDHCurve set to ‘X448’, it shall use the private key
associated with the “Contract Transport Public Key” of the OEM Provisioning Certificate
along with the public key calculated from [V2G20-2532] for calculation of the session key
as defined by [V2G20-2535].
NOTE 9 Refer to B.7.2 for the OEM provisioning certificate profile associated with the algorithm specified by
[V2G20-2319] and [V2G20-2674]. Refer to for further details of the xx448 private key.

Clause 7.10.1.1
Add the following new requirements and note at the end of the section (above 7.10.1.2):

ISO 15118-20:2022/DAM 1:2024(en)
[V2G20-3015] [MCS] If 10BASE-T1S communication according to ISO 15118-10 is applied, the SDP client
in the EVCC shall use SECC discovery message with the payload type SDPRequest-
PayloadID (see Table 14).
[V2G20-3016] [MCS] If 10BASE-T1S communication according to ISO 15118-10 is applied, the SDP client
in the EVCC shall only accept SDP response messages with the payload type SDP-
ResponsePayloadID (see Table 14).
[V2G20-3017] [MCS] If the SDP server shall handle charging services with 10BASE-T1S (according to
ISO 15118-10), the SDP server shall accept SECC discovery request messages with
payload type SDPRequestPayloadID (see Table 14).
[V2G20-3018] [MCS] An SDP server which is used for 10BASE-T1S communication according to ISO
15118-10 shall use SECC discovery response message for 10BASE-T1S with payload
type SDPResponsePayloadID (see Table 14).
NOTE 1 Requirements [V2G20-2273] through [V2G20-2280] are not applicable for MCS and MCS_BPT.

Clause 7.10.1.5
Replace title of clause 7.10.1.5 with:
SECC discovery request message for communication according to ISO 15118-3 or ISO 15118-10
Add the following new requirement at the end of the section (above 7.10.1.6):
[V2G20-3019] [MCS] For communication according to ISO 15118-10, an SDP client shall send SECC dis-
covery request messages with the security option value equal to 0x00, equivalent
to secured with TLS.
Clause 7.10.1.6
Replace title of clause 7.10.1.6 with:
SECC discovery response message for communication according to ISO 15118-3 or ISO 15118-10

Clause 8.2.1
Add the following requirement below requirement [V2G20-1039]:
[V2G20-3020] [DER] If an EVCC supports the service AC DER and intends to use it for this V2G commu-
nication session, it shall add an AppProtocol element to the supportedAppPro-
tocolReq with ProtocolNamespace set to "urn:iso:std:iso:15118:-20:AC-DER",
VersionNumberMajor set to "1" and VersionNumberMinor set to "0".
Add the following requirement below requirement [V2G20-5126]:
[V2G20-3021] [MCS] If an EVCC supports the service MCS and intends to offer it for this V2G communica-
tion session, it shall add an AppProtocol element to the supportedAppProtocolReq
with ProtocolNamespace set to "urn:iso:std:iso:15118:-20:DC", VersionNumber-
Major set to "1" and VersionNumberMinor set to "0".

Clause 8.3.4
ISO 15118-20:2022/DAM 1:2024(en)
Add the following new clauses below 8.3.4.8:
8.3.4.9  MCS messages
[V2G20-3022] [MCS] If the MCS or MCS_BPT service is selected, the EVCC and the SECC shall implement
the DC messages as specified in 8.3.4.5.
8.3.4.10  AC DER messages
[V2G20-3023] [DER] If the AC DER service is selected, the EVCC and the SECC shall implement the AC
DER messages as specified in L.2.1.1.

Clause 8.3.4.1.2
Replace Note 5 with:
NOTE 5 In case of communication according to ISO 15118-3, from first authorization until termination of the V2G
communication session or physical plug out. A physical plug out is indicated by a CP state change B to A for conductive
charging based on IEC 61851-1, and by CE state changes from state B/B_Aux to A for conductive charging according to
IEC 61851-23-3.
Clause 8.3.5
Add the following new clauses below 8.3.5.7:
8.3.5.8  MCS
[V2G20-3024] [MCS] If the MCS or MCS_BPT service is selected, the EVCC and the SECC shall implement
the complex data types of the DC message set as specified in 8.3.5.5.
8.3.5.9  AC DER
[V2G20-3025] [DER] If the AC DER service is selected, the EVCC and the SECC shall implement the complex
data types, physical values and simple data types as specified in L.2.2.1 and L.2.2.2.

Clause 8.4.3.1
In Table 204: Replace the table row with ServiceID (unsignedShort) value 8-64 with the following new rows:
ServiceID
ServiceName Description
(unsignedShort)
MCS energy transfer, physical
8 MCS
layer according to ISO 15118-10
MCS energy transfer with BPT,
9 MCS_BPT physical layer according to ISO
15118-10
AC Charging with BPT, EV being
responsible for acting as a DER
and fulfilling a dedicated part of
10 AC_DER the grid codes requirements de-
fined for the BPT system consist-
ing of an EV and a permanently
connected EV supply equipment.
11-64 Reserved by this document

ISO 15118-20:2022/DAM 1:2024(en)
Add the following new requirements at the end of the subclause (above 8.4.3.2):
[V2G20-3026] [MCS] If the service with the ServiceName = MCS or MCS_BPT was selected by the EVCC
and confirmed by the SECC, the respective requirements in Annex K shall be applied.
[V2G20-3027] [DER] If the service with the ServiceName = AC_DER was selected by the EVCC and con-
firmed by the SECC, all requirements in Annex L shall be applied.
[V2G20-3028] [DER] If the AC DER service shall be supported by the SECC, the SECC shall support and
offer ServiceRenegotiation, i.e., the SECC shall set ServiceRenegotiationSupported
= TRUE in the ServiceDiscoveryRes.
[V2G20-3029] [DER] If the AC DER service shall be supported by the EVCC, the EVCC shall support Ser-
viceRenegotiation and execute it, if requested to do so by the SECC.
[V2G20-3030] [DER] If the service with the ServiceName = AC_DER was selected by the EVCC and con-
firmed by the SECC, all requirements applicable to the service with ServiceName
= AC shall apply as well.
Clause 8.4.3.2
Add the following new clauses below 8.4.3.2.7:
8.4.3.2.8  MCS service
[V2G20-3031] [MCS] If the MCS service is selected, the EVCC and the SECC shall implement the MCS
service parameters as specified in K.3.1.1.2.
8.4.3.2.8.1  MCS BPT service
[V2G20-3032] [MCS] If the MCS_BPT service is selected, the EVCC and the SECC shall implement the
MCS_BPT service parameters as specified in K.3.1.1.2.1.
8.4.3.2.9  AC DER service
[V2G20-3033] [DER] If the AC DER service is selected, the EVCC and the SECC shall implement the AC
DER service parameters as specified in L.3.1.1.2.

Clause 8.5
Replace the title of 8.5.6 with:
V2G message synchronization for AC, AC DER and DC with IEC 61851-1 signalling
Add the following new clauses below 8.5.7:
8.5.8  V2G message synchronization for MCS with IEC 61851-23-3 signalling
[V2G20-3034] [MCS] If the MCS or MCS_BPT service is selected, the EVCC and the SECC shall implement
the requirements specified in K.4.3.

Clause 8.5.2
Replace the first sentence of NOTE 3 with:
This document supports PLC, WiFi and 10BASE-T1S communication.

ISO 15118-20:2022/DAM 1:2024(en)

Clause 8.6.3.2
Add the following new text at the beginning of the clause:
The following requirements apply for the services AC, AC_BPT and AC_DER.

Clause 8.6.3.3
Add the following new text at the beginning of the clause:
The following requirements apply for the services DC, DC_BPT, MCS and MCS_BPT.

Clause 8.6.4.2
Add the following new text at the beginning of the clause:
The following requirements apply for the services AC, AC_BPT and AC_DER.

Clause 8.6.4.3
Add the following new text at the beginning of the clause:
The following requirements apply for the services DC and DC_BPT. The requirements for the services MCS
and MCS_BPT are specified in K.5.2.1.

Clause 8.6.4.5.3.2
Add the following new text at the beginning of the clause:
The following requirements apply for the services AC, AC_BPT and AC_DER.

Clause 8.6.4.5.3.3
Add the following new text at the beginning of the clause:
The following requirements apply for the services DC and DC_BPT. The requirements for the services MCS
and MCS_BPT are specified in K.5.2.2.1.1.

Clause 8.6.4.6.3.2
Add the following new text at the beginning of the clause:
The following requirements apply for the services AC, AC_BPT and AC_DER.

Clause 8.6.4.6.3.3
Add the following new text at the beginning of the clause:
The following requirements apply for the services DC and DC_BPT. The requirements for the services MCS
and MCS_BPT are specified in K.5.2.3.1.1.

ISO 15118-20:2022/DAM 1:2024(en)

Annex A
Add a bullet point with the following text and link below the bullet point “V2G_CI_AC”:
— “V2G_CI_AC_DER”: Defines the messages exclusively
used for the AC DER service. The XSD file can be downloaded from:
https:// standards .iso .org/ iso/ 15118/ -20/ ed -1/ Amd1/ en/ V2G _CI _AC _DER .xsd

Clause B.1
Replace the entire text below Table B.1 with the following text:
NOTE 1 The following OIDs apply (ASN.1 notation):
— { iso(1) member-body(2) us(840) ansi-X9-62(10045) signatures(4) ecdsa-with-SHA2(3) 4 }
— { iso(1) member-body(2) us(840) ansi-X9-62(10045) keyType(2) 1 }
— { iso(1) identified-organization(3) certicom(132) curve(0) 35 }
— { iso(1) identified-organization(3) thawte(101) id-EdDSA448(113) }
— { iso(1) identified-organization(3) thawte(101) id-X448(111) }
— { joint-iso-itu-t(2) ds(5) attributeType(4) countryName(6) }
— { joint-iso-itu-t(2) ds(5) attributeType(4) organizationName(10) }
— { joint-iso-itu-t(2) ds(5) attributeType(4) organizationalUnitName(11) }
— { joint-iso-itu-t(2) ds(5) attributeType(4) commonName(3) }
— { itu-t(0) data(9) pss(2342) ucl(19200300) pilot(100) pilotAttributeType(1) domainCom-
ponent(25) }
— { joint-iso-itu-t(2) ds(5) certificateExtension(29) subjectKeyIdentifier(14) }
— { joint-iso-itu-t(2) ds(5) certificateExtension(29) keyUsage(15) }
— { joint-iso-itu-t(2) ds(5) certificateExtension(29) basicConstraints(19) }
— { joint-iso-itu-t(2) ds(5) certificateExtension(29) cRLNumber(20) }
— { joint-iso-itu-t(2) ds(5) certificateExtension(29) deltaCRLIndicator(27) }
— { joint-iso-itu-t(2) ds(5) certificateExtension(29) issuingDistributionPoint(28) }
— { joint-iso-itu-t(2) ds(5) certificateExtension(29) cRLDistributionPoints(31) }
— { joint-iso-itu-t(2) ds(5) certificateExtension(29) authorityKeyIdentifier(35) }
— { joint-iso-itu-t(2) ds(5) certificateExtension(29) extKeyUsage(37) }
— { joint-iso-itu-t(2) ds(5) certificateExtension(29) freshestCRL(46) }
— { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4)
hashalgs(2) sha512(3) }
ISO 15118-20:2022/DAM 1:2024(en)
— { joint-iso-itu-t(2) country(16) us(840) organization(1) gov(101) csor(3) nistAlgorithms(4)
hashalgs(2) shake256-len(18) }
— { iso(1) standard(0) 15118 part20(20) extensions(0) contractOperatorName(1) }
— { iso(1) standard(0) 15118 part20(20) extensions(0) contractTariffName(2) }
— { iso(1) standard(0) 15118 part20(20) extensions(0) contractDynamicInformationUrl(3) }
— { iso(1) standard(0) 15118 part20(20) extensions(0) tpmStorageKey(4) }
— { iso(1) standard(0) 15118 part20(20) extensions(0) tpmPolicyDigest(5) }
— { iso(1) standard(0) 15118 part20(20) extensions(0) crossCertIndication(6) }
— { iso(1) standard(0) 15118 part20(20) extensions(0) utf8String(7) }
— { iso(1) standard(0) 15118 part20(20) extensions(0) octetString(8) }
— { iso(1) standard(0) 15118 part20(20) extensions(0) x448PublicKey(9) }
— { iso(1) standard(0) 15118 part20(20) extensions(0) bitString(10) }
— { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
pe(1) authorityInfoAccess(1) }
— { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
pe(1) subjectInfoAccess(11) }
— { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
kp(3) id-kp-serverAuth(1) }
— { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
kp(3) id-kp-clientAuth(2) }
— { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
kp(3) id-kp-OCSPSigning(9) }
— { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
ad(48) ocsp(1) }
— { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
ad(48) id-ad-ocsp(1) id-pkix-ocsp-basic(1) }
— { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
ad(48) id-ad-ocsp(1) id-pkix-ocsp-nonce(2) }
— { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
ad(48) id-ad-ocsp(1) id-pkix-ocsp-response(4) }
— { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
ad(48) id-ad-ocsp(1) id-pkix-ocsp-pref-sig-algs(8) }
— { iso(1) identified-organization(3) dod(6) internet(1) security(5) mechanisms(5) pkix(7)
ad(48) caIssuers(2) }
NOTE 2 The online certificate status protocol (OCSP), defined in IETF RFC 6960 (as updated IETF RFC 8954) is
a protocol used for obtaining the revocation status of an X.509 certificate. OCSP is as an alternative to certificate
revocation lists (CRL), OCSP is an online service. This means, that a backend infrastructure supports OCSP services in
order to be able to use that service.
NOTE 3 Refer to ITU-T X.680 for details of ASN.1 notation.

ISO 15118-20:2022/DAM 1:2024(en)
When the certificate status is provided via OCSP services, id-pe-authorityInfoAccess OID is used within
[99]
the AuthorityInfoAccess extension. The OID repository also refers to id-pe-authorityInfoAccess as
authorityInfoAccess(1) (see NOTE 1 above providing the OID value for id-pe-authorityInfoAccess).
Within a x.509 certificate, the id-ad-ocsp OID is used within the AuthorityInfoAccess extension as
accessMethod if revocation information for the certificate containing this extension is available using the
online certificate status protocol (OCSP). When id-ad-ocsp appears as accessMethod, the accessLocation
field is the location of the OCSP responder, using the conventions defined IETF RFC 6960 as updated
IETF RFC 8954.
[99]
id-ad-ocsp is also known as id-pkix-ocsp. The OID repository also refers to id-ad-ocsp as ocsp(1) (see
NOTE 1 above providing the OID value for id-ad-ocsp).
If the certificate status is provided via
...