Explanations use OCPI 2.2.1. Physical and billing-system events are authored examples.
CPO requests real-time authorization
Advanced
4 min
CPO requests real-time authorizationExplore the tokens module →
The token's whitelist value is NEVER, so the CPO asks the eMSP to authorize it in real time, naming the location and EVSE the driver wants to use.
No sandbox run sends this exchange, so there is nothing to run here.
CPO
EMSP
Valid protocol example
The eMSP refuses the token: it has expired, so charging is not authorized at this location.
For this authenticated request for a known Token, HTTP 200 with status_code 1000 and allowed = EXPIRED is a valid refusal example. Unknown Tokens instead have the explicit HTTP 404 and OCPI 2004 response without data. A response without allowed, or without the complete Token, would not be a valid AuthorizationInfo object.
"When the token is known by the Sender, the response SHALL contain a AuthorizationInfo object. If the token is not known, the response SHALL contain the status code: `2004: Unknown Token`, and no `data` field."OCPI 2.2.1 Tokens module · #mod_tokens_post_response_data"|ALWAYS |Token always has to be whitelisted, realtime authorization is not possible/allowed. CPO shall always allow any use of this Token. |ALLOWED |It is allowed to whitelist the token, realtime authorization is also allowed. The CPO may choose which version of authorization to use. |ALLOWED_OFFLINE |In normal situations realtime authorization shall be used. But when the CPO cannot get a response from the eMSP (communication between CPO and eMSP is offline), the CPO shall allow this Token to be used. |NEVER |Whitelisting is forbidden, only realtime authorization is allowed. CPO shall always send a realtime authorization for any use of this Token to the eMSP."OCPI 2.2.1 Tokens module · #mod_tokens_whitelisttype_enum"If a request is syntactically valid JSON and addresses an existing resource, and comes from a sender that is successfully authenticated and authorized, this request is supposed to have reached the OCPI layer. To such a request, an HTTP error status code MUST NOT be returned."OCPI 2.2.1 Status codes chapter · #status_codes_status_codes"|allowed |AllowedType |1 |Status of the Token, and whether charging is allowed at the optionally given location. |token |Token |1 |The complete Token object for which this authorization was requested. |location |LocationReferences |? |Optional reference to the location if it was included in the request, and if the EV driver is allowed to charge at that location. Only the EVSEs the EV driver is allowed to charge at are returned. |authorization_reference |CiString(36) |? |Reference to the authorization given by the eMSP, when given, this reference will be provided in the relevant Session and/or CDR. |info |DisplayText |? |Optional display text, additional information to the EV driver."OCPI 2.2.1 Tokens module · #mod_tokens_authorizationinfo_object"|country_code |CiString(2) |1 |ISO-3166 alpha-2 country code of the MSP that 'owns' this Token. |party_id |CiString(3) |1 |ID of the eMSP that 'owns' this Token (following the ISO-15118 standard). |uid |CiString(36) |1 |Unique ID by which this Token, combined with the Token type, can be identified. + This is the field used by CPO system (RFID reader on the Charge Point) to identify this token. + Currently, in most cases: type=RFID, this is the RFID hidden ID as read by the RFID reader, but that is not a requirement. + If this is a `APP_USER` or `AD_HOC_USER` Token, it will be a uniquely, by the eMSP, generated ID. + This field is named `uid` instead of `id` to prevent confusion with: `contract_id`. |type |TokenType |1 |Type of the token |contract_id |CiString(36) |1 |Uniquely identifies the EV Driver contract token within the eMSP's platform (and suboperator platforms). Recommended to follow the specification for eMA ID from "eMI3 standard version V1.0" (http://emi3group.com/documents-links/[http://emi3group.com/documents-links/]) "Part 2: business objects." |visual_number |string(64) |? |Visual readable number/identification as printed on the Token (RFID card), might be equal to the contract_id. |issuer |string(64) |1 |Issuing company, most of the times the name of the company printed on the token (RFID card), not necessarily the eMSP. |group_id |CiString(36) |? |This ID groups a couple of tokens. This can be used to make two or more tokens work as one, so that a session can be started with one token and stopped with another, handy when a card and key-fob are given to the EV-driver. + Beware that OCPP 1.5/1.6 only support group_ids (it is called parentId in OCPP 1.5/1.6) with a maximum length of 20. |valid |boolean |1 |Is this Token valid |whitelist |WhitelistType |1 |Indicates what type of white-listing is allowed. |language |string(2) |? |Language Code ISO 639-1. This optional field indicates the Token owner's preferred interface language. If the language is not provided or not supported then the CPO is free to choose its own language. |default_profile_type |ProfileType |? | The default Charging Preference. When this is provided, and a charging session is started on an Charge Point that support Preference base Smart Charging and support this ProfileType, the Charge Point can start using this ProfileType, without this having to be set via: Set Charging Preferences. |energy_contract |EnergyContract |? |When the Charge Point supports using your own energy supplier/contract at a Charge Point, information about the energy supplier/contract is needed so the CPO knows which energy supplier to use. + NOTE: In a lot of countries it is currently not allowed/possible to use a drivers own energy supplier/contract at a Charge Point. |last_updated |DateTime |1 |Timestamp when this Token was last updated (or created)."OCPI 2.2.1 Tokens module · #mod_tokens_token_object"|ALLOWED |This Token is allowed to charge (at this location). |BLOCKED |This Token is blocked. |EXPIRED |This Token has expired. |NO_CREDIT |This Token belongs to an account that has not enough credits to charge (at the given location). |NOT_ALLOWED |Token is valid, but is not allowed to charge at the given location."OCPI 2.2.1 Tokens module · #mod_tokens_allowed_enum"When the eMSP does not know the Token, the eMSP SHALL respond with an HTTP status code: 404 (Not Found)."OCPI 2.2.1 Tokens module · #mod_tokens_post_method
Message FlowStep 2 of 3