RFID authorization and vehicle identification with OCPP backend

Is your feature request related to a problem? Please describe. I use an ABL eMH3 via OCPP with evcc. In addition, an OCPP billing backend is connected through evcc.

I would like to use the same vehicle with different authorization paths depending on the charging session:

private RFID card → local authorization by evcc, private charging session billing provider RFID card → authorization by the OCPP backend, business charging session

The backend provider only accepts the RFID card issued by them. Additional private RFID cards cannot be added there.

In both cases, evcc should still be able to identify and control the vehicle. In particular, the vehicle API, for example for SoC retrieval, as well as evcc charging strategies such as PV charging, Min+PV or target charging should continue to work.

Authorization, vehicle identification and charging control should therefore be handled as separate concerns.

Describe the solution you'd like For RFID tags, it could be configurable whether authorization is handled locally by evcc or by the backend.

For example:

RFID: Private card Vehicle: Kia EV3 Private ☐ Authorize via backend

RFID: Billing card Vehicle: Kia EV3 Business ☑ Authorize via backend

The flow could then be:

The charger sends the RFID tag to evcc. evcc checks whether the tag is assigned to a vehicle. Depending on the configuration: local authorization: evcc decides whether charging is allowed. backend authorization: evcc forwards the authorization request to the OCPP backend, waits for the response and uses that response as the authorization decision. Regardless of the authorization path, the identified vehicle remains assigned in evcc. evcc can continue to use vehicle API data and control the charging strategy.

A pure OCPP forwarding mode without using the backend response may still be useful, for example for billing, monitoring or forwarding transaction and meter data. This should however be distinguished from actual backend authorization.

Other authorization or release mechanisms should remain independent from this. A charging session may for example be released locally by evcc, via an OCPP backend, through ISO 15118, or through the evcc UI.

The important part is that vehicle identification remains separate: once evcc can unambiguously identify the connected vehicle, for example via RFID, ISO 15118 or another available identifier, and assign it to a vehicle, the corresponding vehicle data, API calls and charging strategies should continue to be available.

A pure online release via a backend or the evcc UI does not necessarily identify a specific vehicle. In that case, charging should still be possible; a vehicle should only be assigned if evcc can identify it by another means.

From a flow perspective, there are essentially two directions:

Bottom-up: identification or authorization is initiated at the charger side, e.g. RFID → charger → evcc or ISO 15118 → charger → evcc. Top-down: the charging release is initiated by evcc or an upstream backend and sent towards the charger.

Both paths should coexist without coupling vehicle identification to only one specific authorization mechanism.

Use case

Private charging

car → charger → evcc Private RFID card → local authorization by evcc evcc → vehicle identification, API access and charging control

Business charging

car → charger → evcc → OCPP billing backend Billing RFID → authorization request to backend → backend decides evcc → still handles vehicle identification, API access and charging control

Business charging without backend authorization

Car → charger → evcc Billing RFID → local authorization by evcc → session and meter data are forwarded to the backend evcc → continues to handle vehicle identification, vehicle API access and charging control

This would allow business charging sessions to be accounted for by the backend without requiring the backend itself to make the authorization decision.

Together with the other authorization paths, this would allow the same charger and the same vehicle to be used for both private and billable charging sessions without losing evcc vehicle identification or charging strategy functionality.

Describe alternatives you've considered

I considered using only the backend for all RFID authorization. This does not work in my case because the backend provider only accepts RFID cards issued by them and does not allow additional private RFID cards to be registered.

I also considered using only local authorization in evcc. That would solve private charging, but would prevent the backend from authorizing and accounting for business charging sessions.

Another option would be to use separate chargers or separate loadpoints for private and business charging. This would add unnecessary hardware and configuration complexity for what is essentially the same vehicle and charging point.

A pure OCPP forwarding setup without backend authorization would also not solve the requirement, because the backend must be able to explicitly authorize billable sessions.

The preferred solution is therefore to support both local and backend authorization paths while keeping vehicle identification and evcc charging control independent from the authorization method.

Additional context

Discussion: https://github.com/evcc-io/evcc/discussions/33913