Identity and Access


In most cases, IdToken data acquired via local token reader hardware is usually a (4 or 7 byte) UID value of a physical RFID card, typically represented as 8/14 hexadecimal digit characters.

However, IdTokens sent to Charge Points by Central Systems for remotely initiated charging sessions may commonly be (single use) virtual transaction authorization codes, or virtual RFID tokens that deliberately use a non-standard UID format to avoid possible conflict with real UID values.

Before the owner of an electric vehicle can start or stop charging, the Charge Point has to authorize the operation. The Charge Point SHALL only supply energy after authorization. When stopping a Transaction, the Charge Point SHALL only send an Authorize.req when the identifier used for stopping the transaction is different from the identifier that started the transaction.
Authorize.req SHOULD only be used for the authorization of an identifier for charging.

A Charge Point MAY authorize identifier locally without involving the Central System, as described in Local Authorization List. If an idTag presented by the user is not present in the Local Authorization List or Authorization Cache, then the Charge Point SHALL send an Authorize.req PDU to the Central System to request authorization. If the idTag is present in the Local Authorization List or Authorization Cache, then the Charge Point MAY send an Authorize.req PDU to the Central System.

  • "EHSPHL8K" AuthorizeCharging("CUID2242678", 42) SENT
[3, "7f0340ac-70bf-47bb-a8a7-934e81b24275", {"status":"Accepted"}]
  • Session start received ChargeSessionStartObservation { Id: 136, MeterValue: 1047.886754, Start: 07/22/2022 12:11:40, Auth: "CUID2242678", AuthReason: BlindlyAcceptToken }

Offline Behavior

The Charge Point is designed to operate stand-alone, which means a Charge Point will authorize a user when it is offline -unavailability of the communications or the Central System.
To improve the experience for users, a Charge Point MAY support local authorization of identifiers, using an
Authorization Cache and/or a Local Authorization List.
This allows authorization of a user when the Charge Point is offline, and faster authorization response time when
communication between Charge Point and Central System is slow.

Authorization Cache

A Charge Point MAY implement an Authorization Cache that autonomously maintains a record (10 records with Easee chargers) of previously presented identifiers that have been successfully authorized by the Central System. (Successfully meaning: a response received on a message containing an idTag)

Local Authorization List

The Local Authorization List is a list of identifiers that can be synchronized with the Central System.
The list contains the authorization status of all (or a selection of) identifiers and the authorization status/expiration date.

Identifiers in the Local Authorization list can be marked as valid, expired, (temporarily) blocked, or blacklisted, corresponding to IdTagInfo status values Accepted/ConcurrentTx, Expired, Blocked, and Invalid, respectively.

[2, "eae4d55b-bda7-4db4-b2d2-061c2a8e0a40", "StartTransaction", {"connectorId":1,"idTag":"043B89D2EB6C80","meterStart":230488,"timestamp":"2022-07-21T07:11:16.0000000Z"}]
[3, "eae4d55b-bda7-4db4-b2d2-061c2a8e0a40", {"idTagInfo":{"status":"Accepted","expiryDate":"2022-07-22T07:13:20.875Z"},"transactionId":1658387600}]

The Local Authorization List SHOULD be maintained by the Charge Point in non-volatile memory, and SHOULD be persisted across reboots and power outages.

Did this page help you?