Architectuurscan OO API
De architectuurscan is uitgevoerd op 18 januari 2018. Zie voor meer informatie, waaronder de adviezen die naar aanleiding van de scan door de Architectuurraad zijn uitgebracht, het adviesdeel en het bevindingendeel.
ROSA onderdeel | Bevindingen uit project: OO API | Relatie met ROSA (Groen: ROSA, geel: OO API) |
---|---|---|
Werkingsgebied |
Hoger onderwijs (ho) |
Compliant - Het werkingsgebied van de OO API valt volledig in het onderwijsdomein c.q. ROSA |
Toepassingsgebied |
De OO API ondersteunt administratieve- en onderwijsprocessen, door informatie van onderwijsinstellingen beschikbaar te stellen over: onderwijsafdelingen, onderwijsplannen, cursusgroepen, cursussen, cursusresultaten, toetsresultaten, gebouwen, ruimtes, roostergegevens, nieuwskanalen en nieuwsitems. |
Compliant - De OO API geeft invulling aan de volgende ketenfuncties: Onderwijsuitvoering; Personeel en organisatie; Onderwijshuisvesting; Toetsen, examinering en oefening; Informatieverwerking; Informatiestandaardisatie. |
Bovensectorale samenwerking |
De OO API beperkt zich tot de ho-sector |
Irrelevant - De OO API bestrijkt geen bovensectorale samenwerking |
IBP |
Voorkom onrechtmatige toegang of verspreiding - Uit de website blijkt dat de OO API onderstaande data beschikbaarheidsniveaus kent:
Zie: https://openonderwijsapi.nl/community/faq/ In de website van de OO API staat dat de OO API de OAuth 2.0 protocol ondersteunt. De specificatie zelf geeft niet aan hoe OAuth 2.0 precies gebruikt/geïmplementeerd moet worden. Er is een PoC waarin informatie hierover is opgenomen. Transparantie over maatregelen - In het HO is gekozen voor het vastleggen van afspraken ten aanzien van privacy en security middels het SURF juridisch normenkader. De juiste gegevens op het juiste moment op de juiste plaats - De OO API geeft een goede invulling hieraan Maakt het mogelijk om gegevens op een laagdrempelige manier op te vragen bij de bronnen. Welke gegevens de ‘juiste’ zijn, kan worden aangegeven via filters (zie hierover de opmerkingen bij Voorkom onrechtmatige toegang of verspreiding) Handelingen zijn herleidbaar - Over de traceerbaarheid van opvragingen via de OO API zijn geen besluiten of richtlijnen vastgelegd Voorkom ongewenste traceerbaarheid en vindbaarheid - Over het gebruik van persoonsgegevens (zoals geslacht, tel.nummer, foto,..) zijn geen besluiten of richtlijnen vastgelegd |
Onbepaald - Verdere ontwerp- en implementatiekeuzes bepalen de mate waarin toegang tot vertrouwelijke gegevens afdoende kan worden beperkt |
IAA |
Gebruik onderwijsidentiteit waar nodig - Over het gebruik van identiteiten zijn geen besluiten of richtlijnen vastgelegd |
Onbepaald - Verdere ontwerp- en implementatiekeuzes bepalen hoe het gebruik van identiteiten afdoende kan worden geborgd |
Gegevensuitwisseling in de keten |
Ketenpartijen bieden wederzijdse services - De OO API is weliswaar geen webservicespecificatie, maar biedt desalniettemin een (REST) endpoint voor data consumers om gegevens uit de bron op te halen. Op die manier geeft de OO API een goede invulling hieraan. Registreer de betekenis van nieuwe gegevens - Het is niet duidelijk welke OO API begrippen nieuw zijn. Sommige begrippen zijn niet scherp gedefinieerd Serviceinformatie wordt samenhangend openbaar gemaakt - Het is niet duidelijk hoe een gebruiker of ontwikkelaar weet dat er een endpoint bestaat Classificeer alle gegevens- en domeinobjecten met het Kernmodel Onderwijsinformatie - Het is onbekend hoe de semantiek van de OO API zich tot de semantiek van het KOI verhoudt. Sommige gegevens, attributen en relaties zijn niet scherp gedefinieerd Voorbeelden: "Educational departments" = The educational departments of an organization. Faculty = The organizational parts of an organization. Wat is het verschil tussen educational departments en faculty? Waarom is Organization niet gedefinieerd? Hoe weet je over welke organisatie het gaat? "Affiiation" The affiliations of how this person is associated with the organization Student/Employee/Staff/Member/Affiliate/Organization Het verschil tussen employee, staff en member is onduidelijk. Er lijkt ook een, verder niet beschreven, relatie te zijn met filters en autorisatie (Zie ook de bevindingen over filters bij IBP) "Building" Dit gegeven staat los van de rest. Building is een attribuut van “Schedule”, maar de verwijzing ontbreekt. Wat is de ontwerpbeslissing hierachter? Behoeftegerichte en doelgebonden gegevensuitwisseling - Het is niet duidelijk hoe de OO API borgt dat er niet meer (maar ook niet minder) informatie dan nodig uitgewisseld wordt. |
Onbepaald - Verdere ontwerp- en implementatiekeuzes bepalen hoe de gegevensuitwisseling afdoende kan worden geborgd |
Ketenprocessen |
De ketenprocessen zijn niet gedefinieerd in de OO API specificatie |
Onbepaald - Bij gebrek aan informatie is niet goed te bepalen voor welke processen de OO API wel of niet is bedoeld. |
Zeggenschappen en gegevenssoorten |
De zeggenschappen bij de gegevenssoorten (wat wel en wat niet door welke partij mag worden uitgewisseld, opgeslagen, ingezien, bewerkt) zijn niet gedefinieerd in de OO API specificatie. Deze zouden wel gedefinieerd moeten worden worden, mede als opmaat naar verdere uitwerking van security-aspecten als autorisatie en filtering (cf. IBP) |
Onbepaald - omdat de zeggenschappen niet zijn uitgewerkt. |
Bouwstenen en voorzieningen |
Het is niet vastgelegd welke referentiecomponenten en/of applicaties via de OO API ontsloten (moeten) kunnen worden. In de website wordt er gerefereerd aan een ‘API Manager’. Dit lijkt een referentiecomponent (bouwblok) dat bij de OO API hoort. Over deze referentiecomponent is echter maar weinig vastgelegd. |
Onbepaald - Bij gebrek aan informatie is niet goed te bepalen voor ontsluiting vanuit welke referentiecomponenten de OO API is bedoeld, noch welke referentiecomponenten rechtstreeks bij (de implementatie van) de OO API zijn betrokken. |