Eigenschap:Scanbevindingen

Uit ROSA Wiki
Naar navigatie springen Naar zoeken springen
Kennismodel
:
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:


Showing 50 pages using this property.
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.  
Het project omvat een stevige infrastructurele vernieuwing die veel partijen raakt.  +
“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.  +
[[Bestand:ZG EF2.0.png|miniatuur|Zeggenschappen rondom de Entree Federatie]]  +
'''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-00005BD4-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.  +