Intro
This article provides an overview on all main steps involved in the process of adding a token in EvPortal. When needed, further references to more in-depth articles are made.
The article focuses on the process of creating a single token. For checking the process to import tokens in batch, check this article.
EvPortal User Requirements:
- Permission: 'Create:Token'
- Roles (example): Admin, eMSP Manager
High Level Process
For additional details on each one of the steps refer to the instructions hereunder.
Step 3 in detail
Follow the wizard and provide the required information.
'Details' Tab
Section/Field | Description/Functionality/Options |
1. Driver - Driver | Pick the driver under which the token will be associated. Only one possible. |
2. Token Information - Token Type | Two options available:
1. RFID: This represents physical tokens, which traditionally are RFID cards, but could also be for instance key fobs
2. Other: In this option the only authentication method will be remotelly through an app, or this tokens could also be used to start a session through EvPortal |
2. Token Information - Auth ID | The auth ID must follow specification eMA ID syntax/structure. As a dummy example, we could have have a token auth Id as follows: NL-GFX-C0B34A240-H |
Check section at the end to know more about the eMA ID syntax and how you can calculate it
Section | Description/Functionality/Options |
2. Token Information - Visual ID | Visual ID is arbitrary. We suggest using the same as the Auth-ID, but if required to be simplified (to keep it short when printed in the physical card), an abbreviation of the 8 ALPHA/DIGIT (mentioned above in Auth ID) could be used instead. In case the token represents an RFID card, then the visual ID is typically the reference printed in the card. |
2. Token Information - Chip ID | This will depend in the option chosen in the token type:
1. RFID card: in this case, we should put here the chip that uniquely identifies the RFID card/key fob;
2. Other: in this case, we should define the chip ID with the randomize feature, in order to make sure we define a unique chip ID.Note: When providing chip IDs for physical tokens, be sure to provide it "Little Endian" Format (e.g. 55AC89BCZZP4). There are other formats like Big Endian and middle endian (e.g. 58:C7:DZ:V8:22), but which GreenFlux does not support. |
3. Token Status - Token Authentication | Enable the toggle to set the token to Active status |
'Billing' Tab
Section/Field | Description/Functionality/Options |
2. Roaming Active - Roaming Enabled | |
3. Billing Type | Two options:
1. Post-paid: This is the most common choice.
2. Pre-paid: This is a beta option, check with your CSM if it's suitable to your Use Case |
'Groups' Tab
For details about groups, check this page and go the Groups section: Add a Driver (greenflux.com)
'Finalize' Tab
Review all the data that you have introduced and press Save. After that, you have added a new token.
eMA ID Syntax explanation and useful tools
eMA ID syntax is adopted widely in mobility sector and it defines the structure under which the auth id property must be defined.
The full details about it are available here, page 17.
The eMA ID structure is as follows:
<eMA ID> =
Auth ID
= <Country Code> - <Provider ID> - <ID Type> <eMA Instance> - <Check Digit>, where:
- <Country Code> this is inherited from your EMSP contract (e.g. NL, which stands for the Netherlands)
- <Provider ID> this is inherited as well from your EMSP contract (e.g. GFX, which stands for GreenFlux, which some partners may adopt for their operations)
- <ID Type> this is always 'C', which represents a reference to a contract
- <eMA Instance> this should be eight alphanumeric characters referring to the internal service contract between EVSP and its customer. When operators don't have such reference defined (or perhaps you as operator make that link at driver/customer level in the data model, then you should use a random sequence of eight alphanumeric.
- <Check Digit> this is generated by a certain algorithm. Use the below link to calculate check digits:
Check digit calculation: Follow this link to obtain an excel sheet where you can create check digits
Even though the check digit is not mandatory, according to the explanation of the eMI3 standard (link above, page 17), GreenFlux strongly recommends to include it, as some partners in the roaming ecosystem define it as mandatory.
In order to import tokens in batch, more details here Private Location Authorization Management