Tokens module
Roam OCPI implementation of OCPI 2.2.1 tokens module
Tokens module adjustments
| Deviation | Roam OCPI solution |
|---|---|
| PULL not supported | Only PUSH, Plugsurfing expects the EMP to push new/updated tokens |
| Token whitelist always set to ALLOWED_OFFLINE | In order to allow users to charge when the CPO can't connect to the EMP (or when their chargers are offline), Plugsurfing forward all tokens to the CPOs with whitelist=ALLOWED_OFFLINE. |
| Token issuer | By default we share all tokens with CPOs with token issuer DE*8PS. Combining EMPs under DE*8PS brings us an advantage in our discussions with the CPOs, as we aggregate the demand from several players and thereby can negotiate better pricing, which all EMPs get advantage from. |
Real-time authorisation
Real-time authorisation can be enabled for your organization based on a setting. If real-time authorisation is enabled, we send through each authorisation request we receive after conducting some primary checks.
-
Step 1: Internal Validation - perform standard checks:
- Location within supported countries (based on existing location reference)
- Key enabled/disabled
-
Step 2: Forwarding to EMP - If the internal checks pass, Plugsurfing forwards the request to you for real-time authorization.
Please note that not all CPOs perform real-time authorization and that not all CPOs who do real-time authorization do it for all their sessions. Further, not all real-time authorizations include a location reference.
The time-out for answering to the real-time authorization is 3 seconds. If you don't respond within 3 seconds, Plugsurfing will allow the session.
Multiple keys per contract_id
Your organization can be set up to either support just one key per contract_id or multiple keys per contract_id. The default value is one key per contract_id, and if you support multiple keys per contract_id and want the setting enabled, you should know that there are a few limitations to the solution:
- Restriction of maximum 25 tokens per contract ID. The reason for the limit is because of a limit/risk with OCPI 2.1.1 connections with CPO partners. If such partner just sends us just a CDR (for a local start), we will not be able to identify exactly which charging key performed the charge. In such case we will pick the first key matching the contract ID in the CDR.
- To clarify that the session was conducted where there is uncertainty of whether we share the correct charging key or not, a header X-Original-Protocol is available for outgoing requests over the Session and CDR module. It contains
<protocol>-<version>, where protocol can be OCPI or OICP. The current versions are listed below, but can be extended if we upgrade CPO integrations to higher versions.- OCPI-2.1.1
- OCPI-2.2
- OCPI-2.2.1
- OICP-2.3 (hubject)
Updated 30 days ago