Architectuurscan OO API

Uit ROSA Wiki
Ga naar: navigatie, zoeken

Deze pagina toont een samenvatting van de ROSA Architectuurscan van het onderwerp OO API. Met de ROSA Architectuurscan worden op systematische wijze alle architectuuraspecten van een bij Edustandaard ingebracht onderwerp in kaart gebracht en worden knelpunten en kansen gesignaleerd. Niet alleen kan de indiener er zijn voordeel mee doen, ook kan ROSA ermee worden verrijkt. En tot slot stelt het andere ketenpartijen in staat om kennis te nemen van architectuurwijzigingen en het belang hiervan voor de eigen organisatie of achterban te bepalen (transparantie in de keten, informatiepositie).

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 onderdeelBevindingen uit project: OO APIRelatie met ROSA (blauw: ROSA, geel: OO API)
Werkingsgebied

Hoger onderwijs (ho)

Compliant.pngCompliant - 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.pngCompliant - 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.pngIrrelevant - 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:

  1. “Data wat beschikbaar is voor iedereen, zoals nieuwsberichten of een overzicht van de verschillende studies.”
  2. “Data wat voor een bepaalde doelgroep beschikbaar is, zoals rooster data wat alleen beschikbaar is voor studenten van een bepaalde instelling of van een bepaalde studierichting. Voordat deze data kan worden vrijgegeven dient het systeem (veelal de API manager) de identiteit van de gebruiker te achterhalen om te kunnen bepalen ‘Is dit een student van deze instelling of van deze studierichting?’. De gebruiker zal deze gegevens middels een inlog moeten vrijgeven.”
  3. “Data wat bedoeld is voor een bepaalde gebruiker. Denk hier bijvoorbeeld aan tentamen/examen cijfers. Voordat deze data kan worden vrijgegeven dient het systeem de identiteit van de gebruiker te achterhalen. De gebruiker zal hiervoor moeten inloggen”

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.pngOnbepaald - 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.pngOnbepaald - 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.pngOnbepaald - Verdere ontwerp- en implementatiekeuzes bepalen hoe de gegevensuitwisseling afdoende kan worden geborgd

Ketenprocessen

De ketenprocessen zijn niet gedefinieerd in de OO API specificatie

Onbepaald.pngOnbepaald - 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.pngOnbepaald - 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.pngOnbepaald - 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.

Deze pagina is vastgesteld door Architectuurraad, op 18 januari 2018.
Toelichting: Besproken in AR van 15 februari 2018