You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
S05 - Er is dus een EAM functie gewenst zoals beschreven in FTV. Er wordt in dit GBO al op een implementatie voorgesorteerd. Deze indruk wekt de tekst een referentie-implementatie per bronhouder. Hierbij kan ook gesteld worden dat het wenselijk is dat er een EAM component in het stelsel aanwezig is maar dat bronhouders zelf verantwoordelijk zijn voor dit EAM component. Hierdoor laat je de feitelijke implementatie vrij en hoeft er geen gebruik gemaakt te worden van OPA, maar kunnen ook alternatieven ingezet worden.
Vraag hierbij is of dit bij de bronhouders noodzakelijk is om in te richten? Dit is nog niet heel duidelijk te halen uit het GO.
Voor een data uitwisselingen waarbij de private partij toestemming heeft van de betrokkenen is dan enkel de toestemmingsverklaring voldoende?
Daarnaast hoe verhoudt dit tot de GDI-domeinen Toegang en Interactie?
De EAM is gewenst, omdat de autorisatie op meer aspecten gecontroleerd wordt. De toestemming alleen voldoet niet - de afnemer moet deelnemer zijn van het stelsel, rechten hebben om de dienst aan te roepen en alleen gegevens opvragen die binnen de toegestane gegevensset vallen. Dat kan (grotendeels) met FSC-contracten, maar PBAC geeft meer flexibiliteit en minder beheer.
Activity
Govert-Claus commentedon Jul 10, 2026
De EAM is gewenst, omdat de autorisatie op meer aspecten gecontroleerd wordt. De toestemming alleen voldoet niet - de afnemer moet deelnemer zijn van het stelsel, rechten hebben om de dienst aan te roepen en alleen gegevens opvragen die binnen de toegestane gegevensset vallen. Dat kan (grotendeels) met FSC-contracten, maar PBAC geeft meer flexibiliteit en minder beheer.
Govert-Claus commentedon Oct 20, 2026
Uitleg voor keuze EAM zit in herschreven oplossingsrichting in v0.9.5