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