1.11 Registration Authority

As a PKI provider, verifying the identity associated with the Common Name is a critical part of the certificate issuance process.

To ensure a smooth and secure certificate signing experience, we require that Common Names be registered in our certificate authority. This registration process is essential as it allows us to conduct thorough checks and validation, ensuring that certificates are only issued to the rightful owners. If a Common Name is not registered in our certificate authority, the request for signing a certificate may be denied, thus maintaining a robust security posture.

Getting ready

We adhere to ISO requirements, which dictate that different roles must have specific IDs attached to their Common Names. The first components of these IDs are attached to the credential used to access the endpoints, so it needs to be set beforehand:

1. Mobility Operators (MO) are identified by their EMAID (e-Mobility Account Identifier). The first five characters of the Common Name represent the country code and provider ID and are attached to the credentials used to access the endpoints.

2. Charge Point Operators (CPO) are distinguished by their EVSE/SECC ID (Electric Vehicle Supply Equipment/Supply Equipment Communication Controller). The first five characters of the Common Name represent the country code and operator ID. This is attached to the credential.

3. Original Equipment Manufacturers (OEM) are identified by their PCID (Provisioning Certificate Identifier). The first three characters of the Common Name represent the WMI (World Manufacturer Identifier) of the manufacturer. It's attached to the credential.

Typically, during the initial onboarding process, the credentials are configured, incorporating the aforementioned components. However, it is crucial to keep us informed in the event of any changes or additions to the ProviderID, OperatorID, or WMI. This ensures that we can promptly update the used credentials and avoid potential blockages of certificate signing requests.

Our Registration Authority endpoints have been purposefully implemented to streamline the registration process. With these endpoints, users can easily register, verify, and manage their EVSE/SECC IDs. This user-friendly approach enhances the overall experience and simplifies certificate management, ensuring secure and efficient deployment for all stakeholders.

By adhering to these rigorous identity verification processes and implementing user-friendly tools, we strive to maintain the highest standards of security and user satisfaction as a trusted PKI provider.

Interfaces

In total five interfaces are available for the process:

Register

This endpoint allows registration of the common names at the Hubject PKI Gateway for a specific role by passing the common names in an array of string objects.

Six attributes are required in the body of the call: 

{ 
  "commonName": "string",
  "manufacture": "string",
  "deviceName": "string",
  "deviceSWVersion": "string"
  "evseSerialNumber": "string"
  "evseID": array["string"]
  "evseISOversion": "string"
  "ocppVersion": "string"
  "chargeBoxSerialNumber": "string"
}

^(([a-zA-Z]{2}\-?[a-zA-z0-9]{3}\-?[S]\-?[a-zA-Z0-9]{32,59})\-?[0-9]?|([a-zA-Z]{2}\*?[a-zA-Z0-9]{3}\*?[E][a-zA-Z0-9*]{1,59}))$

With a successful response you will receive the following attributes:

{ 
  "id": 0,
  "commonName": "string", 
  "registeredDate": "string", 
  "userName": "string",
  "ca": "string", 
  "stage": "string",
  "manufacture": "string",
  "deviceName": "string",
  "deviceSWVersion": "string"
  "evseSerialNumber": "string"
  "evseID": array["string"]
  "evseISOversion": "string"
  "ocppVersion": "string"
  "chargeBoxSerialNumber": "string"
}

GetAllRegisterByUserName

Delete

GetAllRegisterPages

This endpoint facilitates the retrieval of all Common Names and their associated information stored in the Registration Authority using a pagination format.

By providing the following parameters:

• offset: specifying the desired page to be displayed;
• pageSize: indicating the number of items per page;

the user will receive an array of items adhering to the registration response schema.

Error Handling

Error Response Schema:

• Properties: 
  • errorMessage Array(string): An array of error messages
  • traceId (string, UUID format): A unique identifier for tracing the error.

Responses:

• 200: OK
  • Schema: Registration response;
• 400: Bad Request
  • Schema: Error;
  • Description: Invalid request or parameters;
• 404: Unauthorised
  • Schema: Error;
  • Description: Invalid token was presented;
• 500: Internal Server Error
  • An internal error occurred in the server.

The interface above mentioned can be found in the Postman collection available here.