Privacy Leaflet

About this document

This document covers data protection and privacy topics related to Bosch IoT Permissions. It discusses how Bosch IoT Permissions acquires, processes, shares, and deletes user related data within the service, as well as in interaction with your custom IoT application. It is provided as an information source for your application-specific data protection concept, and aims to support application developers who need to compile such documents focused on their own interfaces.


Privacy by Design and Privacy by Default

Bosch IoT Permissions

Privacy by Design and Privacy by Default is provided by Bosch IoT Permissions:

It is ensured that only the required amount of data sets is stored
The service does not save or create any extra data

Personal data can be deleted after elimination of the purpose
Your application can delete any data which was stored in the service

Log files are deleted after their purpose has been removed. Access and integrity of log files is protected.
Technical logs are deleted automatically after 90 days. Access to the logs is limited to the operators of the service (Bosch Software Innovations GmbH, Robert Bosch GmbH).

In development and not yet available:

Accesses, changes, deletions of personal data are recorded according to their protection requirements:
A change to a user entity can be logged to a privacy audit log. The logged entries will be deleted automatically after a defined retention period.

Your application is responsible

Check that your service implements Privacy by Design and Privacy by Default together with Bosch IoT Permissions:

Only personal data are processed, the processing of which is necessary for the respective processing purpose. This is ensured by default.
This has to be ensured by your application. The service requires username and password as a minimal set of data (see Manage user accounts).

Data have been pseudonymized or anonymized
Your application can apply this practice, e.g. requesting a pseudonym as username (see Manage user accounts).

Access rights to personal data have been implemented in such a way that the person concerned can view or modify his / her data. Furthermore, access to personal data is restricted to users with data processing tasks.
This can be provided by your application using the service API.  

The data subject has the possibility to determine which of his data is processed.
This can be provided by your application. It is not covered by the service.

Service measures

This is a list of privacy and security measures which are implemented in the Bosch IoT Permissions service.

The measures are classified into these categories:

  • Privacy
  • Integrity
  • Availability
  • Reliability

Privacy

  • Communication with service is encrypted with TLS/SSL
  • Authentication needed to access any data
  • Authentication rate is limited to prevent brute force attacks
  • Role-based access control manageable by service customer
  • Privileged user concept to prevent privilege escalation
  • Logical separation of tenant data
  • Audit log data is encrypted at rest

Integrity

  • The last change of an entity is logged (date and user)
  • Role-based management of write access
  • Encrypted service communication
  • User access rights can be requested as JWT, which can be verified with public key cryptography (as recommended by the JWT specification draft)
  • Uniqueness of data entity identifiers is ensured

Availability

  • Service runs in 2 different operation centers redundantly (BIC DE1 Stuttgart)
  • Continuous monitoring
  • Automatic alerting of service engineers in case of an incident
  • Data backups are available

Reliability

  • Service is checked for security vulnerabilities regularly by external pen testers
  • Request rate for each client is limited to ensure reliability of the service for all customers
  • Software is scanned for security vulnerabilities continuously in development
  • Running in a Bosch Data Center (BIC DE1 Stuttgart)


Privacy considerations - use cases

This section lists common use cases supported within the Bosch IoT Permissions service.
Each use case description discusses which type of user related data is processed by the service and gives a hint on what would need to be considered with regards to data protection and privacy.

Manage user accounts

The service provides a User entity to store information about a user (see Developer Guide > Concepts > Basic Entities > User). The service also provides an API to create, read, update and delete such a User (see Developer Guide > API Description > Service API 1 > REST Resources overview > User Resource).
While some of the User properties are only stored and displayed within Bosch IoT Permissions, others might be used beyond, depending on your use case. The following table describes the properties and their usage in Bosch IoT Permissions.

User ("User Account")
A user can be a person, machine, network, etc. that is allocated to use a part of an application.
Property Description Usage
Name

A user account name is required.
The user account name is often chosen by the user.
Examples: john.doe, my-name, 124361257, john.doe@example.org, employee-123 (i.e. real name, alias, name initials, email address or an arbitrary identifier)

Display in service UI,
Authentication - Login
Password

Password for login ("Authentication") with this account.
The password is not stored in clear-text and is thus not human readable, nor can it be re-covered in clear text.

Authentication - Login
Last name Optional, last name of the user Display in service UI
First name Optional, first name of the user Display in service UI
Email Optional, email address of the user Display in Service UI,
Password reset
Custom attributes Optional, key-value pairs, which allow to store additional project specific user information (e.g. birthday, mobile number, etc.) -

Password reset

The service has built-in support for password reset implying email notification. However, it is not required to request the user's email address. In case no email address is stored, such a user will merely not beneficiate from this functionality. To handle the case of forgotten passwords, another communication channel (e.g. SMS, phone call) can be used.

Privacy considerations

  • Name can be a pseudonym to ensure privacy.
  • Last name and First name are optional fields. You do not need to ask your customer for this data.
  • Email address is an optional field. If no email address is stored, you will need to provide another channel for communication in case of a forgotten password.
  • You might use Custom attributes for storing additional user data relevant for your use case. If you do so, you are responsible to evaluate your data protection requirements. As we don't know how sensitive your custom data could be, you will need to check yourself their requirements for data security measures. However, Bosch IoT Permissions does not take special data security measures for custom attributes data, thus users empowered to read user data of the specific tenant will be able to read this data also.
  • The password reset can be done in self-service by the user, if a "Password Reset" template is set. If you use this template, you have to adapt it to your own product or service towards your customer. You should provide a link to your web page and and legal documents (e.g. "terms of use" and "privacy statement").
    The relevant section is marked with the following inline comment: <!-- You have to change the following information.-->

Email update

The service has built-in support for email update. This functionality is supported by a email notification.

Privacy considerations

  • The email update can be done in self-service by the user, if a "Email Update" template is set. If you use this template, you have to adapt it to your own product or service towards your customer. You should provide a link to your web page and and legal documents (e.g. "terms of use" and "privacy statement").
    The relevant section is marked with the following inline comment: <!-- You have to change the following information.-->

Manage user authorization

The service provides Groups, Roles, Application Roles and Permissions (see Developer Guide > Concepts > Basic Entities) for authorization management. These entities are managed within the Bosch IoT Permissions service and get assigned to a User directly or indirectly. Based on these assignments, the user will be authorized to execute specific operations in your application.

Group

A group contains a set of Users with the same set of Roles.

Groups are often used to model an organizational structure. Within this structure, there are several teams which have different responsibilities and access rights.

Property Description Usage
ID A unique ID is created by Bosch IoT Permissions. Authorization - Enforce access control
Name An identifying group name is required. This could be a department name, team name or an arbitrary identifier.
Example values: accounting, field-workers, team-x, group-123, executive-board
Display in service UI
Contained Roles Set of Roles available to the all Users of the Group. Display in service UI,
Authorization - Enforce access control
Parent Group A group can be related to a parent group.
All roles of the parent Group (and further parent Groups) are available to the Users of the Group.
Display in service UI,
Authorization - Enforce access control

Privacy considerations

  • A person might be identifiable based on the Groups it is assigned to (e.g. a group named "executive-board" probably identifies a small set of persons).
  • For the use case "Authorization", the assigned Groups are provided by ID. This makes it more difficult to identify a person based on its group assignments. A user which is allowed to query Groups may still be able to identify the members, based on the group assignment and the group name.


Role

A Role contains a set of Permissions.
A Role is either defined at development time ("Application Role") or created at runtime by a user of your application ("Tenant Role").
Property Description Usage
ID A unique ID is created by Bosch IoT Permissions. Authorization - Enforce access control (in case of Tenant Roles)
Name An identifying Role name is also required (e.g. job role, functional role, or an arbitrary identifier).
Example values: admin, accounting, field-workers, role-123, CEO
Display in service UI,
Authorization - Enforce access control (in case of Application Roles)
Contained Permissions Set of Permissions.
A user which has the role (assigned directly or indirectly through a Group), will have all these Permissions.
Display in service UI,
Authorization - Enforce access control

Privacy considerations

  • A person might be identifiable based on its Roles (e.g. a role named "CEO" probably identifies a single person).
    Functional names like "patient-data-access", "document-auditor", "manage-incidents", might be less leading to real persons.
    Names which may directly identify a person like "chief-doctor", "CEO", "security-officer" can be avoided.
  • For the use case "Authorization", the assigned Application Role names are provided.
  • For the use case "Authorization", the assigned Tenant Roles are provided by ID. This makes it more difficult to identify a person based on a role assignment. However, a user who is allowed to query Roles might still be able to identify the person based on the Role assignment and the Role name.

Permission

A Permission allows to execute a specific functionality in your application.
Before executing the functionality, your application will check if the user has the appropriate Permission (see use case "Authorization").
Property Description Usage
Name An identifying Permission name. The name usually describes a resource type and an action on this resource.
Example values: file-read, document-sign, incident-submit
Display in service UI,
Authorization - Enforce access control

Privacy considerations

  • A person might be identifiable based on the Permissions it is granted.
  • For the use case "Authorization", the Permission names are provided.

Authentication - Login

Authentication

For the use case authentication, the user provides his username and password on a login page of your application. Your application calls one of the authentication endpoints of the Bosch IoT Permissions service to verify the data, and receives a response.

Application Login

Your login page may request this data from the user, to provide it to the service authentication endpoint.

Property Description Usage
Tenant ID or name

The ID or technical name of the tenant. It might be a fixed tenant ID, configured within your application.

If your application supports multiple tenants, the specific tenant must also be provided.
Usually this is solved either by using a tenant-specific login URL,
or by providing a login form, where the user trying to authenticate can fill in the tenant name.

Authentication
Username The username of the user who wants to log in. Authentication
Password The password of the user who wants to log in. Authentication

Privacy considerations

  • Your login page should communicate over HTTPS, to keep the user credentials confidential. Sending credentials over HTTP should not be possible.
  • If authentication fails, your application should not provide details like "tenant does not exist", "username does not exist" or "password for this user is wrong". (The service itself does also not provide those details). If such details are provided on a failed login, it could be misused to check if a known user is using your application.
  • The ID Token issued by Bosch IoT Permissions contains the user ID and the tenant ID, but no personal related data.

Login with external identity provider


Login with external identity provider

Your login page allows the user to log in with an external identity provider (e.g. "Login with Google"). Your application receives an ID token and provides this ID token to Bosch IoT Permissions.

Property Description Usage
Identity Provider ID token

The Bosch IoT Permissions service resolves or creates a user entity based on the information provided within the ID token.
Data provided within the token is stored by the service in a user profile ("Linked profile") which is linked to the Permissions user entity. This information is stored for manual user identification in UIs or for support processes.

Authorization
Linked Profile - Email address

If the external identity provider provides an "email" claim within the token, the value is stored in the linked profile and in the "email" property of the user entity.


Manage user accounts

Privacy considerations

  • The service copies some user data provided by the Identity provider (see table above). If you need to delete this data, the whole user entity must be deleted.
  • Identity providers may offer additional user information. You might request such information for your application, but the Bosch IoT Permissions service does not require it.

Forwarding authentication and authorization information

Your application may be built out of different software components (e.g. micro services). While one component is responsible for the login page other components may require an authenticated user for a specific operation. You have to decide which information is requested from Bosch IoT Permissions  (see "Developer Guide - JWT-based Authentication and Authorization") and forwarded to specific service components. Concepts on handling Bosch IoT Permissions tokens are provided in the Developer Guide: Best Practices when using JWTs.

Privacy considerations

  • For data security and privacy reasons, you should restrict an authorization token to the rights which are required by the receiving software component.


Authorization - Enforce access control

Bosch IoT Permissions provides authorization information, which is used by your application to check if a user is allowed to execute a specific operation. The service provides role-based access control management via Groups, Roles and Permissions (see Manage user authorization). To enforce access control, your application requests an Authorization Token which provides a user's Groups, Roles and Permissions on request (see "Developer Guide - JWT-based Authentication and Authorization")

Authorization Token

An authorization token contains authorization information for a user. Your application checks for this information to grant or deny access.

Claim Description Usage
pn (Permission names) Permissions assigned to this user (indirectly via roles).
This includes the name of the application where the Permission names are defined.
Authorization check (see "Permissions based authorization check")
rn (Role names)

Application Roles assigned to the user (directly or via groups and parent groups).
This includes the name of the application where the Role names are defined.

Authorization check (optional, see "Application roles based authorization check")
gid (Group IDs) Groups assigned to the user. Authorization check (optional, see "Object level access control")
trid (Tenant Role IDs) Roles assigned to the user (directly or via groups and parent groups). Authorization check (optional, see "Object level access control")

Permissions based authorization check

It is recommended that your application generally implements authorization checks based on the Permissions names listed in the Authorization Token. This way, specific functionality (e.g. "read data from all sensors") will only be available if the token contains a corresponding Permission name.

Application roles based authorization check

You may need to control access to sets of objects, e.g. if a user is allowed to read data from all sensors in one building. In this case, you may create an application role per building. When a user tries to access a sensor of a specific building, you can check for the corresponding application roles.

Object level access control

You may need fine grained access control per application object. In this case authorization is not managed completely within the service, but you may refer to the Group IDs or Tenant Role IDs in your access control entries. As an example, an application may allow to define which Bosch IoT Permissions Groups and Roles are allowed to access a specific sensor.

Privacy considerations

  • Assigned Groups and Roles can be handed out in the Authorization Token. It is recommended to request such data only if your application needs it for authorization checks.
  • It is possible to resolve the group and tenant role name out of an Authorization Token. However, this is only allowed to restricted group of persons, who have the corresponding permission.
  • You may use arbitrary generated technical names for Application, Permissions and Application Roles, if you want to keep the existence and the exact purpose of your Application, its Roles and Permissions secret. However, such considerations would be rather a data security than a user privacy consideration. In general, this is not recommended.
  • The Authorization Token issued by Bosch IoT Permissions additionally contains the user ID and the tenant ID.

Self-registration

Self-registration API

Bosch IoT Permissions supports user self-registration scenarios, where a user of your application can sign-up to use your application. This implies that your application passes these data to the Bosch IoT Permissions service API, and the service to creates a user account.

Self-registration data

The self-registration API endpoints allow to implement an application specific sign-up page.

See "Developer Guide - Self Registered User Resource"

Data Description Usage
Tenant ID The ID of the tenant to whom the user account belongs.

Manage user accounts

Username A user name which is unique within the tenant Authentication - Login
Password The password for the self-registered user account Authentication - Login
Email address Optional email address of the user.
In case the email is given, it will be verified by the service (an email with a verification link is sent).
Email address verification


Email address verification

The service has built-in support for email address verification. However, it is not required to request the user's email address at self-registration. You may use another communication channel (e.g. in person contact, video, SMS) and another identifier (e.g. identity card, member card, serial number) for user identity verification.

Privacy considerations

  • If your customers should be able to self-register for your application, implement you own (web based) dialog based on the self-registration service endpoints.
  • Your process should only request data which is required by your application, but at least Tenant ID, Username and Password are required.
  • Tenant ID, Username and Password and Email address are mandatory when using the "default" self-registration functionality prepared by Bosch IoT Permissions - see below.
  • The self-registration functionality can be completely activated and deactivated per tenant. By default self-registering is active, see Manage the user self-service related settings, but not out of the box applicable due to email templates which need to be defined per tenant.
  • Self-registered users which did not activate their account and invited users which did not accept the invitation are automatically deleted after 30 days.

Default self-registration

The service also provides a default self-registration page for registration at a specific tenant (see "User Self-Service UI - Basic concepts of user self-registration").
This page is intended for:

  • Application developers - self-registration for working with your service instance.
  • Testing the self-registration service functionality
  • Prototype implementations which do not have an own sign-up page implemented yet

The default self-registration page might not be suitable for other cases. As an owner of a service instance, you are responsible for an appropriate use of this page.

Data Description Usage
Tenant ID The ID of the tenant to whom the user account belongs. Manage user accounts

Username

A unique user name in the tenant Authentication - Login
Password The password for the self-registered user account Authentication - Login
Email address The email address of the user. Required at the default self-registration page. Will be verified by an email with verification link.

Manage user accounts

First name Optional first name of the user Manage user accounts
Last name Optional last name of the user Manage user accounts

Privacy considerations

  • If your customers should be able to self-register for your application, implement you own (web based) dialog based on the self-registration service endpoints.
  • Your process should only request data which is required by your application, but at least Tenant ID, Username and Password are required.
  • Tenant ID, Username and Password and Email address are mandatory when using the "default" self-registration functionality prepared by Bosch IoT Permissions - see below.
  • The self-registration functionality can be completely activated and deactivated per tenant (see Developer Guide, Manage the user self-service related settings). By default self-registering is active, but you should adapt it to match your own product or service (see point below).
  • The registration can be done in self-service by the user, if a "User activation" template is set. If you use this template, you have to adapt it to your own product or service towards your customer. You should provide a link to your web page and and legal documents (e.g. "terms of use" and "privacy statement").
    The relevant section is marked with the following inline comment: <!-- You have to change the following information.-->
  • Self-registered users which did not activate their account and invited users which did not accept the invitation are automatically deleted after 30 days.


User invitation

User Invitiation API

Bosch IoT Permissions supports user invitation scenarios, where a user of your application can invite an other user to sign-up for an account. The invitation process makes use of multiple API endpoints to supply relevant data about the invited user.

Inital user invitation data

The invitation API endpoints allow to implement an application specific user invitation process.

See "Developer Guide - Implementing an invitation workflow"

Data Description Usage
Tenant ID The ID of the tenant to whom the user account belongs.

Manage user accounts

Email address

Email address of the invited user (optional).

An invitation email can be sent to this email address, so that the recipient can accept the invitation.

User invitation
Accepting an invitation

The invited user accepts the invitation on the default or on a custom "Accept invitation" page. The invited user provides credentials and additional user data which may be requested on this page.

See "Developer Guide - Implementing an invitation workflow".

Data Description Usage
Invitation code A technical code which allows the invited user to accept the invitation. User invitation

Username

A unique user name in the tenant Authentication - Login
Password The password for user account of the invited user. Authentication - Login
Further user data (optional) A custom "accept invitation" page could request additional user data. Manage user accounts


Invitation Email

The service has built-in support for sending out an invitation email. However, it is not required to use an email address for delivering an invitation. You may use another communication channel (e.g. in person contact, video, SMS).

Privacy considerations

  • The invitation functionality is restricted to users who have rights to create and modify a user.
  • When the invitation is created, the inviting user or your application could store additional data at the user account of the user to be invited (see Manage user accounts).
  • The default invitation email template should be adapted to your own product or service towards your customer. You should provide a link to your web page and and legal documents (e.g. "terms of use" and "privacy statement").
    The relevant section is marked with the following inline comment: <!-- You have to change the following information.-->
  • If the default invitation email template is used, the invitation email contains data of the inviting user. The username, first name, last name and email address of the inviting user could be present in the email. The invited user can thereby trust the invitation by recognizing the name or email address of the inviting user. You might change the email template if you don't want to expose this data.
  • If an invited user does not complete the invitation process, the corresponding user account is automatically deleted after 30 days.

Default "Accept invitation" page

The service provides a default page for accepting an invitation.
This page is intended for:

  • Application developers - invite team members to use your Permissions service instance.
  • Prototype implementations which do not have an accept invitation page implemented yet
  • Users of your application - the default page might be sufficient if you need only an email address and a username and your accept that the user visits the Bosch IoT Permissions domain for accepting the invitation.

The default accept invitation page might not be suitable for other cases. As an owner of a service instance, you are responsible for an appropriate use of this page.

Data Description Usage
Invitation code A technical code which allows the invited user to accept the invitation. User invitation

Username

A unique user name in the tenant Authentication - Login
Password The password for user account of the invited user. Authentication - Login

Privacy considerations

  • If you need other data from users of your application, implement you own (web based) dialog based on the invitation process service endpoints.
  • Your process should only request data which is required by your application, but at least Username and Password are required.


User deletion

Bosch IoT Permissions supports you in implementing a user deletion process in two steps:

  • Deletion - the user is marked as deleted (however he could be restored)
  • Permanent deletion - all user information is erased permanently

Deletion state

If a user wants to quit using your application, the user entity can be "deleted". A login operation (see Authentication - Login) is not possible, if a user entity is in state "deleted". To get a user entity into state deleted, specific permission is required (see "Developer Guide > User Resource). Within this state, all user data and authorization data is "on-hold" and can be restored. The data can still be accessed via service API.

Privacy considerations

  • No data is discarded, when a user entity is in state "deleted". The user entity must be deleted permanently, to delete the user's personal data.
  • Your application should usually not process the data of a user in state "deleted".
  • If a user entity was put into state "deleted" on the request of the user, you should only remove this state with the consent of the user.
    (Example: It might happen that a user first wants to quit using the application, but afterwards wants to get his account recovered.)
  • In case your tenant empowers its users to self-delete, such an action will set the user entity in the state "deleted" (see Identify a self-deleted user). Thus, prior to officially confirm the deletion of all user data (in the legal sense) you might need a second confirmation by the user (optional) and will definitely need to trigger a permanently delete (erase) action.

Permanent deletion

A user account can be deleted permanently. 

To permanently delete all managed data of a user account, a user entity needs to be erased. With the erase operation all data which is stored at the user entity is deleted permanently. This also includes authorization data (see Manage user authorization).

Privacy considerations

  • If you have stored user related data in your own application, make sure to also erase the data there.
  • If some of the user's data is still relevant for your application, you can access and archive this specific data before calling the erase operation. For privacy reasons this should be preferred over leaving the whole user entity inside the service in state "deleted".
  • Permanently deleting (erasing) a Tenant (or sub-tenant) will implicitly delete all its users.

Data processing and storage locations

The data provided by a client application, is processed and stored according to the following data flow diagram.

Data Flow

Notes:

Downstream service providers

To fulfill it's service we engage service providers to perform functions and process data:

  • Robert Bosch GmbH, Robert-Bosch-Platz 1, 70839 Gerlingen-Schillerh√∂he, Germany (hereinafter referred to as "Bosch")
  • Amazon Web Services EMEA SARL, 5 rue Plaetis, L-2338, Luxemburg (hereinafter referred to as "AWS")

Storage locations

The service stores data in a Tenant data store (A) and in an Audit log data store (B).

  • Tenant data (A) is stored at data centers of Bosch in Stuttgart, Germany,
  • Audit log data (B) is stored at Data centers of AWS in Frankfurt, Germany.
    Before entering the AWS data center, the data is encrypted by processes 5.1 and 5.2 running in a Bosch data center.




Data retention

In general, all data stored at the service is stored until you delete it explicitly via API or service UI. This section describes special cases where a retention policy is applied.

Operations log

For service operations, specifically for error analysis or usage statistics, all API calls might be logged. Operations logs are for internal service operation purposes only. Access to this logs is restricted to the operators of the Bosch IoT Permissions service. After the retention period the operations log data is deleted automatically.

  • Data: Operations log with data from API calls. Content of API calls (HTTP body) is not logged.
  • Control: Always active
  • Retention period: 30 days

Audit log

The audit log tracks security relevant operations and changes to personal data in user accounts. The log is not active by default. It needs to be activated per tenant. After the retention period the audit log data is deleted automatically.

  • Data: Security relevant operations or modifications (For details see "Developer Guide, section Audit Logging")
  • Control: Not active by default
  • Retention period: 90 days

(info) The Audit Logging feature is currently in Beta status. If you want to evaluate it, please send a request to activate it for your tenant.

Self-registered and invited users

In general all user account data is managed through the service API by your applications. It is not deleted automatically. The Self-registration and User invitation use case is an exception. The service deletes user account data automatically if a self-registered or invited user did not activate the user account.

  • Data: User account data of new accounts which weren't activated
  • Control: Always active
  • Retention period: 30 days

Legal Advice Disclaimer

The document has been assembled with every attempt to ensure its accuracy and reliability of the information, however, the information is provided "as is" without warranty of any kind.

This document is not intended to provide, and should not be relied on for legal advice.