Managing BlueID Tokens
Managing BlueID Tokens
Overview
A BlueID Token is a digital permission defining what and how one smart device may interact with a certain secured objects during a specific time period. They can easily be created via the BlueID Operator API. We refer to the Operator API documentation for more details. Nevertheless, there are some aspects, like usability for your customers and security, that you should keep in mind while creating your own BlueID Tokens. In the following we give some recommendations for creating your own BlueID Tokens.
Recommendations
Before discussing three different use cases, we want to give some general recommendations for creating BlueID Tokens.
-
Divide your customer's permissions of your system into several concurrent BlueID Tokens
-
Use an overlap for two concurrent BlueID Tokens
-
Do not create all BlueID Tokens of a permission at once
-
Save the BlueID Token ID in your system
-
Create your BlueID Tokens in the backend, not on the smart device
-
Sync the smart device often and automatically
-
Use an additional delta for the begin and end date of your BlueID Token
-
Do not use an end date far in the future for your BlueID Token
In general, you want to divide a permission of your system into several concurrent BlueID Tokens for security reasons. Assume that a customer has a permission for one year. If each BlueID Token is only valid for e.g. one day, then the customer has only one valid BlueID Token for a single day on the smart device. Therefore, in the case that the customer looses the smart device, an unauthorized person could only use this BlueID Token for one day. In addition, we recommend having an overlap between two concurrent BlueID Tokens. You want to ensure that a valid BlueID Token is always available on the smart device. The longer the overlap, the more time does the customer have to (automatically or manually) synchronize with the BlueID trust center. We recommend having an overlap between two concurrent BlueID Tokens of at least 4 hours or about 20% of the time period a single BlueID Token is valid. It is worthwhile to mention that currently all current or future valid BlueID Tokens will be downloaded to the smart device. For example, three concurrent BlueID Tokens that are each valid for one day is equivalent to one BlueID Tokens that is valid for three days. Therefore, you should create your BlueID Tokens shortly before they are needed. \ Furthermore, BlueID Tokens should only be created in your backend system. If you create your BlueID Tokens on the smart device, an attacker could extract your credentials easily. Please save the BlueID Token ID with your backend system in order to easily revoke a BlueID Token. \ Since a BlueID Token needs to be downloaded by the smart device, the smart device should be synchronized with the BlueID trust center often and automatically. It is worthwhile to mention that invalid or revoked BlueID Tokens will be removed as well from the smart device while you synchronize with the BlueID trust center. This provides an additional level of security to your system. Note, the shorter your BlueID Tokens are valid, the more often you should synchronize the smart device with the BlueID trust center. \ Last but not least, you should add an additional delta to the start and end date of your BlueID Token since the time provider within your secured object might not be as accurate as the time within your backend system. We recommend having an additional delta of 5 minutes. Please note that we strongly discourage you using BlueID Tokens having an end date far in the future.
Token Status and lookup
Tokens can acquire different status during their lifetime:
Valid: a Token issued for an existing MobileDeviceID, whose start date is in the past and whose end date has not been reached yet
Revoked: a Token for whom a previously granted permission to access a specific SecuredObject has been revoked by the Tenant
Removed: a Token whose revocation reached the lock through BlueID viral revocation mechanism and the Lock acknowledgement has been sent back to the Backend
Expired: a Token whose end date is in the past, no matter the previous status
Canceled: a Token deleted from a NFC card by assigning the card to another resident
30 days after expiry, Tokens are removed from the production table and stored in a Backup table for emergency lookup.
Use case 1: facility
In general, granting access is usually done for a longer period (e.g. 3 months). Hence, we recommend using BlueID Tokens that are valid for one week having an overlap between two concurrent BlueID Tokens of one day.
Use case 2: car sharing
Assuming that the smart devices of the customers can be synchronized with the BlueID trust center every 24-48 hours, we recommend to you the following
-
BlueID Tokens are valid for 48 hours with an overlap between two concurrent BlueID Tokens of 24 hours
-
Use of a grace period (depending of the business case) at the end of the booking
-
Revoking the BlueID Tokens when returning the car
Firstly, we recommend creating BlueID Tokens that are valid for about 2 days with an overlap between two concurrent BlueID Tokens of 24 hours. If you have different assumptions about the possibility of the smart devices for synchronizing with the BlueID trust center, you can change the BlueID Token length and overlap between two concurrent BlueID Tokens accordingly. Secondly, you should define a grace period for returning the car, i.e. you should define the time that the customer has for returning the car. Depending on your use case the grace period could be a few minutes as well as one or two days. Moreover, you could define two different grace periods. One for opening and starting and one for closing the car. Of course, the grace period for closing the car should be at least as long as the one for opening and starting.\ Once the customer returns the car, the BlueID Tokens should be revoked as well. We recommend having some kind of user interaction on the smart device in order to synchronize the smart device with the BlueID trust center, i.e. the revoked BlueID Tokens can be removed from the smart device. \ It is worthwhile to mention that in some rare corner cases the smart devices cannot be synchronized with the BlueID trust center within 24-48 hours. We recommend having some kind of user interaction for the customer during the booking process. Afterwards you create the BlueID Tokens accordingly.
Use case 3: parking
In general, granting access is usually done for a longer period (e.g. 3 months). Hence, we recommend using BlueID Tokens that are valid for one week having an overlap between two concurrent BlueID Tokens of one day.