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