Provision of signed datasets for the transparency software
The signed data which is transmitted from the charging device is passed over to the transparency software in a data format. This specification explains the data format to enable the use of the transparency software.
German calibration law calls for the unquestionable possibility of checking readings at charging facilities. One of the permissible methods for checking readings is to provide the readings with a digital signature. The signature check required for this process is carried out in a transparency software.
In order for the back-end systems to provide the digitally signed readings which are to be checked in a uniform format, we define with this specification the file format, which transmits digitally signed readings to the transparency software.
General data transfer procedure
Digitally signed readings are transmitted from the charging device to a back-end system. This can be done either directly through OCPP or alternatively through third-party systems, such as roaming networks based on InterCharge. In every case, a digitally signed dataset is transmitted, which includes not only the actual readings but also the digital signature. This data is saved in the backend system of the CPO or EMP and stored accordingly.
The user or consumer who wants to check the readings for accuracy after a charging process with the help of the transparency software must now have access to these readings. The EMP is responsible for passing on the readings to the consumer. This must make the digitally signed readings available to the consumer. This is done, for example, by providing the signed readings via download from a customer portal or mobile application, or alternatively by sending them via email or by means of data carriers.
The digitally signed records must be created in a format that can be read and processed by the transparency software. This file format is specified in detail below, allowing for a seamless transfer of digitally signed readings to the transparency software. This will enable the consumer to check the readings with little effort without any further requirements.
Data format for data transfer
The data format for transferring digitally signed readings to the transparency software is based on an XML data construct and allows for one or more readings to be provided in a transmission. This makes it possible to digitally send the consumer either a single reading or, alternatively, all readings for an entire charging process.
With the file, in addition to the signed measurement data in its original form, the consumer is also given the optional public key, which is required for the signature check. Handing over the public key is a comfort function so that the consumer does not have to manually capture this key in the application. However, in the transparency software, they also have the ability to capture, correct and verify the public key themself. To provide the public key in the data export, it is necessary to transmit it to the back-end system beforehand. This can be done by the charging device or by a manual input. In this context, we refer to our specification for the transmission of information about the measurement capsule via OCPP.
The file format for transferring readings to the transparency software has the following format:
<?xml version="1.0" encoding="UTF-8"?> <values xmlns="http://transparenz.software/schema/2018/07"> <value> <signedData encoding="base64" format="SML_EDL40_P">ENCODED STRING</signedData> <publicKey>887FABF407AC82782EEFFF2220C2F856AEB0BC22364BBCC6B55761911ED651D1A922BADA88818C9671AFEE7094D7F536</publicKey> </value> </values>
File format container for transparancy software
The optional public key, if included in the export, must be deployed in ASN.1 format.
To clarify the file format specification, we show here the XSD format of the file as follows:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <xs:schema version="1.0" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="publicKey" type="publicKey"/> <xs:element name="signedData" type="signedData"/> <xs:element name="value" type="value"/> <xs:element name="values" type="values"/> <xs:complexType name="values"> <xs:sequence> <xs:element ref="value" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:complexType> <xs:complexType name="value"> <xs:sequence> <xs:element ref="publicKey" minOccurs="0"/> <xs:element ref="signedData" minOccurs="1"/> </xs:sequence> </xs:complexType> <xs:complexType name="publicKey"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="encoding" type="xs:string"/> </xs:extension> </xs:simpleContent> </xs:complexType> <xs:complexType name="signedData"> <xs:simpleContent> <xs:extension base="xs:string"> <xs:attribute name="format" type="xs:string"/> <xs:attribute name="encoding" type="xs:string"/> </xs:extension> </xs:simpleContent> </xs:complexType> </xs:schema>
XSD for the file format for transparancy software