[VRAAG] Buitenlandse adressen bevragen

[Bartman0]

Er wordt in de documentatie beschreven dat autorisatie op buitenlandse adressen een rol speelt voor het verkrijgen van deze informatie.
Waar wordt deze autorisatie vastgelegd, want een afnemer krijgt een API key en daarop is deze autorisatie dan vastgelegd?

Waarom is de keuze gemaakt om verblijf adres buitenland zo apart te behandelen?

deze vragen leveren bij buitenlandse adressen verschillende uitkomsten op:

{ "type": "RaadpleegMetBurgerservicenummer", "burgerservicenummer": ["999997439"], "fields": [

    "aNummer",
    "adressering",
    "adresseringBinnenland",
    "verblijfplaats",
    "verblijfplaatsBinnenland",

]
}

{ "type": "RaadpleegMetBurgerservicenummer", "burgerservicenummer": ["999997439"], "fields": [

    "aNummer",
    "adressering",
    "verblijfplaats",

]
}

door het opnemen van "adresseringBinnenland" en "verblijfplaatsBinnenland" wordt de API 'omgegooid' naar binnenlandse bevraging, en dan verdwijnt de buitenlandse info. ik denk nu dat ik de logica begrijp maar het was even een exercitie om de mentale omslag te maken. ;-)

persoonlijk zie ik geen goed doel voor de "adresseringBinnenland" aliassen (dat zijn het, geloof ik).
want door "verblijfplaats" te bevragen komt ook het "type": "VerblijfplaatsBuitenland" mee en dan weet je dat het een buitenlands adres is.

dus, de hoofdpunten nog even samengevat:

• waar ligt de autorisatie vast tav buitenlandse adressen?
• is het een idee om de duale rol van verblijfplaats eenduidiger te maken?

de eenduidigheid zou er mijns inziens uit bestaan dat verblijfplaats altijd de verblijfplaats teruggeeft, en dat eventuele aliassen zoals *Binnenland komen te vervallen.

groet, Richard

[CathyDingemanse]

Beste Richard,

Autorisaties van afnemers liggen vast in autorisatiebesluiten. Zie: https://publicaties.rvig.nl/Besluiten_en_modelautorisaties/Besluiten/BRP_besluiten

De Alias verblijfplaatsBinnenland en adresseringBinnenland zijn in het leven geroepen om afnemers zonder autorisatie voor buitenlandse verblijfplaatsen van de benodigde informatie te voorzien. Zie de uitleg:
https://brp-api.github.io/Haal-Centraal-BRP-bevragen/v2/features/persoon/verblijfplaats/fields-alias.feature
https://brp-api.github.io/Haal-Centraal-BRP-bevragen/v2/features/persoon/verblijfplaats/fields-alias-fout-cases.feature
Als je wel geautoriseerd bent voor buitenlandse verblijfsadressen heb je geen alias nodig en kun je de BRP API Personen zonder alias gebruiken.

Overigens wordt in de proefomgeving en in de productie-omgeving niet met een API key gewerkt, maar met een PKI overheid certificaat in combinatie met een OAuth ID en -secret.

Hoop dat dit eea verduidelijkt!

[Bartman0]

mijn punt is vooral dat wanneer ik geautoriseerd ben om verblijfplaats op te vragen, dat ik dan verblijfplaats mag opvragen.
of het dan een buitenlands adres is of niet, is dan niet zo relevant.
de eenduidigheid zou er uit moeten bestaan dat een query die ik stel altijd werkt zodra ik geautoriseerd ben op elementen.

wat er nu bestaat is dat ik als afnemer zonder autorisatie op buitenlandse adressen niet een query kan overnemen van mijn buurman die wel geautoriseerd is op buitenlandse adressen.
bij hem zal de query slagen en krijgt ie een buitenlands adres terug.
bij mij zal de query falen (ik kan het nog niet goed testen in de proefomgeving volgens mij) en moet ik de aanpassing doen om de binnenlandse aliassen expliciet op te vragen. tenzij het adres een binnenlands adres betreft en dan werkt het wel. het is niet consistent naar mijn gevoel.

twee opties:

• maak het expliciet en gebruik alleen binnenlandse verblijfplaats en buitenlandse verblijfplaats elementen; en ja, dan zal de query die ik kopieer falen met bovenstaand voorbeeld, maar dan zal er expliciet staan "not authorized on verblijfplaatsBuitenland" wat ik geheel kan plaatsen want daarvoor ben ik niet geautoriseerd
• gebruik verblijfplaats als generiek handvat tot verblijfplaatsen en geef altijd het type terug met de aanduiding 'binnenland/buitenland' en geef overige elementen terug als leeg of met vulling "NOT AUTHORIZED" of laat die subelementen helemaal weg uit de respons

ik neig ernaar de eerste optie te verkiezen.