Transmission of digitally signed readings - has·to·be eMobility

OICP Integration

for transmission of digitally signed readings

The calibration law requirements in Germany require the provision of digitally signed readings to the end-user. This specification describes the necessary implementation to send digitally signed readings to mobility providers via Hubject's OICP protocol.

The current implementation of the Intercharge Platform already provides for part of the CDR dataset to transmit digitally signed readings. Based on the historical growth, the platform used the former text lengths with respect to the OCPP specifications. However, as part of the implementation of the relevant calibration law requirements, it has now been shown that it is not possible to use this field due to the limited length of text for some use cases. The currently available length of the data field is simply too small for the transmission of all relevant data.

The same requirement also applies to various other roaming platforms that have provided for an identical field size. In order to enable a correspondingly pragmatic implementation of interoperability in a transition phase, we have drawn up the implementation guideline described on this page. This can be used to transmit digitally signed readings in conjunction with roaming platforms. It should be noted that be.ENERGISED Platform's digitally signed readings are processed in the form described here and made available to third parties according to this specificationen.

General advice on implementation

The transmission of digitally signed readings is an imperative measure based on the requirements of the measurement and calibration law in Germany. This ensures that a mobility provider can bill charging operations in a compliant and performance-related way to third parties such as end-customers and drivers etc. To do this, the CPO must provide the EMP/MSP with the necessary digitally signed datasets.

Since the field length defined in the current CDR dataset is limited to 200 characters for signed readings, it is advisable to transfer the digitally signed readings in a different form. In this context, has·to·be recommends providing the EMP/MSP with information on how to obtain the signed readings instead of transferring the digitally signed readings. This data download can be accessed after receiving the CDR dataset from the EMP/MSP with an asynchronous query from the CPO. The signature data can be queried by the CPO via a GET request after receiving the CDR dataset from the EMP.

Design of the data delivery

has·to·be delivers digitally signed readings exclusively via an additional GET request at the request of the EMP/MSP. For this purpose, a URL is transmitted in the MeteringSignature field, from which the signature data can be retrieved. After receiving the CDR, the EMP/MSP sends a second GET request to obtain the signature data from the CPO.

When the request is sent, the CPO immediately returns an XML file to the EMP/MSP in response to this request, which corresponds to the file format of the transparency software. This provides the MSP with all the necessary data required to provide the signature data.

Data Security

The information provided with the dataset of signed readings is exposed to the internet due to the GET request. In order to ensure that this data is not accessed illegally, but that the individual user data does not need to be negotiated with every EMP/MSP, it is advisable to secure the retrieval of the data with a corresponding parameter sequence in such a way that no access can be made to the data.

In addition to a TLS secured data connection, has·to·be recommends a MD5 checksum for the URL link which is transmitted in the MeteringSignature field and subsequently provided. This makes it virtually impossible for an attacker to guess the correct link, and it is also impossible to infer any inventory data from a charging operation.
For example, a URL link is constructed, as it is transmitted in the MeteringSignature field, as follows:

The MSP can use this URL information to retrieve the transaction number as well as the verification sum of the data and validate it as an option after receiving the data.

Connection to the transparency software

The signature data retrievable from this request includes all digital signatures available for the required charging process. In addition, these are already stored in the data format which can be used by the transparency software transparency software. This enables the EMP/MSPs to provide their end-customer with the dataset without any modification necessary, so that they can thereafter check the signatures of the charging process.
d to meet the relevant requirements of the calibration law.