"BRP" Basic Registration of Persons

A data source/registration for all inhabitants in the Netherlands

The "BRP" or Basic Registration of Persons is a collection of all inhabitants in the Netherlands. This is the core data source which most dutch governmental organisations make use of.
Do we have a database of all the people in the Netherlands? No of course not that would be a gross violation of the GDPR and some other very important laws. But what is this then, I hear you ask. This is an API that functions as the BRP api currently developed by the dutch government. It can be filled with test persons which you then can use to develop or test your own solutions.

If there is enough interest we will host a test BRP with a simple interface where you can upload your own person that fits for your solutions at the hackathon.

GitHub     Redoc


A mock version of the dutch national online identifier

DigiD is the mostly used method in which someone can identify themselves with the online services of the government. This component is a open source mock version of this method. This component contains a frontend to simulate the login and an API to handle the backend, from the outside it functions as the real thing. The DigiSpoof component works in tandem with the BRP building block mentioned above.

GitHub Demo

Assent/consent service

A service which formally facilitates assents asked and given.

The assent/consent service or “instemmingservice” in dutch handles the assent given by a person. Where would you use a service as this? To choose one example this service is used in a wedding scheduler in development by the municipality of Utrecht. The municipality must establish that assent is given by both parties of a wedding. But the assent service can be used for anything which requires an assent given by a party. A request for data to name one of them.

GitHub Redoc


If you want to arrange something with a (local) government you as an individual or organisation can send them a “request”. The (local) government will process your request and communicate the result back. The difficulty with this is that many municipalities have different systems to process requests which have limited interoperability. This method aims to tackle this problem by standardizing the collection of data.
The method is a bit abstract, let’s use an example to illustrate this subject. You as a person would like to have a parking permit in your street. Usually you will fill out an application form (either digitally or physically) and send this to the department of the municipality that has jurisdiction over this application. As an individual you are sending a “request” for a parking permit. What is a request in this context? An request is a way to structure the dataset. The request type describes what information is needed in an abstract way. The request is self contains the data needed for the processing of the request.

Request Type Catalogue (VTC)

The request type is a template of the dataset needed in an request. These templates are stored in a catalogue. The template is just a template and thus holds no data. It does describe what the requirement are for the data. For example a “date of birth” would have the type date and “name” would be a string. To maximize reusability of this building block there is no “business logic” within the request type. The business logic is stored in another component which we will release soon.

GitHub Redoc

Request registration Component (VRC)

A request it self is stored in a registration, the VRC (verzoek registratie component in Dutch). The request uses the request type to determine the template of the data set and collects the data. It can be saved and continued at any point in time, tis creates flexibility for the user who in example starts the request on their phone but finishes the request on a laptop. When the request is complete the status is set to “submitted”. It is then ready to be picked up by the concerning department of the municipality to be processed.

GitHub Redoc

More to come!

We will add building blocks every week

The governmental ecosystem is vast and complex. We will add building blocks to this page every week. If you have a suggestion which building blocks you will need in the hackathon let us know and we will make those a priority!

Mail the team Captain!

Conduction an SSI Odyssey 2020 team!

Do you want to know more?

We are always looking for ways to help others to make the world a better place! If you need help with our building blocks or want to explore what we can do to help you out, do not hesitate to contact us! :)