ChargeParameterDiscoveryRes for EIM contains XML signature

[lategoodbye]

According to ISO 15118-2:2014 (Table 104) the ChargeParameterDiscoveryRes message for EIM shouldn't contain a signature in it's header. But SECC of RiseV2G sends the XML signature also for EIM case, which looks wrong to me.

Expected behavior: In EIM case the XML signature in ChargeParameterDiscoveryRes should be omitted.

Here is an example trace from version 1.1.1:

hex encode:
809802219004B7236030928A895A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBD5148BD8D85B9BDB9A58D85B0B595E1A4BD0D5A1D1D1C0E8BCBDDDDDDCB9DCCCB9BDC99CBCC8C0C0C4BCC0D0BDE1B5B191CDA59CB5B5BDC9948D958D91CD84B5CDA184C8D4D910311A4A218812B43A3A381D1797BBBBBB973B999737B93397AA2917B1B0B737B734B1B0B616B2BC3497A429687474703A2F2F7777772E77332E6F72672F323030312F30342F786D6C656E632373686132353642020FAF9EB9A163505B97B754E77CDD3A210366E4BD450CDCDD0D50939A4557FCB1281D40419EB8CB1E470F22984A52A9BD36B74ADCB15DE31259D255F75561833AED51E77F25E2D29B8F4D5A094282CBB4785613692BC0A9A88976FA93CFBA23A88F482801C148CD2DCD2E6D0CAC900000000140700C2805840152510C400400040094800000062073008186040000

XML encoded:
<?xml version="1.0" encoding="UTF-8"?><s3:V2G_Message xmlns:s3="urn:iso:15118:2:2013:MsgDef" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:s0="http://www.w3.org/2000/09/xmldsig#" xmlns:s1="urn:iso:15118:2:2013:MsgBody" xmlns:s2="urn:iso:15118:2:2013:MsgDataTypes" xmlns:s4="urn:iso:15118:2:2013:MsgHeader">
  <s3:Header>
    <s4:SessionID>864012DC8D80C24A</s4:SessionID>
    <s0:Signature>
      <s0:SignedInfo>
        <s0:CanonicalizationMethod Algorithm="http://www.w3.org/TR/canonical-exi/"/>
        <s0:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#ecdsa-sha256"/>
        <s0:Reference URI="#ID1">
          <s0:Transforms>
            <s0:Transform Algorithm="http://www.w3.org/TR/canonical-exi/"/>
          </s0:Transforms>
          <s0:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/>
          <s0:DigestValue>IPr565oWNQW5e3VOd83TohA2bkvUUM3N0NUJOaRVf8s=</s0:DigestValue>
        </s0:Reference>
      </s0:SignedInfo>
      <s0:SignatureValue>6gIM9cZY8jh5FMJSlU3ptbpW5YrvGJLOkq+6qwwZ12qPO/kvFpTcemrQShQWXaPCsJtJXgVNREu3
1J590R1Eeg==</s0:SignatureValue>
    </s0:Signature>
  </s3:Header>
  <s3:Body>
    <s1:ChargeParameterDiscoveryRes>
      <s1:ResponseCode>OK</s1:ResponseCode>
      <s1:EVSEProcessing>Finished</s1:EVSEProcessing>
      <s2:SAScheduleList>
        <s2:SAScheduleTuple>
          <s2:SAScheduleTupleID>1</s2:SAScheduleTupleID>
          <s2:PMaxSchedule>
            <s2:PMaxScheduleEntry>
              <s2:RelativeTimeInterval>
                <s2:start>0</s2:start>
                <s2:duration>7200</s2:duration>
              </s2:RelativeTimeInterval>
              <s2:PMax>
                <s2:Multiplier>3</s2:Multiplier>
                <s2:Unit>W</s2:Unit>
                <s2:Value>11</s2:Value>
              </s2:PMax>
            </s2:PMaxScheduleEntry>
          </s2:PMaxSchedule>
          <s2:SalesTariff s2:Id="ID1">
            <s2:SalesTariffID>1</s2:SalesTariffID>
            <s2:SalesTariffEntry>
              <s2:RelativeTimeInterval>
                <s2:start>0</s2:start>
              </s2:RelativeTimeInterval>
              <s2:EPriceLevel>1</s2:EPriceLevel>
            </s2:SalesTariffEntry>
          </s2:SalesTariff>
        </s2:SAScheduleTuple>
      </s2:SAScheduleList>
      <s2:AC_EVSEChargeParameter>
        <s2:AC_EVSEStatus>
          <s2:NotificationMaxDelay>0</s2:NotificationMaxDelay>
          <s2:EVSENotification>None</s2:EVSENotification>
          <s2:RCD>false</s2:RCD>
        </s2:AC_EVSEStatus>
        <s2:EVSENominalVoltage>
          <s2:Multiplier>0</s2:Multiplier>
          <s2:Unit>V</s2:Unit>
          <s2:Value>230</s2:Value>
        </s2:EVSENominalVoltage>
        <s2:EVSEMaxCurrent>
          <s2:Multiplier>0</s2:Multiplier>
          <s2:Unit>A</s2:Unit>
          <s2:Value>32</s2:Value>
        </s2:EVSEMaxCurrent>
      </s2:AC_EVSEChargeParameter>
    </s1:ChargeParameterDiscoveryRes>
  </s3:Body>
</s3:V2G_Message>

[MarcMueltin]

Table 104 is not completely correct in this case. You need to consider requirement [V2G2-308] as well as Note 3.

Note 3: "If the secondary actor is unaware of which authentication mode is used during EVCC-SECC communication (EIM/ PnC), it can simply always sign the SalesTariff."

[V2G2-308] "The SECC shall not change the signature attached to the message element SalesTariff when receiving tariff information from the secondary actor."

So if the Secondary Actor (represented by DummyBackendInterface.java) always signs the SalesTariff according to Note 3, then the SECC is not allowed to change the signature (including deleting it).

Although in EIM the EVCC will not process the signature, it does not lead to an error situation if the signature is present.

Does this explanation solve the issue for you?

[lategoodbye]

Okay, thanks for the explanation and sorry for the noise.