Vereningstype

Context

Het verenigingstype is een eigenschap van een vereniging die deel uitmaakt van beslissende factoren die bepalen of een vereniging zich kan registreren in het Verenigingsregister. Verder bepaalt het verenigingstype de hoedanigheid van acties die een vereniging in het Verenigingsloket kan uitvoeren. De parameter is daarom van belang binnen het Verenigingsloket. Binnen de huidige context beantwoordt ze volgende vraag, "Is een verening registreerbaar?"

Het Verenigingsloket vereist de gebruiker om zich te authenticeren en een keuze te maken tussen de verenigingen waartoe men behoort. Na het authenticeren, ontvangt de gebruiker een token met daarin de vereniging: naam, KBO-nummer, eventueel de V-code en het verenigingstype. Ontbreekt de V-code, dan kan de gebruiker de vereniging registeren.

Om verenigingsinformatie aan de claims toe te voegen, voert ACM/IDM twee requests uit:

1. Een performante request om de naam en het KBO-nummer van de vereniging te bekomen.
2. Een traag request om het verenigingstype te bekomen.

ACM/IDM wenst om het laatste request niet meer uit te voeren.

Todo: uitzoeken waarom ACM/IDM het request niet meer wil doen? Vereningstype niet meer bijhouden of geen traag endpoint bevragen?

sequenceDiagram
    Gebruiker->>+Loket: Authenticeer 
    Loket->>+ACM: Authenticeer
    ACM->>+KBO: Verenigingen voor INSZ?
    KBO->>+ACM: Namen en KBO-nummers
    ACM->>+Vereningsregister: Verenigingen voor INSZ?
    Vereningsregister->>+ACM: V-code, verenigingstype, kbo-nummer voor gekende Verenigingen
    ACM->>+Gebruiker: Lijst vereningen
    Gebruiker->>+ACM: Keuze vereniging
    ACM->>+KBO: Vereningstype voor KBO-nummer?
    KBO->>+ACM: Vereningstype
    ACM->>+Loket: Token met vereniging claims

Loading

Decision

Het Verenigingsloket heeft het verenigingstype nodig om de user flow te bepalen, o.a. bij het al dan niet kunnen registreren van een vereniging. De te nemen beslissing is: wie is verantwoordelijk voor het ophalen van het vereningstype? En in welk deel van de flow gebeurt dit?

Assumptions

Constraints

Positions

Optie 1: ACM/IDM bevraagt het Verenigingsregister

Het Verenigingsloket (Departement Cultuur, Jeugd en Media) stelde de vraag of het Verenigingsregister een REST endpoint kan ontwikkelen dat een KBO-nummer aanvaardt en antwoordt met het verenigingstype. Dit endpoint zou dan kunnen worden opgeroepen door ACM/IDM. Dit impliceert dat het Verenigingsregister het VKBO aanspreekt indien het register de vereniging nog niet kent.

Voordelen:

1. Het Verenigingsloket ontvangt bij authenticatie zowel de naam, het KBO-nummer én het verenigingstype van ACM/IDM. Er zijn geen extra requests nodig vanuit het Vereningsloket.

Nadelen en risico's:

1. ACM/IDM neemt een (extra) dependency op het Verenigingsregister.
2. ACM/IDM neemt verantwoordelijkheid voor een claim die niet zuiver haar verantwoordelijkheid is. M.a.w. dient het verenigingstype een claim te zijn?
3. Het risico bestaat dat op termijn andere toepassingen ook deze claim wensen te ontvangen. In dit geval wordt de dependency tussen ACM/IDM en het Vereningsregister groter. De claim en dus het nieuwe endpoint worden gebruikt binnen uses cases anders dan de oorspronkelijke.
4. Het Verenigingsregister is geen owner van (V)KBO data. Voor de huidige use case kan het Verenigingsregister per ontvangen request het VKBO bevragen. Dit houdt in dat het register afhankelijk is van de uptime én performantie van het VKBO. Indien de uptime en/of performantie te wensen overlaten, kan authenticatie falen of een verwachte claim ontbreken. Het Verenigingsregister zou om voorafgaande te voorkomen de VKBO data kunnen cachen. Maar in dit geval wordt de correctheid van de claim potentieel verzwakt daar deze out-of-date kan zijn.

Optie 2: Het Verenigingsloket bevraagt het VKBO

Het Verenigingsloket bevraagt het VKBO rechtstreeks.

Voordelen:

1. Het loket behoudt zelf de controle over hoe ze VKBO data ter beschikking heeft. Bijv. VKBO per request bevragen of VKBO data cachen (en het refresh rate van de cache).
2. Het loket bepaalt zelf de snelheid waarin de nieuwe functionaliteit ontwikkelt kan worden.

Nadelen en risico's:

N.v.t.

Optie 3: Het Verenigingsloket bevraagt het Verenigingsregister

Het Vereningsregister stelt een nieuw endpoint ter beschikking dat een KBO-nummer aanvaardt en met volgende informatie antwoordt:

• Is de vereniging registreerbaar?
  • Ja, indien het verenigingstype dit toelaat én de vereniging nog niet geregistreerd is.
  • Nee, in alle andere gevallen.
• Het Verenigingstype
• V-Code indien gekend

Bijv.

{ "isRegistreerbaar": false, "vereningstype": "vzw" "v-code": "123" }

Voordelen:

1. Het endpoint kan worden gebruikt naast authenticatie scenario's.
2. Het endpoint geeft meer informatie dan enkel het vereningstype.

Optie 4: ACM/IDM bevraagt het VKBO (as-is)

Argument

Implications