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
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. +