Tokens

The Tokens module: synchronising tokens for whitelist authorization, the methods per role and the Token object.

On this page

Technical considerations

The EMSP shall ensure that the tokens required for whitelist-based authorization are correctly synchronized with the MOBI.Hub whenever this authorization model is used.

The MOBI.Hub HUB supports both whitelist-based authorization and real-time authorization, depending on the operational model selected by the EMSP. In a Classic Hub model, token information may be exchanged and managed according to the applicable OCPI flows. In a Centralized Authentication model using real-time authorization, tokens do not need to be synchronized with the MOBI.Hub, as authorization is performed against the EMSP in real time.

MOBI.Hub MAY perform a GET request to retrieve the full list of tokens available for a given EMSP when whitelist-based authorization is used. However, it is not the obligation of MOBI.Hub to perform this operation and the EMSP shall ensure that the token information made available to the HUB is kept up to date.

Token creation or updates are not necessarily routed directly to CPOs. Depending on the selected authorization model and the applicable OCPI flows, token information may be used by MOBI.Hub for authorization purposes without requiring the CPO to receive the complete Token object.

Methods to be implemented

MOBI.Hub – Receiver

`Tokens` methods for the MOBI.Hub – Receiver
Method	Direction	Description of usage
`GET`	Response	The EMSP shall be able to retrieve its tokens as they are defined on MOBI.Hub.
`PUT`	Response	The EMSP shall be able to create a new or update an existing token
`PATCH`	Response	Partially update the token

EMSP – Sender

`Tokens` methods for the EMSP – Sender
Method	Direction	Description of usage
`GET`	Request	The EMSP shall be able to retrieve its tokens
`PUT`	Request	The EMSP shall be able to create a new or update an existing token
`PATCH`	Request	Partially update the token

Objects description

Description of the Token object:

`Token` object properties
Property	Mandatory	Value	Comments
`country_code`	TRUE	`PT`
`party_id`	TRUE
`uid`	TRUE		`internal_number` if `type=RFID`. In this case, the direct decimal format should be considered. If type is `AD_HOC_USER` or `APP_USER`, then it is advisable that an integer with less than 19 digits is used. So as to ensure unicity it is recommended that the following format be used: concatenations between current time in milliseconds (13 digits) and 5 random digits. This is not mandatory. In case a `uid` already exists and does not belong to the EMSP, MOBI.Hub will respond with an error message.
`type`	TRUE	`AD_HOC_USER` `APP_USER` `RFID`
`contract_id`	TRUE		<Country Code> = “AA” <Party ID> = “AAA” <Separator> = - <ID Type> = “C” -<eMA Instance> = 8 (ALPHA / DIGIT) Each EMSP is completely free to define its 8 alphanumeric structures for its e-mobility contracts. As an example, an MOB e-mobility contract coded with “1234ABCD” would have a corresponding `contract_ID` of: `PT-MOB-C1234ABCD-J`. Check-digit is optional, although if it is used it must a correct one.
`issuer`	TRUE		Card/token issuer name. Can be freely defined by the EMSP.
`valid`	TRUE
`whitelist`	TRUE
`last_updated`	TRUE