DECODE/DEC02 use case
Contents
- 1 Use Case ID - Use Case title
- 2 Owner of Use Case
- 3 Description
- 4 Requirements
- 5 Component(s)
- 6 Types/classes of data involved
- 7 Actors
- 8 Preconditions
- 9 Postconditions
- 10 Normal Flow
- 11 Alternate Flows
- 12 Evaluation of UC and requirements realisation
- 13 Categories of personal data involved
- 14 Purposes for personal data handling
- 15 Different kinds of processing involved
- 16 Data subjects, controllers, processors, and recipients involved
- 17 Storage & security aspects
- 18 Means of legitimation for personal data processing
Use Case ID - Use Case title
DEC02 - Rental Register
Owner of Use Case
Stefano Bocconi - DECODE project
Description
A local municipality wishes to register each rental transaction made by landlords with an online rental platform (AirBnB).
Each landlord needs to register a new rental period. The registration needs to contain as little personal information as possible:
- Duration (days) of the rental
- Address of the rented place
- Proof of ownership of the rented place given by the person registering the rental
Is Sub-Use Case of
Has Sub-Use Cases
Requirements
Related functional requirements
- Authorisation to submit a new rental period to the register is based only on the proof of ownership of that place
Related non-functional requirements
Requirement conflicts (if any)
Requirement similarities (if any)
Requirement subsets/refinements (if any)
Component(s)
- A digital wallet that each user has, containing verified attributes such as name, age, ownership of a house, etc.
- An authorisation system that requires particular verified user attributes to allow access (in this case to the register)
- A trusted authority (such as a municipality) that certifies the authenticity of (some of) the user attributes contained in the wallet
Types/classes of data involved
- User attributes
- Rental periods
Actors
- A local municipality or other instances that runs the register
- Landlord that needs to register a new rental period
- A certifying instance (such as the same local municipality)
Preconditions
- Users have (installed) a wallet
- Register supports attribute-based authorisations
- Users have means to certify their attributes
Postconditions
Normal Flow
- User interacts with a trusted authority that certifies (digitally sign) particular attributes of the user, such as ownership of a flat/house
- User records these attributes in their digital wallet
- User rents their place for a certain period of time via an online platform.
- Local municipality requires landlords to register their renting activity
- User is authorised to register a new rental period by allowing their wallet to share the required attributes with the register (ownership of the rented place)
- User registers the number of days their place is going to be rented
Alternate Flows
Evaluation of UC and requirements realisation
(e.g. manual, automatically...)
Categories of personal data involved
- The address of a property
- Attribute stating holder is owner of that property.
The second attribute is cryptographically signed by an authority such as the municipality. It is likely not stored, it is used to access the rental registry.
The rental period is stored together with the address of the property on a register managed by the municipality.
No other data such as name, date of birth, etc is necessary.
Purposes for personal data handling
The purpose of the processing for the ownership attribute is to assess whether the holder of the attribute has the right to register a rental period for the given property.
In theory this attribute does not need to be stored, as it is an authorisation process.
The rental period (which is not personal data) is stored in the register together with the address of the property.
Address of the property is personal data but is not linked to a person in the register.
Different kinds of processing involved
There is an authorisation process that verifies that:
- the digital cryptographic signature of the ownership attribute is valid
- the ownership attribute refers to the particular property at the given address
The data recorded in the register is analysed for further urban policy. Likely statistics are used in this analysis.
Data subjects, controllers, processors, and recipients involved
The data subjects are the property owners of a particular city that are willing to rent their property using platform such as Airbnb.
The data controller is the municipality, data processors are not known, possibly IT service providers that work for the municipality.
Inside the municipality, the register can be accessed likely by several departments.
Storage & security aspects
The storage and security of the register data is responsibility of the municipality.
Storage duration can be subject to legal requirements, as well as the security of the storage.
Attributes used to authenticate the registration process might be discarded, if legally this is admissible, or kept for the period of time in which appeals can be legally raised against the register..
All this data is not directly linked to a person but to a property, so we can say that it is at least in pseudonymisation form.
Means of legitimation for personal data processing
Processing of the attributes required for authorisation have as legal ground the legal obligations of the municipality.