OCPP 2.0.1 Edition 4

Authorization Flows - CSMS Developer Guide

Based on OCPP 2.0.1 Edition 4 Specification (Part 2). This guide covers all authorization flows from the CSMS (Charging Station Management System) perspective.

7 Sections
16 Use Cases
C01 - C16, D01 - D02

1. Overview

Introduction

Authorization in OCPP 2.0.1 determines whether an EV Driver is allowed to charge at a Charging Station. The CSMS is the central authority that validates IdTokens and returns authorization decisions.

Core Concepts

IdToken

An identifier presented by the EV Driver (RFID card, app token, eMAID, etc.)

Authorization Cache

A local cache on the Charging Station that stores previously received authorization data from the CSMS. This is an autonomous Charging Station mechanism.

Local Authorization List

A CSMS-synchronized list of IdTokens stored on the Charging Station. The CSMS controls this list via SendLocalListRequest.

Group IdToken

A parent token that links multiple individual IdTokens (e.g., a family or company account). Used for stopping transactions started by another token in the same group.

Relationship Between Authorization and Transactions

Authorization and transactions are decoupled in OCPP 2.0.1. The Charging Station decides locally when to start/stop a transaction based on TxStartPoint and TxStopPoint configuration. Authorization can happen before, during, or after a transaction starts. The CSMS receives authorization requests and transaction events independently.

2. Key Data Types & Schemas

Reference

2.1 IdTokenType

Sent by the Charging Station to identify the EV Driver.

IdTokenType Schema 
{
  "idToken": "string (max 36 chars, case-insensitive)",
  "type": "IdTokenEnumType",
  "additionalInfo": [                          // optional
    {
      "additionalIdToken": "string (max 36)",
      "type": "string (max 50)"
    }
  ]
}

IdTokenEnumType values:

Value Description
Central Identifier from the CSMS (used for GroupIdTokens)
eMAID Electro-Mobility Account Identifier (ISO 15118)
ISO14443 RFID card conforming to ISO 14443 (most common NFC cards)
ISO15693 RFID card conforming to ISO 15693
KeyCode PIN code entered on keypad
Local Locally generated identifier (e.g., start button)
MacAddress MAC address-based identifier
NoAuthorization No authorization needed (AuthEnabled = false)

2.2 IdTokenInfoType

Returned by the CSMS in responses to communicate the authorization decision.

IdTokenInfoType Schema 
{
  "status": "AuthorizationStatusEnumType",       // REQUIRED
  "cacheExpiryDateTime": "date-time string",     // optional
  "chargingPriority": 0,                         // optional, integer -9 to 9
  "language1": "string (max 8)",                 // optional, RFC 5646
  "language2": "string (max 8)",                 // optional, RFC 5646
  "evseId": [1, 2],                              // optional, array of integers
  "groupIdToken": {                              // optional
    "idToken": "string",
    "type": "IdTokenEnumType"
  },
  "personalMessage": {                           // optional
    "format": "MessageFormatEnumType",           // REQUIRED
    "content": "string (max 512)",               // REQUIRED
    "language": "string (max 8)"                 // optional, RFC 5646
  }
}

AuthorizationStatusEnumType values:

Value Description CSMS Action
Accepted Token is valid, charging allowed Token found and authorized
Blocked Token is blocked Token is explicitly blocked in the system
ConcurrentTx Token is already in use in another transaction Check for active transactions with this token
Expired Token has expired Token validity period has passed
Invalid Token is unknown/invalid Token not found in the system
NoCredit Token has no credit (prepaid) Check balance for prepaid accounts
NotAllowedTypeEVSE Token not allowed on this EVSE type Token has EVSE type restrictions
NotAtThisLocation Token not valid at this location Token has location restrictions
NotAtThisTime Token not valid at this time Token has time-of-day restrictions
Unknown Token status cannot be determined CSMS cannot verify the token at this time

MessageFormatEnumType values: ASCII, HTML, URI, UTF8

2.3 StatusInfoType

A generic type used in many responses to provide additional information about a status.

StatusInfoType Schema 
{
  "reasonCode": "string (max 20)",               // REQUIRED, case-insensitive predefined code
  "additionalInfo": "string (max 512)"           // optional, detailed human-readable information
}

2.4 AuthorizeCertificateStatusEnumType

Used only in AuthorizeResponse.certificateStatus for ISO 15118 certificate validation.

Value Description
Accepted All certificates are valid
SignatureError Certificate signature is invalid
CertificateExpired Certificate has expired
CertificateRevoked Certificate has been revoked
NoCertificateAvailable No certificate available for validation
CertChainError Error in the certificate chain
ContractCancelled The contract associated with the certificate has been cancelled

3. OCPP Messages Involved in Authorization

Protocol

3.1 AuthorizeRequest (CS -> CSMS)

The Charging Station sends this when an EV Driver presents an IdToken and the CS needs CSMS validation.

Charging Station --> CSMS
AuthorizeRequest 
{
  "idToken": {                                    // REQUIRED
    "idToken": "AABBCCDD",
    "type": "ISO14443"
  },
  "certificate": "-----BEGIN CERTIFICATE-----...",  // optional, PEM format, max 5500 chars
  "iso15118CertificateHashData": [                   // optional, 1-4 items
    {
      "hashAlgorithm": "SHA256",                     // REQUIRED: SHA256 | SHA384 | SHA512
      "issuerNameHash": "string (max 128)",          // REQUIRED
      "issuerKeyHash": "string (max 128)",           // REQUIRED
      "serialNumber": "string (max 40)",             // REQUIRED
      "responderURL": "string (max 512)"             // REQUIRED
    }
  ]
}

3.2 AuthorizeResponse (CSMS -> CS)

The CSMS responds with the authorization decision.

CSMS --> Charging Station
AuthorizeResponse 
{
  "idTokenInfo": {                                // REQUIRED
    "status": "Accepted",
    "cacheExpiryDateTime": "2025-12-31T23:59:59Z",
    "chargingPriority": 0,
    "evseId": [1, 2],
    "groupIdToken": {
      "idToken": "GROUP001",
      "type": "Central"
    },
    "personalMessage": {
      "format": "UTF8",
      "content": "Welcome, John!"
    }
  },
  "certificateStatus": "Accepted"                // optional, only for ISO 15118
}

CSMS implementation logic for AuthorizeResponse:

  1. Look up the idToken (case-insensitive) in the authorization database
  2. Determine the status based on token validity, location, time restrictions, credit, etc.
  3. If the token has a group, include groupIdToken (C09.FR.09)
  4. If the token is restricted to specific EVSEs, include evseId array
  5. Set cacheExpiryDateTime if the token should expire in the CS cache
  6. For ISO 15118 with certificate: validate the certificate chain and set certificateStatus

3.3 TransactionEventRequest (CS -> CSMS)

Sent by the Charging Station to report transaction lifecycle events. May contain idToken.

Charging Station --> CSMS
TransactionEventRequest 
{
  "eventType": "Started",                         // REQUIRED: Started | Updated | Ended
  "timestamp": "2025-01-15T10:30:00Z",           // REQUIRED
  "triggerReason": "Authorized",                  // REQUIRED
  "seqNo": 0,                                    // REQUIRED, integer
  "transactionInfo": {                            // REQUIRED
    "transactionId": "uuid-string",
    "chargingState": "Charging",                  // optional
    "timeSpentCharging": 3600,                    // optional, seconds
    "stoppedReason": "Local",                     // optional, only when eventType=Ended
    "remoteStartId": 123                          // optional
  },
  "idToken": {                                    // optional
    "idToken": "AABBCCDD",
    "type": "ISO14443"
  },
  "evse": { "id": 1, "connectorId": 1 },         // optional
  "meterValue": [...],                            // optional
  "offline": false,                               // optional
  "numberOfPhasesUsed": 3,                        // optional
  "cableMaxCurrent": 32,                          // optional
  "reservationId": 123                            // optional
}
ChargingStateEnumType values
Value Description
Charging EV is charging (energy is flowing)
EVConnected EV is connected but not charging
SuspendedEV Charging suspended by EV
SuspendedEVSE Charging suspended by EVSE
Idle No EV connected
TriggerReasonEnumType values
Value When Sent
Authorized EV Driver has been authorized
CablePluggedIn Cable plugged in
ChargingRateChanged Charging rate has changed
ChargingStateChanged Charging state has changed
Deauthorized Authorization has been revoked
EnergyLimitReached Energy limit reached
EVCommunicationLost Communication with EV lost
EVConnectTimeout EV connection timeout
EVDeparted EV departed (parking bay)
EVDetected EV detected (parking bay)
MeterValueClock Clock-aligned meter value sample
MeterValuePeriodic Periodic meter value sample
RemoteStart Remote start requested
RemoteStop Remote stop requested
ResetCommand Reset command received
SignedDataReceived Signed meter data received
StopAuthorized Stop authorization received
TimeLimitReached Time limit reached
Trigger Triggered by TriggerMessage
UnlockCommand Unlock command received
AbnormalCondition Abnormal condition detected
ReasonEnumType (stoppedReason) values
Value When Used
DeAuthorized Transaction deauthorized by CSMS (C15)
EmergencyStop Emergency stop button pressed
EnergyLimitReached Energy limit of transaction reached
EVDisconnected EV disconnected
GroundFault Ground fault detected
ImmediateReset Immediate reset command received
Local Stopped locally (unplug, stop button)
LocalOutOfCredit Local credit limit reached
MasterPass Stopped by Master Pass (C16)
Other Other reason
OvercurrentFault Overcurrent fault detected
PowerLoss Power loss detected
PowerQuality Power quality issue
Reboot Charging Station rebooting
Remote Stopped by CSMS via RequestStopTransaction
SOCLimitReached State of Charge limit reached
StoppedByEV Stopped by EV
TimeLimitReached Time limit reached
Timeout Transaction timed out

3.4 TransactionEventResponse (CSMS -> CS)

The CSMS responds to acknowledge the transaction event. Can include updated authorization info.

CSMS --> Charging Station
TransactionEventResponse 
{
  "totalCost": 15.50,                             // optional, only when Ended
  "chargingPriority": 0,                          // optional, overrides IdTokenInfo priority
  "idTokenInfo": {                                // optional
    "status": "Accepted",
    "groupIdToken": {
      "idToken": "GROUP001",
      "type": "Central"
    }
  },
  "updatedPersonalMessage": {                     // optional
    "format": "UTF8",
    "content": "Charging in progress..."
  }
}

CSMS implementation logic for TransactionEventResponse:

  1. Always: Acknowledge receipt (even an empty {} response is valid)
  2. On eventType=Started with idToken: Validate the token and return idTokenInfo with authorization status (C12.FR.03)
  3. On eventType=Ended: Optionally include totalCost (omit = not free, 0.00 = free)
  4. If token has groupIdToken: Include it in the response (C09.FR.12)
  5. If authorization status changed: Return updated idTokenInfo to update the CS cache

3.5 RequestStartTransactionRequest (CSMS -> CS)

The CSMS can initiate a transaction remotely.

CSMS --> Charging Station
RequestStartTransactionRequest 
{
  "remoteStartId": 123,                           // REQUIRED, integer
  "idToken": {                                    // REQUIRED
    "idToken": "USER001",
    "type": "Central"
  },
  "evseId": 1,                                   // optional
  "groupIdToken": {                               // optional
    "idToken": "GROUP001",
    "type": "Central"
  },
  "chargingProfile": { ... }                      // optional
}

3.6 RequestStartTransactionResponse (CS -> CSMS)

Charging Station --> CSMS
RequestStartTransactionResponse 
{
  "status": "Accepted",                           // REQUIRED: Accepted | Rejected
  "statusInfo": {                                  // optional
    "reasonCode": "string (max 20)",
    "additionalInfo": "string (max 512)"
  },
  "transactionId": "uuid-string"                  // optional, only when Accepted
}

3.7 ClearCacheRequest (CSMS -> CS)

Used to clear the Authorization Cache on the Charging Station.

CSMS --> Charging Station
ClearCacheRequest 
{}
ClearCacheResponse 
{
  "status": "Accepted",           // REQUIRED: Accepted | Rejected
  "statusInfo": {                  // optional
    "reasonCode": "string (max 20)",
    "additionalInfo": "string (max 512)"
  }
}

4. Authorization Flows

Use Cases C01-C16
C01

EV Driver Authorization using RFID

Authorize an EV Driver who presents an RFID card at the Charging Station.

Actors: Charging Station, CSMS, EV Driver

Flow:

  1. EV Driver presents RFID card (ISO14443 or ISO15693)
  2. Charging Station sends AuthorizeRequest with idToken.type = ISO14443 or ISO15693
  3. CSMS validates the token and returns AuthorizeResponse
  4. If Accepted: Charging Station proceeds with transaction
  5. Charging Station sends TransactionEventRequest(eventType=Started, triggerReason=Authorized)
  6. CSMS responds with TransactionEventResponse

CSMS Responsibilities:

  • Receive AuthorizeRequest
  • Look up idToken.idToken (case-insensitive) in the authorization database
  • Return AuthorizeResponse with appropriate idTokenInfo.status
  • Include groupIdToken if the token belongs to a group (C09.FR.09)
  • Include evseId array if the token is restricted to specific EVSEs
  • Set cacheExpiryDateTime to control how long the CS caches this authorization

Requirements (CSMS-relevant):

ID Requirement
C01.FR.01 CS SHALL send AuthorizeRequest with the presented IdToken
C01.FR.02 AuthorizeResponse SHALL include an authorization status value indicating acceptance or reason for rejection
C01.FR.09 If the IdToken has an associated groupIdToken, AuthorizeResponse SHALL include it
Example AuthorizeRequest 
[2, "msg001", "Authorize", {
  "idToken": {
    "idToken": "AA11BB22",
    "type": "ISO14443"
  }
}]
Example AuthorizeResponse (Accepted) 
[3, "msg001", {
  "idTokenInfo": {
    "status": "Accepted",
    "cacheExpiryDateTime": "2025-12-31T23:59:59Z",
    "groupIdToken": {
      "idToken": "FAMILY001",
      "type": "Central"
    }
  }
}]
Example AuthorizeResponse (Rejected) 
[3, "msg001", {
  "idTokenInfo": {
    "status": "Invalid"
  }
}]
C02

Authorization using a Start Button

Authorize an EV Driver who uses a start button (anonymous authorization).

Flow:

  1. EV Driver presses the start button on the Charging Station
  2. Charging Station sends AuthorizeRequest with idToken.type = NoAuthorization (only if AuthEnabled is true)
  3. CSMS validates and returns AuthorizeResponse
  4. Charging Station starts transaction

CSMS Responsibilities:

  • When receiving idToken.type = NoAuthorization, decide based on business rules whether to accept
  • If anonymous charging is allowed at this location, return Accepted
  • The CSMS might reject if the location requires identification

Note: If AuthEnabled is false on the CS, the CS will not send an AuthorizeRequest at all. The IdToken in the TransactionEventRequest will have type = NoAuthorization.

C03

Authorization using Credit/Debit Card

Authorize using a credit or debit card.

Flow:

  1. EV Driver presents credit/debit card
  2. The payment is handled by an external payment terminal (outside OCPP scope)
  3. Payment terminal communicates result to the CS locally
  4. CS sends TransactionEventRequest(eventType=Started) with the payment reference as idToken
  5. CSMS acknowledges with TransactionEventResponse

CSMS Responsibilities:

  • The actual payment authorization happens outside of OCPP
  • The CSMS receives the TransactionEventRequest with the payment reference
  • The CSMS may or may not validate the payment token depending on the setup
C04

Authorization using PIN-code

Authorize using a PIN code entered on a keypad.

Flow:

  1. EV Driver enters PIN code on the Charging Station keypad
  2. Charging Station sends AuthorizeRequest with idToken.type = KeyCode
  3. CSMS validates PIN and returns AuthorizeResponse
  4. Charging Station starts transaction

CSMS Responsibilities:

  • Receive AuthorizeRequest with idToken.type = KeyCode
  • The idToken.idToken contains the entered PIN code
  • Validate the PIN against the database
  • Return appropriate AuthorizationStatusEnumType
C05

Authorization for CSMS-Initiated Transactions

The CSMS initiates a charging session remotely (e.g., via a mobile app).

Flow:

  1. CSMS sends RequestStartTransactionRequest with idToken and optionally evseId
  2. Charging Station responds with RequestStartTransactionResponse (Accepted/Rejected)
  3. If AuthorizeRemoteStart is true: CS sends AuthorizeRequest to validate the token before starting
  4. CSMS responds to AuthorizeRequest with AuthorizeResponse
  5. CS sends TransactionEventRequest(eventType=Started) - the transactionInfo.remoteStartId matches
  6. CSMS responds with TransactionEventResponse

CSMS Responsibilities:

  • Build and send RequestStartTransactionRequest with: remoteStartId, idToken, evseId (optional), groupIdToken (optional), chargingProfile (optional)
  • If the CS sends an AuthorizeRequest back (when AuthorizeRemoteStart is true), respond with AuthorizeResponse
  • Match the remoteStartId in the subsequent TransactionEventRequest to correlate the transaction

Requirements (CSMS-relevant):

ID Requirement
C05.FR.01 CSMS MAY send RequestStartTransactionRequest to start a transaction
C05.FR.02 The message SHALL contain an idToken
C05.FR.06 If CS has AuthorizeRemoteStart = true, CS SHALL send AuthorizeRequest before starting; CSMS must respond
Example RequestStartTransactionRequest 
[2, "msg010", "RequestStartTransaction", {
  "remoteStartId": 42,
  "idToken": {
    "idToken": "APP_USER_001",
    "type": "Central"
  },
  "evseId": 1
}]
C06

Authorization using Local Id Type

Authorize using a locally generated IdToken (e.g., auto-start, local card reader integration).

Flow:

  1. EV Driver is identified locally
  2. CS sends AuthorizeRequest with idToken.type = Local
  3. CSMS validates and returns AuthorizeResponse

CSMS Responsibilities:

  • Handle idToken.type = Local tokens
  • These are implementation-specific identifiers generated by the Charging Station
  • The CSMS must be able to map these local identifiers to user accounts
C07

Authorization using Contract Certificates (ISO 15118)

Authorize using ISO 15118 Plug & Charge with contract certificates.

Flow:

  1. EV presents contract certificate via ISO 15118 communication
  2. CS sends AuthorizeRequest with: idToken.type = eMAID, certificate (PEM format), iso15118CertificateHashData
  3. CSMS validates the certificate chain and returns AuthorizeResponse
  4. Response includes both idTokenInfo.status AND certificateStatus

CSMS Responsibilities:

  • Validate the eMAID against the authorization database
  • Validate the certificate chain: check expiry, revocation (OCSP), chain integrity
  • Set certificateStatus: Accepted, CertificateExpired, CertificateRevoked, SignatureError, CertChainError, NoCertificateAvailable, ContractCancelled
  • The idTokenInfo.status and certificateStatus are independent decisions

Requirements (CSMS-relevant):

ID Requirement
C07.FR.01 CS SHALL send AuthorizeRequest containing eMAID as IdToken
C07.FR.02 AuthorizeResponse SHALL include both idTokenInfo.status and certificateStatus
C07.FR.06 If CSMS cannot validate the contract certificate: certificateStatus SHALL be set accordingly
C07.FR.07 When the contract certificate is revoked, CSMS SHALL set certificateStatus = CertificateRevoked
C07.FR.08 CSMS SHALL set idTokenInfo.status based on the eMAID validation
C07.FR.09 If the IdToken has an associated groupIdToken, AuthorizeResponse SHALL include it
Example AuthorizeRequest (ISO 15118) 
[2, "msg005", "Authorize", {
  "idToken": {
    "idToken": "FRXYZ123456789A",
    "type": "eMAID"
  },
  "certificate": "-----BEGIN CERTIFICATE-----\nMIIC...\n-----END CERTIFICATE-----",
  "iso15118CertificateHashData": [{
    "hashAlgorithm": "SHA256",
    "issuerNameHash": "abc123...",
    "issuerKeyHash": "def456...",
    "serialNumber": "1234567890",
    "responderURL": "https://ocsp.example.com"
  }]
}]
Example AuthorizeResponse (ISO 15118) 
[3, "msg005", {
  "idTokenInfo": {
    "status": "Accepted",
    "cacheExpiryDateTime": "2025-06-30T23:59:59Z"
  },
  "certificateStatus": "Accepted"
}]
C08

Authorization at EVSE using ISO 15118 EIM

Authorize using ISO 15118 External Identification Means (e.g., RFID combined with ISO 15118 communication).

Flow:

  1. EV Driver presents RFID card while the EV is communicating via ISO 15118
  2. CS sends AuthorizeRequest with the RFID token (type ISO14443 or ISO15693)
  3. CSMS validates and returns AuthorizeResponse
  4. CS uses the authorization result for the ISO 15118 session

CSMS Responsibilities:

  • Same as standard RFID authorization (C01)
  • The CSMS does not need to differentiate between a regular RFID auth and one used for ISO 15118 EIM
  • No certificate validation is needed (unlike C07)
C09

Authorization using GroupId (Parent Id)

Allow multiple IdTokens to share authorization under a single group (e.g., family accounts, fleet management).

Concept:

A groupIdToken links multiple individual IdTokens. If IdToken A and IdToken B share the same groupIdToken, then a user with IdToken B can stop a transaction that was started by IdToken A.

Flow:

  1. User A starts a transaction with IdToken A (CSMS returns groupIdToken = GROUP001)
  2. User B presents IdToken B at the same EVSE
  3. CS sends AuthorizeRequest for IdToken B
  4. CSMS returns AuthorizeResponse with groupIdToken = GROUP001 and status = Accepted
  5. CS recognizes that IdToken B has the same group as the running transaction
  6. CS stops the transaction (or grants access to stop it)

Requirements (CSMS-relevant):

ID Requirement
C09.FR.09 If the IdToken in AuthorizeRequest has an associated groupIdToken, the AuthorizeResponse SHALL include it
C09.FR.10 AuthorizeResponse SHALL include an authorization status value
C09.FR.12 If a TransactionEventRequest contains an idToken with an associated groupIdToken, the TransactionEventResponse SHALL include it
C09.FR.13 The idToken.type of a GroupIdToken SHOULD be Central
Example AuthorizeResponse with GroupIdToken 
[3, "msg002", {
  "idTokenInfo": {
    "status": "Accepted",
    "groupIdToken": {
      "idToken": "FLEET_COMPANY_A",
      "type": "Central"
    }
  }
}]
C10

Store Authorization Data in the Authorization Cache

The Charging Station autonomously caches authorization data received from the CSMS.

This is a Charging Station-side mechanism, but the CSMS controls the cache behavior through the data it returns.

Key CSMS controls over the cache:

Field Effect
cacheExpiryDateTime Sets explicit expiry for this cache entry. Past value = immediately expire/prevent caching.
idTokenInfo.status All statuses are cached (not just Accepted). Non-Accepted entries trigger re-authorization when presented online.
AuthCacheEnabled Controls whether cache is active (via configuration variables)
AuthCacheLifeTime Default cache entry lifetime when no cacheExpiryDateTime is provided

Preventing caching of a token: Set cacheExpiryDateTime to a date-time in the past. This is useful for prepaid accounts that should not be kept in the cache.

C11

Clear Authorization Data in Authorization Cache

CSMS requests the Charging Station to clear its entire Authorization Cache.

Flow:

  1. CSMS sends ClearCacheRequest (empty payload)
  2. CS attempts to clear its cache
  3. CS responds with ClearCacheResponse: Accepted (cache cleared) or Rejected (could not clear OR AuthCacheEnabled is false)

Requirements (CSMS-relevant):

ID Requirement
C11.FR.01 CS SHALL attempt to clear its Authorization Cache
C11.FR.03 If successful, CS sends ClearCacheResponse with Accepted
C11.FR.04 If AuthCacheEnabled is false, CS sends ClearCacheResponse with Rejected
C11.FR.05 If clearing failed, CS sends ClearCacheResponse with Rejected
C12

Start Transaction with Cached Id

EV Driver starts a transaction using a cached (pre-authorized) IdToken.

When a token is in the Authorization Cache with Accepted status, the CS can start charging immediately without sending an AuthorizeRequest. However, the CSMS still validates the token when it receives the TransactionEventRequest.

Flow:

  1. EV Driver presents IdToken
  2. CS finds the token in its Authorization Cache with status Accepted
  3. CS starts charging immediately (no AuthorizeRequest sent)
  4. CS sends TransactionEventRequest(eventType=Started) with idToken
  5. CSMS validates the token and returns TransactionEventResponse with idTokenInfo
  6. If CSMS returns non-Accepted status, CS updates cache and may stop the transaction

Requirements (CSMS-relevant):

ID Requirement
C12.FR.03 CSMS SHALL check authorization status when processing TransactionEventRequest
C12.FR.05 If cached with non-Accepted status (and CS is online), CS SHALL send AuthorizeRequest
C12.FR.06 When IdTokenInfo is received, CS SHALL update its cache
C12.FR.09 IdTokens with groupId equal to MasterPassGroupId SHALL NOT be allowed to start a transaction
C13

Offline Authorization through Local Authorization List

Authorize using the Local Authorization List while the Charging Station is offline.

CSMS Responsibilities:

  • Maintain the Local Authorization List via SendLocalListRequest (see D01)
  • Ensure all valid tokens are in the list with correct statuses
  • Set appropriate cacheExpiryDateTime values for time-limited authorizations

Requirements (CSMS-relevant):

ID Requirement
C13.FR.01 Local Authorization List entries take priority over Authorization Cache entries
C13.FR.02 If OfflineTxForUnknownIdEnabled = false, offline, no expiry support: only Accepted tokens in list are allowed
C13.FR.04 If OfflineTxForUnknownIdEnabled = true, offline, no expiry support: unknown tokens AND Accepted tokens in list are allowed
C13.FR.05 If OfflineTxForUnknownIdEnabled = false, offline, expiry support: only Accepted tokens with non-expired cacheExpiryDateTime are allowed
C13.FR.06 If OfflineTxForUnknownIdEnabled = true, offline, expiry support: unknown tokens AND Accepted non-expired tokens are allowed
C14

Online Authorization through Local Authorization List

Authorize using the Local Authorization List while the Charging Station is online.

When online and LocalPreAuthorize is true, the CS can start charging immediately for tokens found as Accepted in the Local Authorization List, without waiting for an AuthorizeRequest response.

Flow:

  1. EV Driver presents IdToken
  2. CS checks the Local Authorization List
  3. If token is Accepted in the list: CS starts charging immediately
  4. If token is NOT in the list or NOT Accepted: CS sends AuthorizeRequest to CSMS
  5. CSMS validates and responds with AuthorizeResponse
  6. CS sends TransactionEventRequest(eventType=Started) with idToken
  7. CSMS validates and responds with TransactionEventResponse

Requirements (CSMS-relevant):

ID Requirement
C14.FR.01 Local Authorization List entries take priority over Authorization Cache entries
C14.FR.02 If token is Accepted in list (no expiry support or not expired): CS starts without AuthorizeRequest
C14.FR.03 If token in list with status OTHER than Accepted: CS SHALL send AuthorizeRequest
C14.FR.04 If expiry is supported, token is Accepted, and not expired: CS starts without AuthorizeRequest
C14.FR.05 If expiry is supported, token is Accepted, but expired: CS SHALL send AuthorizeRequest
C15

Offline Authorization of Unknown Id

Allow charging for unknown tokens when the CS is offline (controlled by OfflineTxForUnknownIdEnabled).

Flow:

  1. CS is offline
  2. EV Driver presents unknown IdToken (not in Local Authorization List or Authorization Cache)
  3. If OfflineTxForUnknownIdEnabled = true: CS accepts the token and starts charging
  4. If OfflineTxForUnknownIdEnabled = false: CS rejects the token
  5. When CS comes back online: CS sends TransactionEventRequest for offline transactions
  6. CSMS validates the token and responds with TransactionEventResponse

Requirements (CSMS-relevant):

ID Requirement
C15.FR.01 CS SHALL NOT add offline-authorized tokens to the Authorization Cache
C15.FR.02 When online, CS SHALL send TransactionEventRequest for offline transactions
C15.FR.03 If CSMS returns non-Accepted AND StopTxOnInvalidId=true AND no stop point matches: CS stops energy and sends Deauthorized event
C15.FR.04 If CSMS returns non-Accepted AND StopTxOnInvalidId=true AND stop point matches: CS ends transaction with stoppedReason=DeAuthorized
C15.FR.06 If CSMS returns non-Accepted AND StopTxOnInvalidId=false AND MaxEnergyOnInvalidId exceeded: CS suspends
C15.FR.08 If OfflineTxForUnknownIdEnabled=true: CS SHALL accept the unknown token
C16

Stop Transaction with a Master Pass

Enable stopping of transactions using a Master Pass (e.g., for Law Enforcement officials).

Flow:

  1. User presents IdToken at the Charging Station (where transactions are ongoing)
  2. CS sends AuthorizeRequest to CSMS
  3. CSMS responds with AuthorizeResponse where groupIdToken equals the configured MasterPassGroupId
  4. CS recognizes this as a Master Pass authorization
  5. If CS has a UI: shows Master Pass UI to select which transaction(s) to stop
  6. If CS has no UI: stops ALL ongoing transactions
  7. CS sends TransactionEventRequest(eventType=Ended, stoppedReason=MasterPass) for each stopped transaction
  8. CSMS responds with TransactionEventResponse

CSMS Responsibilities:

  • Configure MasterPassGroupId on the Charging Station via configuration variables
  • When receiving AuthorizeRequest for a Master Pass token: validate, return Accepted, include groupIdToken matching MasterPassGroupId
  • Process TransactionEventRequest with stoppedReason = MasterPass
  • Master Pass tokens SHALL NOT be allowed to start a transaction (C16.FR.03)

Requirements (CSMS-relevant):

ID Requirement
C16.FR.01 If CS has UI: SHALL show Master Pass UI to select transactions to stop
C16.FR.02 If CS has no UI: SHALL stop all ongoing transactions
C16.FR.03 Master Pass tokens SHALL NOT be allowed to start a transaction
C16.FR.08 CS SHALL set stoppedReason = MasterPass in TransactionEventRequest(Ended)
Example AuthorizeResponse for Master Pass 
[3, "msg020", {
  "idTokenInfo": {
    "status": "Accepted",
    "groupIdToken": {
      "idToken": "MASTER_PASS_GROUP",
      "type": "Central"
    }
  }
}]

5. Local Authorization List Management

D01-D02

D01 - Send Local Authorization List

Direction: CSMS -> Charging Station

The CSMS can send either a full replacement list or a differential update.

SendLocalListRequest 
{
  "versionNumber": 5,              // REQUIRED, integer > 0
  "updateType": "Full",            // REQUIRED: Full | Differential
  "localAuthorizationList": [      // optional
    {
      "idToken": {                 // REQUIRED
        "idToken": "AABBCCDD",
        "type": "ISO14443"
      },
      "idTokenInfo": {             // optional (absence = delete)
        "status": "Accepted",
        "cacheExpiryDateTime": "2025-12-31T23:59:59Z",
        "groupIdToken": {
          "idToken": "GROUP001",
          "type": "Central"
        }
      }
    }
  ]
}
SendLocalListResponse 
{
  "status": "Accepted",
  // REQUIRED: Accepted | Failed | VersionMismatch
  "statusInfo": {                  // optional
    "reasonCode": "string (max 20)",
    "additionalInfo": "string (max 512)"
  }
}

Update Types:

Type Behavior
Full Replaces the entire list. If localAuthorizationList is empty/absent, clears the list.
Differential Adds/updates/removes individual entries. Entries WITH idTokenInfo are added/updated. Entries WITHOUT idTokenInfo are removed.

CSMS Implementation Logic:

  1. Full update: Send all tokens with their idTokenInfo. The CS replaces its entire list.
  2. Differential update: To add/update a token: include both idToken and idTokenInfo. To remove a token: include only idToken (no idTokenInfo).
  3. Version management: Always increment versionNumber for each update. versionNumber must be > 0.
  4. Error handling: If CS returns Failed or VersionMismatch and the update was Differential, CSMS should resend the full list.
  5. Size constraints: The CS may limit message size via ItemsPerMessageSendLocalList and BytesPerMessageSendLocalList.

Requirements:

ID Requirement
D01.FR.01 SendLocalListRequest SHALL contain updateType and versionNumber
D01.FR.03 If Failed/VersionMismatch on Differential: CSMS SHOULD resend full list
D01.FR.04 Full update with no list: CS SHALL remove all IdTokens
D01.FR.05 Differential with empty list: no effect (version still updated)
D01.FR.06 All IdTokens in the list SHALL be unique
D01.FR.15 Full update with non-empty list: CS SHALL replace its list and set version
D01.FR.16 Differential with entries WITH idTokenInfo: CS SHALL add/update
D01.FR.17 Differential with entries WITHOUT idTokenInfo: CS SHALL remove
D01.FR.18 versionNumber SHALL be > 0
D01.FR.19 Differential with versionNumber <= CS version: CS returns VersionMismatch
Example - Full update 
[2, "msg030", "SendLocalList", {
  "versionNumber": 1,
  "updateType": "Full",
  "localAuthorizationList": [
    {
      "idToken": { "idToken": "USER001", "type": "ISO14443" },
      "idTokenInfo": {
        "status": "Accepted",
        "groupIdToken": { "idToken": "GROUP_A", "type": "Central" }
      }
    },
    {
      "idToken": { "idToken": "USER002", "type": "ISO14443" },
      "idTokenInfo": { "status": "Accepted" }
    },
    {
      "idToken": { "idToken": "USER003", "type": "ISO14443" },
      "idTokenInfo": { "status": "Blocked" }
    }
  ]
}]
Example - Differential add 
[2, "msg031", "SendLocalList", {
  "versionNumber": 2,
  "updateType": "Differential",
  "localAuthorizationList": [
    {
      "idToken": { "idToken": "USER004", "type": "ISO14443" },
      "idTokenInfo": { "status": "Accepted" }
    }
  ]
}]
Example - Differential remove 
[2, "msg032", "SendLocalList", {
  "versionNumber": 3,
  "updateType": "Differential",
  "localAuthorizationList": [
    {
      "idToken": { "idToken": "USER003", "type": "ISO14443" }
    }
  ]
}]
Example - Clear entire list 
[2, "msg033", "SendLocalList", {
  "versionNumber": 4,
  "updateType": "Full"
}]

D02 - Get Local List Version

Direction: CSMS -> Charging Station

CSMS queries the current version of the Local Authorization List on a Charging Station.

GetLocalListVersionRequest 
{}
GetLocalListVersionResponse 
{
  "versionNumber": 5   // REQUIRED, integer
}

CSMS Responsibilities:

  • Send GetLocalListVersionRequest before updating to determine the current version
  • versionNumber = 0 means: no Local Authorization List installed
  • Use the response to decide whether a Full or Differential update is needed
ID Requirement
D02.FR.01 If LocalAuthListEnabled = true: CS SHALL respond with its list version
D02.FR.02 If enabled but no update ever received: CS responds with versionNumber = 0
D02.FR.03 If LocalAuthListEnabled = not true: CS responds with versionNumber = 0

6. Configuration Variables Reference

Config

These are configuration variables on the Charging Station that affect authorization behavior. The CSMS can read/write these via GetVariables/SetVariables messages.

Authorization Related (AuthCtrlr)

Variable Type Mutability Description
AuthEnabled boolean ReadWrite If false, no authorization is done before starting a transaction. IdToken type will be NoAuthorization.
AdditionalInfoItemsPerMessage integer ReadOnly Max additionalInfo items per message. CSMS expected to handle arbitrary amounts.
OfflineTxForUnknownIdEnabled boolean ReadWrite If true, CS accepts unknown tokens when offline.
AuthorizeRemoteStart boolean RO/RW If true, CS sends AuthorizeRequest before starting a remote transaction.
LocalAuthorizeOffline boolean ReadWrite If true, CS starts transactions for locally-authorized tokens when offline.
LocalPreAuthorize boolean ReadWrite If true, CS starts transactions for locally-authorized tokens immediately when online.
MasterPassGroupId string ReadWrite GroupId value that identifies Master Pass tokens.
DisableRemoteAuthorization boolean ReadWrite If true, CS does not send AuthorizeRequests and only uses Cache/Local List.
SupportedIdTokenTypes MemberList ReadOnly Subset of IdTokenEnumType supported by the CS.

Authorization Cache Related (AuthCacheCtrlr)

Variable Type Mutability Description
AuthCacheEnabled boolean ReadWrite Enables/disables the Authorization Cache.
AuthCacheAvailable boolean ReadOnly Whether Authorization Cache is supported.
AuthCacheLifeTime integer (s) ReadWrite How long a token stays in cache since last used.
AuthCacheStorage integer ReadOnly Bytes used by cache (maxLimit = max capacity).
AuthCachePolicy OptionList ReadWrite Cache replacement policy: LRU, LFU, FIFO, CUSTOM.
AuthCacheDisablePostAuthorize boolean ReadWrite If true, disables re-authorization for non-Accepted cached tokens.
AuthCacheEntries integer ReadOnly Number of entries in cache (maxLimit = max capacity).

Local Authorization List Related (LocalAuthListCtrlr)

Variable Type Mutability Description
LocalAuthListEnabled boolean ReadWrite Enables/disables the Local Authorization List.
LocalAuthListEntries integer ReadOnly Number of entries (maxLimit = max capacity).
LocalAuthListAvailable boolean ReadOnly Whether Local Authorization List is supported.
ItemsPerMessageSendLocalList integer ReadOnly Max items in a single SendLocalListRequest.
BytesPerMessageSendLocalList integer ReadOnly Max bytes for a SendLocalListRequest.
LocalAuthListStorage integer ReadOnly Bytes used (maxLimit = max capacity).
LocalAuthListDisablePostAuthorize boolean ReadWrite If true, disables re-authorization for non-Accepted local list tokens.
LocalAuthListSupportsExpiryDateTime boolean ReadOnly If true, CS enforces cacheExpiryDateTime in local list.

Transaction Related (TxCtrlr)

Variable Type Mutability Description
TxStartPoint MemberList RO/RW Events that trigger TransactionEventRequest(Started). Values: ParkingBayOccupancy, EVConnected, Authorized, PowerPathClosed, EnergyTransfer, DataSigned
TxStopPoint MemberList RO/RW Events that trigger TransactionEventRequest(Ended). Same values as TxStartPoint.
EVConnectionTimeOut integer (s) ReadWrite Timeout for EV to connect after authorization.
StopTxOnInvalidId boolean ReadWrite If true, stop transaction when CSMS returns non-Accepted for a previously offline-authorized token.
MaxEnergyOnInvalidId integer (Wh) ReadWrite Max energy allowed when token is invalid but StopTxOnInvalidId = false.
StopTxOnEVSideDisconnect boolean RO/RW If true, deauthorize when cable is unplugged.

7. CSMS Implementation Decision Matrix

Implementation

When Receiving AuthorizeRequest

Decision Tree 
AuthorizeRequest received
    |
    +-- Look up idToken (case-insensitive) in database
    |
    +-- Token found?
    |   |
    |   +-- YES: Check token validity
    |   |   |
    |   |   +-- Valid? -> status = "Accepted"
    |   |   +-- Blocked? -> status = "Blocked"
    |   |   +-- Expired? -> status = "Expired"
    |   |   +-- No credit? -> status = "NoCredit"
    |   |   +-- Wrong location? -> status = "NotAtThisLocation"
    |   |   +-- Wrong time? -> status = "NotAtThisTime"
    |   |   +-- Wrong EVSE type? -> status = "NotAllowedTypeEVSE"
    |   |   +-- Active transaction? -> status = "ConcurrentTx"
    |   |
    |   +-- Has groupIdToken? -> Include in response
    |   +-- Has EVSE restrictions? -> Include evseId array
    |   +-- Has certificate? -> Validate and set certificateStatus
    |
    +-- NO: status = "Invalid"
    |
    +-- Set cacheExpiryDateTime (controls CS cache behavior)
    +-- Set personalMessage (optional display message)
    +-- Return AuthorizeResponse

When Receiving TransactionEventRequest

Decision Tree 
TransactionEventRequest received
    |
    +-- eventType = "Started"?
    |   |
    |   +-- Has idToken?
    |   |   |
    |   |   +-- Validate token -> Return idTokenInfo in response
    |   |   +-- Has groupIdToken? -> Include in response
    |   |   +-- Is MasterPass token? -> Return non-Accepted (C16.FR.03)
    |   |
    |   +-- Record transaction start (transactionId, EVSE, timestamp)
    |
    +-- eventType = "Updated"?
    |   |
    |   +-- Has idToken? -> Re-validate, return updated idTokenInfo
    |   +-- Update transaction state (chargingState, meterValue)
    |
    +-- eventType = "Ended"?
    |   |
    |   +-- Record transaction end
    |   +-- Calculate totalCost (optional)
    |   +-- stoppedReason = "MasterPass"? -> Log Master Pass stop
    |   +-- stoppedReason = "DeAuthorized"? -> Log deauth reason
    |   +-- Return totalCost (omit = not free, 0.00 = free)
    |
    +-- Check seqNo for completeness (ensure no gaps)
    +-- Return TransactionEventResponse

When to Send RequestStartTransactionRequest

Decision Tree 
Remote start trigger (e.g., mobile app request)
    |
    +-- Build RequestStartTransactionRequest
    |   |
    |   +-- remoteStartId: unique integer
    |   +-- idToken: the user's token (type = "Central")
    |   +-- evseId: specific EVSE (optional)
    |   +-- groupIdToken: if user belongs to a group (optional)
    |   +-- chargingProfile: if specific charging constraints (optional)
    |
    +-- Send to Charging Station
    |
    +-- Response = "Accepted"?
    |   |
    |   +-- YES: Wait for TransactionEventRequest(Started) with matching remoteStartId
    |   +-- NO: Inform user that remote start was rejected
    |
    +-- If AuthorizeRemoteStart = true:
        CS will send AuthorizeRequest -> Respond with AuthorizeResponse

When to Send SendLocalListRequest

Decision Tree 
List update needed (new user, blocked user, periodic sync)
    |
    +-- Get current version: Send GetLocalListVersionRequest
    |
    +-- versionNumber = 0? (no list installed)
    |   |
    |   +-- Send Full update with all tokens
    |
    +-- Small change?
    |   |
    |   +-- Send Differential update (add/update/remove specific tokens)
    |   +-- versionNumber must be > CS's current version
    |
    +-- Large change or full sync needed?
    |   |
    |   +-- Send Full update
    |   +-- If too large for one message:
    |       +-- Send initial Full (first batch)
    |       +-- Send subsequent Differential updates until complete
    |
    +-- Response = "VersionMismatch"?
    |   |
    |   +-- Resend as Full update
    |
    +-- Response = "Failed"?
        |
        +-- Resend as Full update

OCPP 2.0.1 Authorization Flows - CSMS Developer Guide. Based on OCPP 2.0.1 Edition 4 Specification (Part 2).