Eigenschap:Scanbevindingen
Naar navigatie springen
Naar zoeken springen
Type eigenschap
:
Tekst
Geldige waarden
:
Meerdere waarden toegestaan
:
Nee
Weergave op formulieren
:
Tekstvak
Initiële waarde
:
Verplicht veld
:
Nee
Toelichting op formulier
:
Subeigenschap van
:
Geïmporteerd uit
:
Formatteerfunctie externe URI
:
Klik op de button om een nieuwe eigenschap te maken:
A
Een gezamenlijke voorziening die CA mogelijk maakt, dient “eigendom” van de sector te zijn, dit moet in termen van governance geregeld worden +
'''Eenmalige registratie, meervoudig gebruik'''
Voorziening CA maakt (her)gebruik van gegevens uit BRP/BRON, RIO en van centrale voorzieningen (DigiD)
'''Persoonlijke digitale ruimte'''
De studentomgeving binnen CA kan worden opgevat als persoonlijke digitale ruimte ihkv het aanmeldproces. +
Na identificatie worden persoonsgegevens (uit BRP) en vooropleidingsgegevens opgehaald bij BRON/DUO.
Gegevens over opleidingsaanbod worden via RIO naar CA overgebracht
Voorziening CA geeft BSN, Geboortedatum en Geslacht door aan SIS
Introductie van voorziening CA leidt tot harmonisatie van aanmeldinformatie
Gegevenssets worden beschreven in Bijlage 2 PvE. +
Een aspirant-student identificeert zich in de voorziening CA met een eID (DIGID). +
Het transferpunt stuurt alle 1e-jaar mbo-aanmeldingen (uit CA) en aanmeldstatussen (uit VVA) door naar de analyseomgeving meervoudig aanmelden. Daar worden de gegevens geanonimiseerd ten behoeve van analyse en rapportage meervoudig aanmelden.
Uitgangspunt is dat 100% van de aspirant-studentgegevens in/door de voorziening CA gaat i.v.m. inzicht in meervoudige aanmeldingen.
Ten behoeve van statistische analyses kan de ruwe data van aanmeldingen door de beheerder van CA worden geëxporteerd naar Excel.
Voor specificatie van de levering van gegevens CA naar SIS wordt verwezen naar Bijlage 2.. Deze bijlage 2 gaat over het wat, niet over het hoe (+maatregelen) van de levering.
“Zolang wordt gewerkt met geaggregeerde rapportages [...] is er vanuit de AVG geen bezwaar”. +
In het PvE zijn de processtappen van aanmelden door middel van use cases vormgegeven (PvE, p.3). +
Er zijn binnen het mbo reeds activiteiten en werkende voorzieningen gericht op digitaal aanmelden (DaMBO), Digitaal ondertekenen (pilots worden opgeschaald) en de overdracht van leerdossiers (in de regio).
In het kader van nieuwe wetgeving wordt een Voorziening Vroegtijdig Aanmelden (VVA) ingericht (voor wat betreft het mbo ook wel ‘mbo-koppelpunt’ genoemd).
De voorziening CA heeft een directe relatie met de Voorziening Vroegtijdig Aanmelden (VVA) en met de student informatie systemen (SIS) van de instellingen. +
Collectieve (mbo-)voorziening Centraal Aanmelden
Sterke wens vanuit instellingen om inzicht te krijgen in meervoudige aanmeldingen
Informatiebehoefte rondom meervoudig aanmelden speelt op drie niveaus: instelling, regionaal, landelijk (sectoraal). +
Centraal Aanmelden staat ten dienste van alle bekostigde instellingen; 55 instellingen
nemen deel aan het PvE. PvE dient als vertrekpunt voor oplossing door geïnteresseerde (markt)partijen.
Het beheer en eigenaarschap wordt ondergebracht in de coöperatieve vereniging MBO-Voorzieningen, die in handen is van de deelnemende instellingen.
[[DUO]] levert gegevens aan CA, via een soortgelijke koppeling als SIS/BRON. +
Volgens het pitchdocument is beheer en doorontwikkeling belegd bij CvTE in samenwerking met DUO. +
De inhoud van CEVO raakt alleen VO, maar met de toepassing van AMIGO is er ook rekening mee gehouden dat MBO een vergelijkbare aanpak kan implementeren. +
Uit de tekst onder het kopje implementatie blijkt dat CvTE, DUO, CITO en LAS leveranciers binnen het VO met de afspraak te maken krijgen. (Bron: https://www.edustandaard.nl/standaard_afspraken/cevo/schooljaar-2021-2022/ Implementatie) Welke verschillende belangen deze groepen hebben werd niet duidelijk uit de documentatie.
Uit de documentatie werd niet duidelijk hoe alle groepen belanghebbenden bij het beheer van de afspraak betrokken worden.
Op de Edustandaard website wordt onder het kopje “Samenhang” beschreven dat er samenhang is met andere afspraken (Bron: https://www.edustandaard.nl/standaard_afspraken/cevo/schooljaar-2021-2022/ Samenhang) +
Op de Edustandaard webpagina staat dat informatiemodellen zijn ontwikkeld conform de AMIGO methodiek. Te zien is bijvoorbeeld vanaf slide 15 van de CEVO documentatie hoe ROSA informatiemodellen worden omgezet tot een technischer berichtenmodel. Trace relaties worden gebruikt om de semantiek direct traceerbaar te houden naar de ROSA informatiemodellen.
Op de Edustandaard site staat er dat het actuele Edukoppeling REST/SaaS-profiel is toegepast. Om te voldoen aan het Edukoppeling REST/SaaS-profiel zijn de juiste attributen toegevoegd. Bijvoorbeeld het “edu-from”attribuut. (Bron: CEVO definitiedocument) +
Alleen in de uitwisseling van kandidaatgegevens, afnameleiders en planning worden onderwijs identiteiten uitgewisseld. Dit is ook de enige uitwisseling waar dit noodzakelijk is. Ook worden alleen noodzakelijke persoonsgegevens uitgewisseld.
(bron: slide 7 CEVO documentatie)
In CEVO wordt voor de onderwijsdeelnemeridentiteit een pseudoniem gebruikt in de vorm van een verwijzing naar ECKiD. Wanneer een examenkandidaat geen ECKiD heeft kan worden teruggevallen op een LAS key. (Bron: CEVO definitiedocument schema: Onderwijsdeelnemeridentiteit)
Voor uitwisseling van het LAS van de school Identificatie van een school gaat aan de hand van een BRIN code, authenticatie zit in Edukoppeling laag en voor autorisatie wordt het OSR gebruikt. (Bron:CEVO definities document) +
Volgens het pitchdocument wordt veel met persoonsgegevens gewerkt en zijn er bij Centraal examens VO strikte BIV eisen. Ook staat er dat er 2 soorten uitwisselingen zijn:
Openbare informatie, zoals toetscatalogus
Specifieke informatie, zoals scores & resultaten
In de documentatie valt niet terug te vinden welke BIV classificatie een attribuut heeft.
Volgens slide 3 van de CEVO documentatie wordt informatie over afnameleiders opgehaald uit Facet door een LAS. De informatie wordt niet opgeslagen waardoor de integriteit van de gegevens behouden blijft.
Alleen noodzakelijke persoonsgegevens worden uitgewisseld wanneer dit moet. Er worden bijvoorbeeld geen contactgegevens van onderwijsdeelnemers uitgewisseld. De voor en achternaam worden uitgewisseld wanneer een afnamegroep moet worden doorgegeven aan Facet. (Bron: CEVO definitiedocument schema afnamegroep)
Tijdens de afname van een examen worden de weergavekenmerken op het scherm van de examenkandidaat weergegeven zodat een afnameleider de identiteit van de kandidaat kan valideren, (Bron: CEVO definitiedocument schema weergavekenmerken) +
“Afspraken over de implementatie vindt plaats via periodieke overleggen en wordt ondersteund door een digitale projectomgeving (Microsoft Teams) met overlegdocumentatie, specificaties, ondersteunende documentatie, etc. en een discussieforum. Toegang tot deze projectomgeving is alleen voor betrokken partijen en geschiedt op uitnodiging.” (Bron: https://www.edustandaard.nl/standaard_afspraken/cevo/schooljaar-2021-2022/ Implementatie) +
CEVO gaat over de uitwisseling van gegevens met betrekking tot de afname (Bron: https://www.edustandaard.nl/standaard_afspraken/cevo/schooljaar-2021-2022/ Beschrijving) +
Volgens het pitchdocument zijn er nu 3 applicaties/systemen in de keten: Facet (Toetssysteem), Magister (LAS) en Somtoday (LAS)
Er is ook een relatie met het OSR, dit is nog geen Referentiecomponent in de ROSA. +
Volgens de Edustandaard website zijn er verschillende uitwisselingen voorzien binnen het logistieke ketenproces rondom de centrale examens VO (cevo):
* Publicatie van de centrale examens (toetscatalogus)
* Aanleveren van afnameplanningen
* Publicatie van examenvarianten met schaallengte en n-term (variantencatalogus)
* Overdragen van de leerlingscores en -resultaten +
Op basis van de Edustandaardwebsite kan worden vastgesteld dat de afspraak betrekking heeft op uitwisseling van examengegevens tussen een onderwijsinstelling in het VO en overheidspartijen als CvTE en CITO en DUO doet de implementatie. +
Met CEVO worden examens, afnamegroepen, afnameleiders, examenvarianten met daarbij normeringsinformatie en resultaatscores uitgewisseld (Bron: CEVO definitiedocument). Binnen afnamegroepen worden Examenkandidaten opgenomen met een onderwijsidentiteit. +
Paragraaf 1.2 van het PRD geeft een overzicht van interne en externe belanghebbenden en de rollen die zij t.o.v. de (ontwikkeling van de) voorziening hebben. In het Voorstel Governance is in meer detail een governancestructuur uitgewerkt inclusief verantwoordelijkheden en aansluitvoorwaarden. +
De dienst zal gebruik maken van eHerkenning voor toegang en ondertekenen. Daarnaast zal/zullen (delen van?) de dienst toegankelijk zijn via Entree. Beheerders van de dienst maken binnen Kennisnet gebruik van een eigen, interne, SSO-voorziening obv ADFS. +
Het PRD omvat een BIV-classificatie en een beschrijving van de te nemen beheersmaatregelen. +
Afbeelding 7 toont een informatiemodel met gegevensentiteiten voor de Dienst Verwerkersovereenkomsten. Hierin staan o.a. de volgende elementen:
* Onderwijsinstelling
* Leverancier
* Verwerkingsactiviteit
* Digitaal onderwijsmiddel (product/dienst)
* Verwerkersovereenkomst
Definities bij de entiteiten ontbreken. +
Paragraaf 3.2 stelt dat de componenten een mogelijk toekomstbeeld schetsen, maar dat in de huidige opzet het de bedoeling is dat alleen verwerkersovereenkomsten worden geregistreerd.
De mapping op FORA in diezelfde paragraaf is heel breed, en benoemt o.a. invulling van ‘registratie van verwerkingsactiviteiten’ als functie die door de voorziening wordt ondersteund.
Afb. 5 (e.v.) toont verschillende doelen, waaronder ‘Applicatielandschap inzichtelijk maken’.
Afb. 6 toont dat diverse gerelateerde functies die geleverd moeten worden door verschillende voorzieningen (Dienst Verwerkersovereenkomsten, Dienst Product Catalogus, Kennisnet Authenticatiehub, Interne Registers en Kantoorautomatisering) samen invulling geven aan het ‘gesloten domein’.
Afb. 15 toont een fasering voor oplevering van verschillende componenten. +
“De dienst verwerkersovereenkomsten brengt leveranciers en schoolbesturen samen en stelt hen in staat om onderling in een besloten omgeving hun verwerkersovereenkomsten met elkaar af te stemmen en te ondertekenen. Daarnaast biedt het beiden overzicht van alle verwerkersovereenkomsten die zijn afgesloten.” +
Het pitchdocument positioneert de Dienst Verwerkersovereenkomsten als “basisvoorziening voor het funderend onderwijs”. +
[[Id-b269d84e-d15b-4c83-8946-7a69013c288d|'''Koppelen - niet kantelen''']]
“Entree Federatie zorgt ervoor dat digitale identificatie en authenticatie zo min mogelijk het onderwijsproces onderbreken.” Deze doelstelling uit H2 van de Marktverkenning (2), sluit aan bij het ROSA Basisprincipe Koppelen - niet kantelen.
[[Id-72b6fd75-30af-471e-870e-61f115023421|'''Een gezamenlijke basisinfrastructuur:''']]
Het ROSA basisprincipe Koppelen - niet kantelen, wordt verder ingevuld door het leveren van een gezamenlijke basisinfrastructuur. Deze basisinfrastructuur realiseert de Entree Federatie door online authenticatie van gebruikers te centraliseren; “waarbij onderwijsinstellingen en dienstaanbieders met elkaar gekoppeld worden via een centrale voorziening” (Bron: H2 Marktverkenning (2))
'''Samenwerking met SURFconext:'''
SURFConext wordt in §4.3.2 van de Marktverkenning (2) genoemd als vergelijkbare partij met een andere doelgroep. In §6.3.1 van de Marktverkenning wordt OpenConext genoemd als de meest kansrijke optie om de vernieuwde Entree Federatie op te baseren. Dit is dezelfde open source software waar SURFConext op gebaseerd is. Uit de gesprekken met de Entree Federatie (5) bleek dat direct gebruik van SURFConext niet mogelijk is, omdat de Zeggenschappen te veel verschillen. In het bijzonder speelt daarbij de rol van instellingen in het ho als eigen ID-provider ten opzichte van scholen in het po en vo die in de regel het LAS c.q. de LAS-leverancier als ID-provider gebruiken.
De samenwerking tussen Kennisnet en SURF wordt aangemerkt als gemakkelijk te organiseren. Daarnaast, wordt erkend dat wanneer Kennisnet en SURF OpenConext doorontwikkelen, dit ook van waarde is voor een bredere doelgroep. +
Volgens de Pitch (4) blijft het beheer van de Entree Federatie belegd bij Kennisnet.
'''Alle belangen in kaart'''
H4 van de Marktverkenning (2) beschrijft de positie van alle groepen belanghebbende waaronder kennisnet zelf, verschillende groepen gebruikers concurrenten en leveranciers.
'''Betrokken belanghebbenden'''
In H4 van de Marktverkenning (2) worden de groepen belanghebbenden benoemd. Uit de gesprekken met de EF blijkt dat via programma start schooljaar SEM de communicatie verloopt. Scholen worden geïnformeerd via de nieuwsbrief van Kennisnet en later ook via de raden.
'''Bewaak relaties met andere afspraken'''
Het governanceproces rondom de Entree Federatie haakt aan bij bestaande governance- en opverlegstructuren met overlappende doelstellingen. Dit governanceproces is vanuit de Entree Federatie zelf lastig te sturen.
'''Aanvullend'''
Het onderwijsdomein kent geen stelselconformiteit als eis of randvoorwaarde. Hoewel dit strikt genomen buiten de scope van de ROSA-governanceparagraaf valt, onderkennen we dat gebrek aan een overkoepelend stelsel hier wel als risico. De werking van de federatie is uiteindelijk afhankelijk van de op intenties gebaseerde samenwerking tussen ketenpartijen. +
[[Id-8ed6b136-0982-4d5d-aab4-498c22c0e8b8|'''Behoeftegerichte en doelgebonden gegevensuitwisseling''']]
De EF biedt een manier om identiteit van een gebruiker uit te wisselen op het moment dat die gebruiker zich bij een systeem aanmeldt. Daarvoor wordt gebruik gemaakt van het SAML-protocol of OpenID-connect. De Entree Federatie is zelf geen gegevensbron voor identiteitsgegevens. Ook de attributen die via de Entree Federatie kunnen worden meegestuurd worden niet binnen Entree opgeslagen. De registratie en het gebruik van Attribute Release Policies ondersteunt het behoeftegericht en doelgebonden uitwisselen van deze gegevens.
‘Mijn Entree’ biedt een aantal APIs voor metadata en rapportage. Via de Mijn Entree APIs kunnen alleen publieke gegevens worden ontsloten.
Toepassing van de UBV-TLS afspraak wordt als vanzelfsprekend gezien. +
Het huidige Entree Federatie platform loopt tegen grens aan van het aantal authenticaties p.22 technische verkenning (1), daarnaast wil Kennisnet nieuwe technologieën op het gebied van Identity Management kunnen ondersteunen zoals SSO voor mobiele devices. [§2.2.2 van de Marktverkenning (2)]
[[Id-327e11bc-0d95-4d15-a39f-eafaf427e49d|'''Marktpartijen kunnen IAA-diensten leveren''']]
Volgens p.8 vd technische verkenning (1) maakt de Entree Federatie (EF) gebruik van een Hub-and-spoke model. Dit houd in dat de EF erin voorziet dat meerdere Service providers gebruik kunnen maken van identiteiten vanuit verschillende ID providers via een centrale hub.
[[Id-2f6998bd-7079-47a5-b0bc-b8ede6e298d5|'''Meerdere expliciete betrouwbaarheidsniveaus''']]
Op p.24 van de technische verkenning (1) staat de impact omschreven van het ondersteunen van betrouwbaarheidsniveaus op de Entree Federatie. ID providers zijn verantwoordelijk om deze betrouwbaarheidsniveaus in te stellen. Er zijn momenteel geen attributen ingericht om een betrouwbaarheidsniveau uit te wisselen binnen de Entree Federatie. +
'''AVG is drijfveer voor verbeteringen aan Architectuur:'''
In §2.2.2 van de Marktverkenning (2) wordt de AVG genoemd als één van de redenen waarom vernieuwing van de Entree Federatie (EF) nodig is. De AVG biedt gebruikers het recht op meer inzicht in en controle over hun gegevens. Met het huidige platform gaat dit lastig en is innoveren duur, aangezien deze gebaseerd is op verouderde technologie. Daarnaast speelt ook mee dat leerlingen tot 14 jaar zelf niet de verantwoordelijkheid over hun eigen identiteit dragen, waardoor de onderwijsinstelling daarvoor verantwoordelijk is.
[[Id-f4e449df-6504-462a-a23f-d7c6b29dcd2a|'''Duidelijke eisen en verwachtingen:''']]
Op P.11 van de technische verkenning (1) wordt het idee van de Attribute Release Policy service uitgelegd. Uit gesprekken met de EF (5) bleek dat iedere school met iedere service provider een eigen ARP afsluit. De scope van de Attribute Release Policy lijkt te passen bij de scope van Services waarvoor in het OSR mandaten worden vastgelegd. Scholen zullen voor een dienst zowel mandateringen in het OSR als ARPs voor Entree moeten vastleggen.. In de Developer documentatie (3) bestaat een [https://developers.wiki.kennisnet.nl/index.php?title=KNF:Attributen_overzicht_voor_Identity_Providers pagina] waar aanvullende attributen en richtlijnen op te vinden zijn. Uit brondocument (5) blijkt dat in de nieuwe situatie dit anders zal werken. Bij het aansluiten van een service provider kan de attributenset ingericht worden conform, bijvoorbeeld, het Attributenbeleid van Edu-K of andere relevante afspraken.
[[Id-9668c6ac-f646-44ee-b110-416bf1b9e423|'''Continuïteit van de dienstverlening:''']]
De uitgangspunten op p.14 technische verkenning (1) gaan in op een technische implementatie om de continuïteit van de dienstverlening te waarborgen. De maatregelingen om de continuïteit te waarborgen zijn goed uitgewerkt en zouden potentieel van toegevoegde waarde kunnen zijn voor de ROSA om de implicatie binnen het ontwerpkader te verrijken met voorbeelden.
“De Entree Federatie doet dit door online authenticatie van gebruikers te centraliseren, waarbij onderwijsinstellingen en dienstaanbieders met elkaar gekoppeld worden via een centrale voorziening. Dit geeft onderwijsdeelnemers de mogelijkheid om via Single Sign-On met het account van hun onderwijsinstelling in te loggen bij alle dienstaanbieders in het onderwijs. Op deze manier kunnen dienstaanbieders beschikken over betrouwbare onderwijsidentiteiten zonder met elke onderwijsinstelling aparte afspraken of koppelingen te hoeven maken.” [Bron: Context H2 Marktverkenning (2)]
Dienstaanbieders binnen het PO, VO en MBO kunnen zich aansluiten bij de Entree Federatie. De scope van de EF beperkt zich hierbij niet tot diensten ter ondersteuning van een beperkt aantal ketenprocessen. +
'''Gemeenschappelijkheid in informatiehuishouding'''
Binnen het onderwijs zijn al veel ketenpartijen die gebruik maken van RESTful gegevensuitwisseling. Deze maken nu zelfstandige keuzes hoe transport, logistiek en beveiliging ingericht moeten worden. Het profiel beoogt hier meer standaardisatie in door te voeren, waarbij met name invulling gegeven wordt aan het kunnen routeren tussen de rollen die in Edukoppeling t.b.v. SaaS worden onderscheiden. +
'''Relaties met andere standaarden'''
* UBV (zie ook [[AS EK-REST IBP|onderdeel IBP]])
* Voor transparante intermediair, onweerlegbaarheid, en/of uitwisseling obv XML: toepassen Edukoppeling WUS-profiel
* OOAPI: onduidelijk of Edukoppeling-rollen hierin onderkend worden
* Inbedding in nationale (overheidsbrede) standaarden. Basis wordt gevormd door afspraken en voorschriften uit de landelijke API-strategie. Enige mate van ontkoppeling via MoSCoW-classificering.
* Op p.6 wordt XML over REST niet toegestaan, volgens API-24 is het een eigen afweging (COULD). +
Must: Gebruik van openbare internet “Overigens kan Edukoppeling ook toegepast worden in gesloten netwerken.”. Tegenspraak? Hoe ‘must’ te lezen?
'''Foutafhandeling:'''
* Architectuur definieert categorieën A t/m E In 3.1.8 alleen foutmeldingen voor cat. A t.a.v. syntax to/from-routeringskenmerken. → hoe passen de andere categorieën op HTTP statuscodes? +
* Identificatie/authenticatie verwerker obv OIN / PKI-infrastructuur (P2P).
* Eindorganisaties worden geïdentificeerd via routeringskenmerken (TO, FROM)
* Inzet van transparante dienstverleners wordt (nog) niet ondersteund (daarvoor: WUS)
* Verplicht gebruik Onderwijsserviceregister
* Verwijzing naar ontwikkelingen OAuth in bijlage A.
* Gebruik van API-sleutels geen onderdeel van het profiel, maar wel toegestaan
** Voor API-key (geen onderdeel profiel) stroomschema’s en mogelijke 401/403-foutcodes. Zoiets mist voor afhandeling van ‘from-OIN’ en OIN verwerker (P2P) .
+
* TLS (wordt verwezen naar UBV)
Vertrouwelijke gegevens in GET-parameters
* P.13: ‘dienen gepseudonimiseerd te zijn’
* P.18: igv persoonsgegevens ‘kunnen aanvullende beveiligingsmaatregelen toegepast worden, zoals adequaat versleutelen en/of voorkomen ongewenste logging dmv filter’.
+
M2M-gegevensuitwisseling via een beveiligde point-to-pointverbinding waarbij RESTful standaarden voor gesloten (access-restricted en purpose-limited) APIs worden toegepast (zowel pull als push). +
Gehele onderwijsdomein (cf. organisatorisch werkingsgebied zoals beschreven in Edukoppeling architectuur). +
Het governanceproces binnen Edu-V omvat een stapsgewijze en collaboratieve ontwikkeling van het afsprakenstelsel. Hierbinnen zijn het de werkgroepen die afspraken formuleren en toetsen in samenwerking met scholen en leveranciers, gevolgd door een evaluatie op bruikbaarheid en toepasbaarheid in klankbord- en focusgroepen, onder eindtoezicht van de Edu-V architectenraad. Het architectuurkader vormt een raamwerk voor de Edu-V architectuurraad om nieuwe afspraken te kunnen beoordelen en evalueren op een consistente manier. [4] [5]
Tot de directe belanghebbenden van het architectuurkader behoren de Edu-V werkgroepen [5]. Werkgroepen binnen de Edu-V context worden gevormd via een open uitnodigingsproces via diverse kanalen, waarbij de selectie gebaseerd is op specifieke criteria per werkgroep, met als doel een evenwichtige vertegenwoordiging van de verschillende onderwijssectoren en zowel publieke als private partijen te bereiken. [6] Wat deze criteria zijn en hoe deze balans wordt nagestreefd wordt niet duidelijk uit de brondocumentatie.
In het pitch document staat dat bij de totstandkoming van het Architectuurkader is voortgebouwd gemaakt van werk van de werkgroepen van Edustandaard. Specifiek worden afspraken uit de
werkgroepen Edukoppeling, UBV, IBP, Toegang, RIO en Adviesgroep Samenhang Onderwijsarchitecturen genoemd. [2] +
Het onderdeel H2M identificatie en authenticatie beschrijft het architectuurkader voor identificatie en authenticatie van personen in het ecosysteem Edu-V. Het kader is gebaseerd op het concept toepassingspatroon Federatieve toegang van de Edustandaard werkgroep Toegang en onderscheidt verschillende betrouwbaarheidsniveaus en referentiecomponenten voor de identiteitsverklaring van onderwijsdeelnemers en -medewerkers. +
In het Edu-V architectuurkader zijn voorwaarden gesteld voor het uitwisselen van M2M gegevensuitwisselingen en H2M identificatie en authenticatie.
Om een basisniveau van informatiebeveiliging en privacy te waarborgen maakt het Edu-V architectuurkader gebruik van verschillende standaarden en handreikingen, zoals het ‘Certificeringsschema informatiebeveiliging en privacy’ van de ROSA ‘Certificeringsschema IBP ROSA’
Verder maakt het gebruik van verschillende classificatiesystemen voor gegevenssoorten. Er wordt gebruikgemaakt van een [https://edu-v.atlassian.net/wiki/spaces/AFSPRAKENS/pages/1998909/M2M+gegevensuitwisselingen#Classificatie-van-gegevenssoorten:-I,-II,-III-en-IV. classificatiesysteem] voor gegevenssoorten die rekening houdt met de vertrouwelijkheid, de regie, persoonsgegevens ja/nee en een verwerkersovereenkomst voor gegevensuitwisseling [1].
Daarbij maakt het Edu-V architectuurkader gebruik van een [https://edu-v.atlassian.net/wiki/spaces/AFSPRAKENS/pages/10944513/Gegevenssoorten BIV-classificatiesysteem] met de waardes Hoog, Midden en Laag [1]. Waarbij de basiswaarde Midden is. +
In de pitch [2] wordt aangegeven dat van het onderdeel identiteiten onderwijsmedewerkers, stagebegeleiders en stagebedrijven buiten scope zijn. De wikipagina over identiteiten [1] maakt onderscheid tussen primaire en secundaire identiteiten. Wat hier precies mee bedoeld wordt
Voor de onderwijsdeelnemer wordt het ECK iD gebruikt als primaire identiteit. Het ECK iD wordt afgeleid van het BSN volgens de Bijlage.
De wikipagina maakt ook onderscheid tussen primaire en secundaire identifiers voor onderwijsorganisaties. Gedurende de bespreking van de scan werd duidelijk dat dit gedaan wordt om altijd te kunnen terugvallen op secundaire identifiers, wanneer geen primaire beschikbaar is, maar deze grondslag valt nog niet terug te vinden in de beschrijving van het Edu-V architectuurkader. +
De interoperabiliteit binnen het Edu-V architectuurkader wordt versterkt door het hanteren van een beperkt aantal gestandaardiseerde transactiepatronen voor machine-to-machine (M2M) gegevensuitwisseling, gericht op het laagdrempelig houden van het ecosysteem en het faciliteren van diverse bedrijfstransactiepatronen. Deze patronen worden direct overgenomen uit Edukoppeling. [1]
Op de pagina “[https://edu-v.atlassian.net/wiki/spaces/AFSPRAKENS/pages/75268097/Regie+op+gegevens regie op gegevens]” [1] staan een aantal overwegingen die zijn meegenomen bij uitwerking van de gegevensuitwisselingsarchitectuur. De architectuur beschrijft bijvoorbeeld hoe onderwijsorganisaties regie hebben over hun eigen gegevens en toestemming kunnen verlenen of intrekken voor het uitwisselen van gegevens tussen leveranciers.
Daarnaast ondersteunt de architectuur vier implementatievarianten voor regie op gegevens. Ook stelt een overweging dat leveranciers alleen de persoonsgegevens mogen verwerken waarvoor ze ook daadwerkelijk doelbinding hebben.
Het Edu-v architectuurkader bevat een aantal [https://edu-v.atlassian.net/wiki/spaces/AFSPRAKENS/pages/2097211/Gegevensmodel+en+definities gegevensmodellen en definities [1'"`UNIQ--nowiki-000018F3-QINU`"']. Op de desbetreffende pagina staat dat definities tot stand zijn gekomen in afstemming met de Edustandaard Adviesgroep Samenhang Onderwijsarchitecturen. Ook wordt aangegeven dat dit er nog aan gewerkt wordt. Op basis van een steekproefsgewijze vergelijking kan worden gesteld dat definities van “entiteiten” in de gescande conceptversie nog niet volledig geharmoniseerd zijn met de ROSA. Het is wel duidelijk dat de namen wel overeenkomen.
Voorbeeld: Onderwijsdeelnemer in Edu-v: “Een individu die onderwijs volgt op een school.”
ROSA Begrippenkader/KOI: “Een natuurlijk persoon die deelneemt aan een onderwijsactiviteit om zich kennis, vaardigheden en attitudes eigen te maken.”
Daarnaast kan worden vastgesteld dat de AMIGO modellenmatrix nog niet is toegepast om de relatie tussen verschillende modellen duidelijker te maken. Alle ingrediënten hiervoor lijken wel aanwezig te zijn. Bijvoorbeeld de Edu-V praktijksituaties (die inhoudelijk niet behoren tot de scope van deze scan), deze doorlopen de stappen van de AMIGO methodiek, maar hoe deze modellen samenhangen met de overkoepelende gegevensmodellen (die wel onderdeel zijn van de scan) wordt niet direct duidelijk.
Het Edu-V afsprakenstelsel gaat over ketenprocessen in de onderwijsdomeinen po, vo en mbo. De ROSA richt zich op zaken die gemeenschappelijk zijn in het onderwijsdomein als het gaat om samenwerking in ketenprocessen.
In het Edu-V architectuurkader [1] wordt onderscheid gemaakt tussen zes functionele en twee ondersteunende domeinen. Deze domeinen zijn gerelateerd aan de ketendomeinen in de ROSA. Ook de ketenprocessen, behorende bij de ketendomeinen, zijn gerelateerd aan de ketenprocessen in de ROSA. +
Op de pagina M2M gegevensuitwisselingen [1] wordt architectuur rondom M2M gegevensuitwisselingen binnen het Ecosysteem Edu-V uitgewerkt. Deze architectuur bestaat uit vijf beveiligingslagen en vier classificaties van gegevenssoorten. introduceert de vier classificaties van gegevenssoorten, Deze classificatie is afhankelijk van de vertrouwelijkheid, de regie op gegevensuitwisseling, de aanwezigheid van persoonsgegevens en de noodzaak van een verwerkersovereenkomst. +
Het afsprakenstelsel heeft als doel om een gelijk speelveld te bieden aan alle betrokken leveranciers van producten, diensten en applicaties. In het architectuurkader is daarom expliciet het volgende architectuurprincipe opgenomen: ‘Het ecosysteem bevat gedefinieerde referentiecomponenten en is interoperabel’. Een referentiecomponent hangt samen met een rol die een leverancier met een applicatie kan vervullen in het ecosysteem.
“referentiecomponenten geven het recht of de plicht om gegevensdiensten aan te bieden of te consumeren.” [1] Een gegevensdienst volgens Edu-V is een set van afspraken binnen het Edu-V afsprakenstelsel die betrekking hebben op: gegevenssoorten en attributen en koppelvlakspecificatie (APIs) en referentiecomponenten. Er wordt op de pagina “Verplichte en optionele gegevensdiensten per referentiecomponent”, precies bijgehouden welke gegevensdiensten verplicht zijn per referentiecomponent.
De referentiecomponenten in het architectuurkader zijn afgestemd op de ROSA en onderverdeeld in de domeinen van het architectuurkader [1]. Echter, een aantal referentiecomponenten zijn specifiek voor het Edu-V afsprakenstelsel en niet voor onderwijsorganisaties die zich baseren op de ROSA.
Edu-V stelt zelf dat er een aantal acties nog nodig zijn om de referentiecomponenten verder te verifiëren en aan te vullen. Bij het referentiecomponent "Onderwijsleeromgeving", wordt bijvoorbeeld net een andere definitie gebruikt dan in het “adviesdocument leermiddelen” van de adviesgroep samenhang, maar ook in de ROSA wordt hier nog van afgeweken. +
In het Edu-V afsprakenstelsel zijn verschillende praktijksituaties opgenomen [1]. De praktijksituaties zijn onderverdeeld bij verschillende werkgroepen. Op dit moment zijn er vier praktijksituaties uitgewerkt:
* Combineren en arrangeren (digitale) leermiddelen
* Verwerven en in gebruik nemen van (digitale) leermiddelen
* Toetsen en examineren
* Evalueren leervoortgang en -resultaten
De detailuitwerkingen van de praktijksituaties bevatten de volgende onderdelen:
# Scenariobeschrijvingen, soms aangevuld met een conceptueel model ter verduidelijking;
# Randvoorwaarden voor de praktijksituatie;
# Functionele specificatie
# Technische specificatie;
# Relevante APIs. +
Het Edu-V architectuurkader is een belangrijk onderdeel van het Edu-V afsprakenstelsel. Volgens de pitch [2] richt het Edu-V afsprakenstelsel zich op de onderwijsdomeinen po, so, vso, vo en mbo. In de documentatie op Confluence [1] staat dat het Edu-V afsprakenstelsel zich richt op het primair, voortgezet, speciaal en middelbaar beroepsonderwijs. +
Het ontwerpgebied governance van de gescande gegevensdiensten is onveranderd ten opzichte van de vorige ROSA scan. Voor een meer uitgebreide analyse van dit scanonderdeel verwijzen we naar: Architectuurscan Edu-V Architectuurkader - ROSA Wiki +
Het ontwerpgebied H2M Interactie van de gescande gegevensdiensten is onveranderd ten opzichte van de vorige ROSA scan. Voor een meer uitgebreide analyse van dit scanonderdeel verwijzen we naar: [[Architectuurscan Edu-V Architectuurkader]] +
Er worden een aantal aanvullende IBP gerelateerde ontwerpeisen genoemd voor het scenario Administratiesystemen onderwijsdeelnemer en medewerker [1]:
* Dataminimalisatie in de objecten: Dit principe houdt in dat alleen de strikt noodzakelijke gegevens worden verzameld en opgeslagen.
* Scheiding van persoonsgegevens: Persoonsgegevens worden gescheiden gehouden van andere informatieobjecten, en er wordt gewerkt met identificatiecodes (IDs) in plaats van directe persoonlijke informatie.
* Scheiding van bijzondere persoonsgegevens en basis persoonsgegevens: Bijzondere persoonsgegevens, zoals demografische gegevens, worden apart gehouden van basis persoonsgegevens. +
Op de gescande pagina’s wordt niet direct gesproken over ontwerpkaders i.r.t. digitale identiteiten. Daarom blijft het ontwerpgebied onveranderd ten opzichte van de vorige ROSA scan. Voor een meer uitgebreide analyse van dit scanonderdeel verwijzen we naar: [[Architectuurscan Edu-V Architectuurkader]] +
Op de pagina ´Methodiek en modellen” [1] wordt beschreven: “In het afsprakenstelsel Edu-V worden gegevensdiensten tussen referentiecomponenten uitgewerkt. Bij de uitwerking van deze gegevensdiensten benutten we de AMIGO-aanpak van Edustandaard.”
In de pitch staat: “De gegevensdienst leerresultaten is gericht op uniformiteit van de uitwisseling van leerresultaten in het funderend
onderwijs. De gegevensdienst bouwt voort op reeds uitgewerkte standaarden UWLR-Resultaatuitwisseling en
Summatieve toetsresultaten vo en biedt een modern alternatief voor deze (legacy)standaarden.” [2]
In iedere gescande praktijksituatie worden de conceptuele en logische uitwisselingsmodellen (zie AMIGO modellenmatrix) uitgewerkt. Deze zijn meer gedetailleerd dan het conceptuele model dat is gescand in de vorige architectuurscan. Ook worden de API specificaties uitgewerkt. [2] +
Deze (lite) scan richt zich specifiek op alle Edu-V gegevensdiensten rondom de praktijksituaties “Verwerven en in gebruik nemen leermiddelen”
en de gegevensdienst “Administreren leerresultaten” binnen de praktijksituatie “Toetsen en examineren”. [2]
Daarnaast valt het scenario “Administratiesystemen onderwijsdeelnemer en -medewerker”
(Scenario binnen praktijkscenario Doorgifte identiteiten [2]) en de gerelateerde API specificaties binnen de scope van deze scan. Dit scenario richt zich op uitwisseling van gegevens met betrekking tot onderwijsaanbod, onderwijsmedewerkers, onderwijsdeelnemers en onderwijsinrichting. (Administratiesystemen onderwijsdeelnemer en –medewerker
, [2]) +
Het ontwerpgebied M2M Interactie van de gescande gegevensdiensten is onveranderd ten opzichte van de vorige ROSA scan. Voor een meer uitgebreide analyse van dit scanonderdeel verwijzen we naar: [[Architectuurscan Edu-V Architectuurkader]] +
Volgens het conceptuele model van “Verwerven en in gebruik nemen leermiddelen” [1] worden de volgende referentiecomponenten gebruikt binnen de scenario’s:
* Bestelomgeving leermiddelen
* Aanspraakmanager
* Licentieregistratie
* Leermiddelenportaal
* Gebruiksomgeving digitaal leermateriaal
* Digitaal toetssysteem
* Leermiddelen dashboard
Additioneel worden hier in het gedetailleerde model de volgende referentiecomponenten aan toegevoegd:
* Administratiesysteem onderwijsdeelnemer
* Administratiesysteem onderwijsmedewerker
* Leveranciersspecifieke leermiddelencatalogus
* Overkoepelende leermiddelencatalogus
* Selectieomgeving leermiddelen
* Distributiefaciliteit
* Ordersysteem leermiddelen
Binnen het scenario “Administratiesysteem leerresultaten” [1] worden de volgende rc’s gebruikt:
* Digitaal toetssysteem
* Administratiesysteem leerresultaten
Het scenario: Administratiesystemen onderwijsdeelnemer en –medewerker, heeft betrekking op RCs:
* Administratiesysteem onderwijsdeelnemer
* Administratiesysteem onderwijsmedewerker
Daarnaast wordt ook een relatie benoemd met de ketenvoorziening RIO [2] +
De atlassian pagina over de praktijksituaties: “[https://edu-v.atlassian.net/wiki/spaces/AFSPRAKENS/pages/11927579/Verwerven+en+in+gebruik+nemen Verwerven en in gebruik nemen leermiddelen]” [1], bevat een gedetailleerde uitwerking van 18 scenario’s. Elk scenario beschrijft de interacties tussen een actor, zoals een onderwijsmedewerkers, onderwijsdeelnemers of leverancier, en verschillende referentiecomponenten.
De pagina over de praktijksituatie “[https://edu-v.atlassian.net/wiki/spaces/AFSPRAKENS/pages/30113793/Toetsen+en+examineren Toetsen en examineren]” [1], beschrijft twee scenario’s, waarbij alleen “Administreren leerresultaten”, relevant is voor deze scan: Dit scenario gaat over het administreren van leerresultaten in een RC “Administratiesysteem leerresultaten”.
Plannen van toetsen en examens is een ander scenario dat nog niet nader is uitgewerkt. +
In de pitch staat: “De praktijksituatie
Toetsen en examineren richt zich niet op het middelbaar beroepsonderwijs.”. Gegevensdiensten in relatie met deze praktijksituatie zijn onderdeel van deze scan.
Het werkingsgebied van de gegevensdiensten is verder onveranderd ten opzichte van de vorige ROSA scan. Voor een meer uitgebreide analyse van dit scanonderdeel verwijzen we naar: [[Architectuurscan Edu-V Architectuurkader|Architectuurscan Edu-V Architectuurkader - ROSA Wiki]] +
Volgens de Pitch en de Edustandaard website is het beheer van de FDE-set belegd Bij de werkgroep “ECK Distributie en Toegang”. +
EDEXML is de standaard voor de uitwisseling van administratieve gegevens van leerlingen met bijbehorende gegevens over groepen en leerkrachten. (bron: FDE-set v1.1 §1.2) EDEXML sluit qua begrippen niet perfect aansluit bij het VO en MBO en er zijn wensen tot uitbreiding, daarom is de FDE-set ontwikkeld. (Bron: https://www.edustandaard.nl/standaard_afspraken/fijndistributie/fde-set1-0/ alinea 3) +
“In dit profiel zijn om praktische redenen de ontwikkelingen rondom RIO en AMIGO buiten de specificaties gelaten. De gedachte hierbij is dat deze ontwikkelingen nog niet volledig geïmplementeerd zijn en op dit moment nog pending zijn.” (Bron: https://www.edustandaard.nl/standaard_afspraken/fijndistributie/fde-set1-1/ ) Het is onduidelijk uit de documentatie wat de verwachte impact zal zijn van het toepassen van de AMIGO methodiek.
Uit de lijst aanvullende documenten in FDE-set v1.1 §1.4 kan worden opgemaakt dat er relaties bestaan tussen de FDE-set en andere afspraken. Hoe deze bewaakt worden wordt niet duidelijk uit de documentatie.
Volgens p.1 van FDE-set v1.1 is het beheer van de FDE-set belegd bij de werkgroep Distributie en toegang. Of de werkgroep de groepen belanghebbende in kaart heeft gebracht werd niet duidelijk uit de documentatie. +
In FDE-set §2.5 worden aanvullende gegevens in de vorm van werkingsregels en eisen op EDEXML beschreven. Zie ook Bijlage 2 van de ROSA scan voor een overzicht. Ook worden alle gegevens gedefinieerd.
In FDE set §2.2 staat dat de beveiliging van de uitwisseling wordt geboden door de onderwijstransactiestandaard Edukoppeling.
Het is onduidelijk uit de documentatie hoe er wordt omgegaan met internationale adressen. Dit wordt binnen verschillende registraties anders gedaan. RIO sluit bijvoorbeeld aan bij de NEN door het huisnummertoevoegingNEN veld toe te voegen. +
“Distributeur Applicatie (DA) zich gedraagt als de Educatieve Applicatie (EA) in de stap 1 van UWLR scenario 2 waarbij als identifier van de leerling het ECK iD moet worden gebruikt. De DA stuurt een verzoekbericht aan het LAS om leerlinggegevens, het LAS reageert met de gevraagde Leerlinggegevens.” (Bron FDE-set §2.3)
Het ECK iD wordt gebruikt om een leerling mee te identificeren. Wanneer deze niet beschikbaar is kan worden teruggevallen op een LAS-key. Er zit ook een gebruikersnaam bij leerlinggegevens. +
Volgens de Pitch worden veel persoonsgegevens of bijzondere
persoonsgegevens verwerkt met toepassing van de FDE-set. Welke van de attributen dit zijn valt wel te achterhalen in de specificatie, maar is niet direct aangegeven met een BIV classificatie.
“met de komst van het ECK iD is het noodzakelijk om een andere route te kiezen die voldoet aan de eisen die vanuit IBP hieraan worden gesteld.” (bron: FDE-set v1.1 §2.2) De documentatie stelt dat deze eisen worden ingevuld door het ECK-iD toe te voegen aan een EDEXML-profiel in combinatie met het toepassen van Edukoppeling.
De berichtenuitwisseling bouwt voort op UWLR. (Bron: FDE-set v1.1 §1.3) Er zijn 2 varianten mogelijk: alles in 1 of getrapt. (Bron FDE-set §2.3) Deze varianten bieden geen mogelijkheid om het ECK-iD los van de persoonsgegevens uit te wisselen. Beide hebben we een ander doel. ECK iD zit in de FDE-set voor digitale toegang en persoonsgegevens (zoals adressen) voor distributie van fysiek lesmateriaal.
In de specificatie van de FDE-set worden geen richtlijnen gesteld voor afnemers over hoe de traceerbaarheid van het pseudoniem “ECK iD” naar persoonsgebonden gegevens (zoals adresgegevens) kan worden voorkomen. Edukoppeling moet tijdens de uitwisseling voor beveiliging zorgen, maar wanneer de gegevens worden opgeslagen in een registratie, zou dit voor ongewenste traceerbaarheid kunnen zorgen. +
Realisatie wordt ingeschat als gemiddeld in de pitch. Uit de documentatie wordt niet duidelijk wat de onderkende risico’s zijn bij implementatie. Steeds meer uitwisselingen worden in OSR gemandateerd, dus zou voor verwarring kunnen zorgen aangezien OSR niet gebruikt wordt bij de FDE-set. +
De afspraak raakt volgens de Pitch een enkele of slechts een zeer beperkt
aantal ketenprocessen. Op basis van FDE-set v1.1 §2.1 kan worden gesteld dat het hier gaat om een profiel voor het uitwisselen van educatieve content behalve toetsen. +
Leerlingadministratiesysteem (LAS) en Distributeur Applicatie (DA) worden genoemd in §2.4. In ROSA wordt de term [https://rosa.wikixl.nl/index.php/Id-e3c985fa-04dd-4abe-a491-509791e25b7f Distributeursportaal] gebruikt voor Distributeur Applicatie. +
FDE-set is een profiel dat kan worden toegepast voor de uitwisseling van leerlinggegevens die fijndistributie van leermiddelen(behalve toetsen) voor distributeurs mogelijk maakt. Het voegt een profiel toe hiervoor bovenop EDEXML, (bron: FDE-set v1.1 §2.1)
Uit de documentatie werd niet duidelijk waar de afkorting “FDE” voor staat. De naam verliest daarom wat betekenis. +
De FDE-set voor fijndistributie is een profiel voor het VO en MBO op EDEXML gebruikmakend van de UWLR-uitwisseling van leerlinggegevens.
EDEXML is de standaard voor de uitwisseling van administratieve gegevens van leerlingen met bijbehorende gegevens over groepen en leerkrachten. EDEXML is bedoeld voor het primair en voortgezet onderwijs. (bron: https://www.edustandaard.nl/standaard_afspraken/edexml/edexml-2-1/ ) +
Uit de gesprekken met de FDE-set bleek dat zeggenschappen zijn belegd, maar deze zijn niet omschreven in documentatie. Informatieobjecten staan in Bijlage 2 van deze Scan. +
Er wordt een apart ontwikkeltraject opgestart voor verdere aansluiting op ontwikkelingen rondom RIO, AMIGO en ROSA-gegevensmodellen en Edukoppeling-profielen. +
De afspraak is gericht op het op een gestandaardiseerde wijze uitwisselen van leerlinggegevens tussen LAS/SIS van een VO-school en een distributeur. +
De afspraak is gebaseerd op UWLR 2.3 en daarmee inclusief EDEXML 2.1. De afspraak is “verder niet afhankelijk van beide betrokken afspraken” (paragraaf 2.1).
Ten opzichte van v1.1 is een Governance-paragraaf toegevoegd (2.8), waarin de adviezen uit de vorige architectuurscan zijn vewerkt. In het colofon is informatie opgenomen over de betrokken groepen belangjhebbenden en de wijze waarop zij zijn betrokken. +
Paragraaf 2.5 beschrijft de gegevens en werkingsregels binnen het profiel FDE-set. Ten opzichte van v1.1 is een aantal wijzigingen aangebracht, waaronder:
* Toevoeging van DigideliveryID bij School en FDE-vestiging
* Vestigingsinfo hernoemd naar FDE-vestiging
* Samengestelde groep (vak/keuzegroep) hernoemd naar Vakkengroep
* Leerling-/studentnr toegevoegd bij Leerling
* Blok ‘Plaatsing’ toegevoegd
* Blok Adres gespecificeerd.
* Deze wijzigingen zijn niet backwards compatible.
De relatie met RIO is in v1.2 duidelijker beschreven. +
De werkingsregels voor het gebruik van identiteiten van identiteiten van een leerling zijn in deze versie gewijzigd ten opzichte van v1.1. In versie 1.1 was het uitgangspunt het gebruik van ECK-iD om een leerling te identificeren, met mogelijk terugvallen op een LAS-key wanneer ECK-iD niet beschikbaar is.
<br>
In versie 1.2 is het gebruik van LAS-key verplicht gesteld, en moet in aanvulling daarop het ECK-iD worden meegegeven als dat beschikbaar is; in dat geval moet het ECK-iD als identificatie worden gebruikt (paragraaf 2.5.5 Leerlinginfo). Daarnaast is een (verplicht) Leerling-/studentnr aan het gegevensblok Leerling toegevoegd. +
Naar aanleiding van de Architectuurscan op v1.1 van de FDE-set is een paragraaf 2.7 IBP toegevoegd. +
In het project Revisie ROSA is een implementatie-onafhankelijk ketenproces rondom Leermiddelen en Leermateriaal uitgewerkt dat model staat voor de specifieke invulling van het proces in verschillende ketensamenwerkingen.. +
De FDE-set voor VO onderscheid LAS en DA (distributeurapplicatie). +
FDE-set is een profiel op EDEXML voor de uitwisseling van leerlinggegevens ten behoeve van de fijndistributie (FDE) bij het ditributie-/levereingsproces door een distributeur. +
Het profiel is ingeperkt tot werkingsgebied voortgezet onderwijs (vo). Versie 1.1 had als werkingsgebied vo + mbo. Voor mbo zal een apart profiel gemaakt moeten worden.
<br>
Op [https://www.edustandaard.nl/standaard_afspraken/fijndistributie/fde-set1-2/ de Edustandaard website] wordt op dit moment nog zowel vo als mbo aangeduid als werkingsgebied. +
Paragraaf 2.1 (Scope) beschrijft de rol van distributeurs en scholen in het proces, inclusief het beheer/’eigenaarschap’ over leermiddelen. Deze paragraaf laat ook de inforamtiestromen tussen deze rollen zien vanuit LAS (school) naar DA (distributeur) +
De PrSA (3.5) bevat bedrijfsprincipes. Principe BP07 geeft aan dat DUO zich inzet voor transparantie door stakeholders op verschillende momenten in het proces te informeren. Dit omvat voorafgaande informatie, updates tijdens het proces, en achteraf inzage in relevante informatie. DUO informeert stakeholders ook over het procesverloop, de regels, de gebruikte gegevens en het (mogelijke) resultaat van de gevraagde dienst.
Volgens Artikel 23 van de [https://wetten.overheid.nl/jci1.3:c:BWBR0042012&hoofdstuk=2¶graaf=2.3&artikel=23&z=2023-01-01&g=2023-01-01 Wet register onderwijsdeelnemers] kunnen basisgegevens worden verstrekt aan verschillende onderwijsverenigingen, waaronder de Vereniging PO-Raad te Utrecht, de vereniging VO-raad te Utrecht, de vereniging MBO Raad te Woerden, de Vereniging Hogescholen te Den Haag, en de Vereniging Universiteiten van Nederland te Den Haag.
In het PrSA komen de termen “leverancier”, "bronhouder” en “data provider” op meerdere plekken terug. Basisgegevens kunnen worden verstrekt aan verschillende onderwijsverenigingen volgens wet WRO, De PrSA van GABI benoemt deze organen niet. Ze worden alleen kort benoemd in de PSA documenten voor SANE en MDP. +
Het PrSA (5.2) document beschrijft drie afzonderlijke functies die in samenhang ook wel worden aangeduid met Identity and Access Management (IAM): Identificatie, Authenticatie en Autorisatie. Hoewel deze functies duidelijk worden gedefinieerd, is het niet duidelijk hoe ze in de praktijk worden geïmplementeerd en hoe ze met elkaar samenwerken om een veilige en efficiënte toegangscontrole te waarborgen. +
In het Project Start Architectuur (PrSA) document, specifiek in sectie 4.4, wordt het principe van "Gegevens bij de bron" en "Enkelvoudig beheer, meervoudig gebruik" benadrukt. Dit principe is in lijn met Artikel 23 van de Wet register onderwijsdeelnemers (WRO), waarin staat dat persoonsgegevens kunnen worden verwerkt indien dit noodzakelijk is voor de genoemde doelen.
Verder wordt in het PrSA document, onder principe BP05, gesteld dat de stakeholders van DUO erop kunnen vertrouwen dat informatie, en de onderliggende gegevens, goed worden beschermd. Dit omvat bescherming tegen inbreuken op de beschikbaarheid, integriteit, vertrouwelijkheid, duurzame toegankelijkheid en rechtmatig gebruik tijdens de verwerking van informatie en onderliggende gegevens.
De gegevensbeveiliging wordt ingevuld door verschillende services, waaronder de Minimaliseren gegevens service (Enterprise Data Hub), Meta-gegevens service (Metadata Publicatie), Gegevens kwaliteit service (Enterprise Data Hub), en Gebruikersomgeving beheer service (SANE). +
In het Project Start Architectuur (PrSA) document worden twee principes benadrukt: "Gegevens enkelvoudig en uniform beschreven" en "Gegevensbeschrijvingen van de bron" (PrSA, 4.4). Deze principes onderstrepen het belang van het hebben van duidelijke definities voor gegevens. Voorbeelden hiervan zijn de definities voor Access Management (PrSA, 5.2): "Het vaststellen dat een subject (persoon of systeem) de juiste rechten om een object te benaderen" en Identity Management: "Het beheren van de identiteiten van gebruikers, hun rollen, autorisaties en authenticatiegegevens."
Het PrSA document (sectie 1.1) inventariseert de kaders, principes, richtlijnen, standaarden en normen die relevant zijn voor het project en schetst de implicaties van deze kaders voor de oplossing die het project gaat realiseren. Een specifiek principe dat wordt benadrukt is dat DUO standaardiseert processen, gegevens en ondersteunende applicaties en IT technologie, en daarbij open standaarden gebruikt en aansluit op referentiearchitecturen van de overheid, in dit geval specifiek HORA / HOSA (PrSA, 3.6). Ook wordt gezegd dat MIM wordt toegepast. Welke Edustandaard afspraken worden geraakt wordt niet duidelijk uit de documentatie. +
In paragraaf 3.3 van het Project Start Architectuur (PrSA) document is een functiemodel uitgewerkt. Uit dit model blijkt dat het voornamelijk gaat om interne processen van DUO. Dit beeld is consistent met de bedrijfsarchitectuurmodellen die zijn opgenomen in de begeleidende Project Start Architectuur documenten.
Zie bevinding werkingsgebied WRO artikel 23. Een verstrekking van basisgegevens is toegestaan voor zover dit noodzakelijk is voor de ondersteuning van onderwijsinstellingen en samenwerkingsverbanden bij hun verantwoording omtrent de kwaliteit, toegankelijkheid of doelmatigheid van het onderwijs. In WRO artikel 10 staat: “De basisgegevens omvatten, naast de identificerende gegevens, bedoeld in artikel 9, in elk geval gegevens met betrekking tot:
a.de onderwijsinstelling waar de onderwijsdeelnemer is of was ingeschreven;
b.de datum van in- en uitschrijving bij de desbetreffende onderwijsinstelling.” +
In het PrSA document (sectie 4.2) worden drie soorten applicaties onderscheiden, elk met hun specifieke verantwoordelijkheden:
# Bron gegevens platformen: Deze zijn verantwoordelijk voor de extractie van gegevens uit de oorspronkelijke bron en de integratie van deze bronnen met de Data Hub.
# Distributie platformen: Deze zijn verantwoordelijk voor de distributie van gegevens naar de afnemende platformen. Ze voeren ook de benodigde transformaties uit om de gegevens geschikt te maken voor de afnemers, waaronder gegevensharmonisatie (transformatie), mastering en verrijking met metadata.
# Afnemer platformen: Deze zijn verantwoordelijk voor het gebruik van de gegevens uit de distributie platformen. Dit kan bijvoorbeeld een gebruikersinterface zijn voor metadata zoals een begrippencatalogus of een gegevenscatalogus, of een gevirtualiseerde omgeving die wordt gebruikt om gegevens te gebruiken met behulp van visualisatietools of programmeertools. +
Het werkingsgebied van GABI wordt in de Pitch beschreven als het gehele onderwijsdomein. In paragraaf 2.1 van de PrSA document wordt het doel van BI gedefinieerd als het helpen van DUO om informatie-inzichten te verkrijgen die kunnen worden gebruikt om de prestaties te verbeteren en rechtmatigheid aan te tonen. Uit verder onderzoek naar de drijvende factor achter GABI, de wet WRO, blijkt dat alle onderwijsraden worden geraakt door de invoering van de wet en dus ook door invoering van GABI, wat onderdeel gaat worden van de uitvoering van de wet.
GABI lijkt een realisatie van de Onderwijsgegevensplatform ketenarchitectuur die eerder is gescand en behandeld tijdens AR 14 april 2022. In die scan was het werkingsgebied onduidelijk en leek het vooral om een DUO architectuur te gaan. De uitwerking van de architectuur van GABI in de brondocumenten lijkt deze aanname te bevestigen. +
In de brondocumenten van het GABI worden gegevens niet nader gespecificeerd. Echter, door de verwijzing naar de Wet register onderwijsdeelnemers (WRO), kan worden afgeleid dat het waarschijnlijk gaat om de volgende gegevenssoorten: Basisgegevens deelname, Basisgegevens persoon, en Basisgegevens resultaat.
Er bestaat een doorstroommonitor afspraak (https://www.edustandaard.nl/standaard_afspraken/doorstroommonitor/doorstroommonitor-6-0/), beheerd door de Werkgroep Doorstroommonitor. In de doorstroommonitor staat dat gegevens worden aangeleverd door DUO. Dit kan mogelijk geraakt worden door WRO artikel 23, indien het hier gaat om basisgegevens. In de specificatie van de Doorstroommonitor (https://www.edustandaard.nl/app/uploads/2017/05/Specificatie-6.0-van-de-afspraak-Doorstroommonitor.pdf) staat bij de definitie van deelnemerkenmerken dat het om gegevens gaat met betrekking tot de onderwijsinstelling waarbij een onderwijsdeelnemer was ingeschreven en de datum van in- en uitschrijving.
Dit komt overeen met WRO artikel 10, dat stelt dat de basisgegevens, naast de identificerende gegevens, in elk geval gegevens omvatten met betrekking tot de onderwijsinstelling waar de onderwijsdeelnemer is of was ingeschreven, en de datum van in- en uitschrijving bij de desbetreffende onderwijsinstelling. +
De verantwoordelijkheid voor het beheer van de HOVI standaard ligt volgens het Governance document bij de stuurgroep. Momenteel is de opdrachtgever Studiekeuze123, maar dit kan veranderen naar een andere partij volgens het Governance document. Afstemming op andere afspraken binnen de onderwijsketen, zoals RIO, wordt nu gedaan volgens de Hovi website door nauwe samenwerking met het projectleiderschap of wordt, zoals bij de OO-API gedelegeerd naar de softwarebouwer. Hoe deze afstemming tijdens de beheerfase of bij verandering van opdrachtgever gaat verlopen, is nergens in de gescande documenten terug te vinden. +
'''Is er een relatie tussen HOVI en RIO?'''
RIO (Registratie Instellingen en Opleidingen) is het nieuwe CROHO. RIO bevindt zich nog in de ontwerp-fase. Binnen RIO krijgen de instellingen gelegenheid om de eigen onderwijswerkelijkheid weer te geven op een centrale plek, gekoppeld aan de formele registers zoals die nu onderdeel zijn van CROHO. Met de projectleiding van RIO wordt gedurende de ontwikkeling van HOVI intensief afgestemd, zowel inhoudelijk als planmatig.
'''Is er een relatie tussen HOVI en OO-API?'''
De Open Onderwijs API is een open standaard voor het delen van onderwijsdata. Een API (Application Programming Interface) is een set definities waarmee softwareprogramma’s onderling kunnen communiceren. Aansluiting op deze standaard is één van de opdrachten aan de HOVI-ontwikkelaars. (PvE p.21) Uit een vergelijking van de HOVI API en OO-API bleek echter dat deze niet dezelfde begrippen hanteerde.
'''Eenmalige registratie meervoudig gebruik:'''
Uit de HOVI Specificatie (p.3) valt af te leiden dat de HOVI als centrale database voor studiekeuzeinformatie wil fungeren. Onderwijsinstellingen kunnen op HOVI zelf informatie over hun onderwijsaanbod beheren. (Governance p.7) Afnemers kunnen deze informatie van deze centrale plek afnemen. Uit een gesprek met Studiekeuze123 is gebleken dat wanneer RIO voor het HO gaat gelden, de HOVI zich bij RIO aansluit. Hierdoor zal worden voorkomen dat ketenpartijen twee keer moeten aanleveren. +
Informatie met betrekking tot governance van de HOVI valt te halen uit de documenten “Governance HOVI.pdf” en “200805 Afnemers.pdf”.
Alle belangen in kaart & Geclusterde belanghebbenden: In het Afnemers document van de HOVI worden afnemers in kaart gebracht en worden deze ook in een aantal groepen onderverdeeld.
Betrokken belanghebbenden: Met name studiekeuzevoorlichtingpartijen worden door HOVI benaderd over de impact die de verandering van HODEX naar HOVI gaat hebben. (Afnemers p.1) Onder het takenpakket van de HOVI stuurgroep valt het organiseren van de communicatie rondom en vanuit het programma. (Governance p.6)
Bewaak relaties met andere afspraken: Uit het Governance document wordt niet duidelijk hoe relaties worden bewaakt met andere afspraken. Het bewaken van relaties van met andere afspraken binnen de keten (bijvoorbeeld RIO) wordt niet als taak van de stuurgroep genoemd. Wel wordt er in het aanbestedingsdocument (P21) de vraag bij de softwarebouwer neergelegd om met een architectuur te komen die aansluit op lopende ontwikkelingen zoals RIO en OO-API. Het wordt niet duidelijk uit voor ons beschikbare documentatie hoe de aannemer invulling heeft gegeven aan deze vraag. +
Openbare register gegevens worden ontsloten als Linked Open Data:
HOVI is geen openbaar register. Alleen geregistreerde afnemers kunnen met een key via de HOVI API data afnemen, wanneer ze akkoord gaan met de leveringsovereenkomsten. Gegevens worden niet ontsloten als LOD, maar via de HOVI API.
'''Aansluiting op RIO'''
Parallel aan de ontwikkeling van de HOVI loopt ook de ontwikkeling van RIO. In het HOVI datamodel wordt er bij “organization” verwezen naar een BRIN nummer om de koppeling te leggen met het BRIN register. (de voorloper van RIO) De architectuur van de HOVI zal dus moeten kunnen aansluiten op lopende ontwikkelingen bij RIO. In het HOVI aanbestedingsdocument (p.21) wordt aan de inschrijver gevraagd om rekening te houden met aansluiten op ontwikkelingen bij RIO. Ook in de HOVI specificatie (p.6) wordt opgemerkt in een kanttekening dat mogelijk de definitie van een unieke croho code nog kan wijzigen na implementatie van DUO. Hoe deze veranderingen precies gefaciliteerd worden werd niet duidelijk uit de beschikbare brondocumentatie. Onder “veelgestelde vragen” op de HOVI website gesteld dat er intensieve afstemming is met de RIO projectleiding, zowel inhoudelijk als planmatig.
Onderdeel van het project HOVI is “Een synchronisatietool waarmee de opleidingenset synchroon blijft met de CROHO-registratie (later koppeling met RIO).” +
'''Voortbouwen op bestaande federaties:'''
Op pagina 17 van het aanbestedingsdocument punt 65 wordt als eis gesteld dat architectuur aansluiten op SurfConext toestaat. Dit is in lijn met het ROSA ontwerpkader Voortbouwen op bestaande federaties. Hoe de identificatie en autorisatie meer concreet wordt vormgegeven wordt niet duidelijk uit de voor ons beschikbare documentatie.
'''API-sleutel'''
Op https://api.hovi.nl/api-opzet/ is beschreven dat voor autorisatie gebruik gemaakt wordt van API-keys. Afnemers en instellingen (die data kunnen bewerken) gebruiken dezelfde API. Schrijfrechten kunnen per organisatie beperkt worden, maar de API dwingt geen verdere rechtenbeperkingen binnen organisaties af - schrijf- en publicatierechten per opleiding worden in de HOVI Editor zelf geimplementeerd of moeten door de instellingen zelf in hun eigen koppelingen +
'''Vertrouwelijkheid'''
HOVI bevat geen vertrouwelijke informatie. Alle data in de HOVI-database is openbare data die gratis wordt aangeboden na registratie van de afnemer en ondertekening van leveringsovereenkomsten door die afnemer, waarin afspraken zijn vastgelegd over actualiteit, bronvermelding en dergelijke.
Volgens het Pitch document leveren instellingen contactgegevens op verzoek zoveel mogelijk functioneel. Daarnaast worden ook afnemers geregistreerd.
'''Integriteit'''
De onderwijsinstelling ‘als geheel’ krijgt de mogelijkheid om via aansluiting op de API data in HOVI te registreren en te bewerken. Binnen deze aansluiting worden geen rollen onderscheiden of autorisatiematrices gebruikt. Dat betekent dat de instelling zelf verantwoordelijk is voor (het inrichten van) de juiste autorisaties en toewijzingen aan rollen en personen in systemen die op HOVI aansluiten. Ook traceerbaarheid van handelingen zal vanuit die systemen moeten worden ondersteund.
'''Beschikbaarheid'''
Buiten enkele beschikbaarheidseisen voor de HOVI-voorziening (uptime) zijn er geen duidelijk geformuleerde eisen aan de beschikbaarheid van de inhoud van HOVI (juistheid, tijdigheid en volledigheid van data). Juist deze eisen zijn van belang voor het gebruik van data uit de HOVI in de keten. Dat belang is wederzijds; afnemers moeten weten wat ze kunnen verwachten t.a.v. de beschikbare data en instellingen moeten weten wat ze kunnen verwachten t.a.v. het gebruik door afnemers. Het is nu bijvoorbeeld niet duidelijk welke reactietijd van studiekeuzesites verwacht mag worden, nadat er nieuwe informatie over open dagen door een onderwijsinstelling is aangeleverd aan de HOVI. +