<?xml version="1.0"?>
<LijstOpenStandaarden><Standaard><Naam>SEPA</Naam><Omschrijving>Betalingsgegevens</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Financi&#xEB;le administratie</Trefwoorden><Beheerorganisatie>European Payments Council</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>4.1</Versie><Domein>Economie en werk</Domein><EuropeseStatusMsp>Ja</EuropeseStatusMsp><Functioneel_toepassingsgebied>Toepassingen betrokken bij giraal betalingsverkeer in Euro binnen de SEPA landen (inclusief binnenlands betalingsverkeer)</Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>De Europese Unie streeft naar een interne markt voor betalingsverkeer, zonder grenzen. De SEPA-standaarden zijn bedoeld om het giraal betalingsverkeer binnen Europa goed op elkaar af te stemmen (incl.binnenlands betalingsverkeer). De voordelen van de SEPA-standaarden zijn eenvoudigere internationale betalingen, ruimere overstapmogelijkheden naar andere (buitenlandse) banken en verhoogde kwaliteit van betalingsinformatie. </Nut><Werking>De SEPA-standaarden beschrijven de semantiek en bedrijfsregels voor overboekingen en incasso&#x2019;s. De standaard is succesvol geadopteerd en wordt breed gebruik. Vanwege de verplichte en brede adoptie is opname op de lijst niet meer nodig.</Werking><Volledige_naam>SEPA Credit Transfer Rulebook SEPA Direct Debit Rulebook</Volledige_naam><Specificatiedocument>http://www.europeanpaymentscouncil.eu/</Specificatiedocument><Hulpmiddelen>Betaalvereniging Nederland heeft een Nederlands profiel ontwikkeld voor de SEPA-standaarden: &#x201C;Implementation Guideline(s) for the Netherlands&#x201D;.&#xD;
&#xD;
 &#xD;
&#xD;
In Europese regelgeving zijn voor SEPA interoperabiliteitseisen geformuleerd waarin met name de standaarden IBAN, BIC en ISO 20022 XML terugkomen. Dit is onder andere vastgelegd in de Europese verordening &#x201C;tot vaststelling van technische en bedrijfsmatige vereisten voor overmakingen en automatische afschrijvingen in euro en tot wijziging van Verordening (EG) nr. 924/2009&#x201D;.</Hulpmiddelen><Toelichting_bij_opname>Vanwege succesvolle adoptie is opname op de 'Pas toe of leg uit'-lijst niet meer nodig. Vandaar dat standaard in april 2015 is verwijderd van de lijst.</Toelichting_bij_opname><Adoptieadviezen>Bij de opname op de "Pas toe of leg uit"-lijst heeft het College Standaardisatie een oproep gedaan aan:&#xD;
&#xD;
&#xD;
	de bancaire sector om initiatief te nemen voor implementatieondersteuning en voor verdere standaardisatie;&#xD;
	SEPA Nederland om operationele aspecten van de migratie te verbeteren en ervoor te zorgen dat ervaringen worden gedeeld.&#xD;
	de Nederlandse overheid om de betrokkenheid van Nederland bij de (door-) ontwikkeling van de SEPA-standaarden te vergroten. Dit kan middels een afvaardiging van de Nederlandse overheid in het Stakeholder Forum of het voordragen van een Nederlands onafhankelijk lid in het Scheme Management Committee. Het ministerie van Financi&#xEB;n lijkt voor beide activiteiten de meest aangewezen partij.&#xD;
&#xD;
&#xD;
Deze activiteiten zijn opgepakt en ingevuld.</Adoptieadviezen><Datum_van_aanmelding>11-11-2010</Datum_van_aanmelding><Datum_van_besluit>22-04-2015</Datum_van_besluit><Waarvoor_geldt_de_verplichting>Deze standaard is inmiddels verwijderd van de lijst met standaarden in verband met Europese wetgeving waardoor alle Europese lidstaten deze standaarden hebben geadopteerd.</Waarvoor_geldt_de_verplichting></Standaard><Standaard><Naam>DNS</Naam><Omschrijving>Netwerkcommunicatie</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Netwerk, Website, Internet</Trefwoorden><Beheerorganisatie>IETF</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>Nov 1987</Versie><Domein>Veilig internet</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Netwerken: voor het omzetten van URL's naar IP adressen</Functioneel_toepassingsgebied><Nut>Het DNS protocol maakt het mogelijk om binnen netwerken gebruik te maken van URL&#x2019;s in plaats van ip-adressen.</Nut><Werking>DNS maakt het mogelijk dat de URL's op de achtergrond vertaald worden naar ip-adressen zodat hosts op het netwerk elkaar kunnen vinden, zonder dat de gebruiker ziet welk ip-adres er gekoppeld is aan een URL.</Werking><Volledige_naam>Domain Name System</Volledige_naam><Specificatiedocument>Specificatiedocument DNS A (externe link)&#xD;
	Specificatiedocument DNS B</Specificatiedocument><Hulpmiddelen>Factsheet DNS-amplificatie, NCSC, 30 oktober 2013Doorzoek website op relevante beveiligingsadviezen van NCSC</Hulpmiddelen><Datum_van_besluit>20-08-2009</Datum_van_besluit></Standaard><Standaard><Naam>Webrichtlijnen</Naam><Omschrijving>Vervangen door DigiToegankelijk (EN 301 549&#xA0;met daarin&#xA0;opgenomen&#xA0;WCAG 2.0)</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Website, Internet</Trefwoorden><Beheerorganisatie>Logius</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>2.0</Versie><Domein>Openbaar en toegankelijk</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Webgebaseerde informatie-, interactie-, transactie- en participatiediensten.</Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>De Webrichtlijnen bevatten richtlijnen die content op websites en in webapplicaties optimaal bruikbaar en toegankelijk maken voor gebruikers op uiteenlopende apparaten en besturingssystemen. De Webrichtlijnen zorgen ervoor dat content op websites en in webapplicaties ook toegankelijk is voor mensen met een functiebeperking.&#xD;
&#xD;
In oktober 2016 zijn de Webrichtlijnen 2 op de 'pas-toe-of-leg-uit'-lijst vervangen door 'Digitale Toegankelijkheid'.</Nut><Werking>De Webrichtlijnen bestaan uit een verzameling regels die bij de bouw en het onderhoud van een website of webapplicatie toegepast dienen te worden om de toegankelijkheid van de content op de website te bevorderen en om de bouwkwaliteit te verhogen. Deze regels vallen in twee groepen:&#xD;
&#xD;
&#xD;
	De richtlijnen van de standaard WCAG 2.0, gepubliceerd door het W3C, zorgen voor de toegankelijkheid van de content, ook voor mensen met een functiebeperking.&#xD;
	De richtlijnen van Principe Universeel zorgen voor bouwkwaliteit, waardoor de content duurzaam, uitwisselbaar en goed te onderhouden wordt.</Werking><Volledige_naam>Webrichtlijnen</Volledige_naam><Specificatiedocument>Veelgestelde vragen rondom toegankelijkheid.</Specificatiedocument><Conformiteitstest>De volgende sites helpen om een website of een document te testen op een aantal aspecten van WCAG 2.0 (de toegankelijksrichtlijnen die besloten liggen in EN 301 549 en Webrichtlijnen):
Webrichtlijnen check voor websites
Webrichtlijnen check voor PDFs op websites
Dit zijn geen formele conformiteitstests.&#xA0; Een aantal aspecten van webrichtlijnen kan niet automatisch getest worden, en vereist validatie met menselijke tussenkomst.
Organisaties als Stichting drempelvrij.nl en Stichting Accessibility kunnen u helpen met het testen en/of certificeren van uw website en webcontent op WCAG 2.0. Ook zijn er tools om geautomatiseerde tests uit te voeren, zoals SiteImprove en GewoonToegankelijk.</Conformiteitstest><Toelichting_bij_opname>Versie 2 vervangt de eerder opgenomen versie 1.2 van de Webrichtlijnen.&#xD;
&#xD;
De Europese standaard EN 301 549 voor de toegankelijkheid van ICT producten en diensten wordt eind 2016 op Europees niveau verplicht gesteld. De Nederlandse overheid zal deze medio 2018 omzetten in nationale wetgeving. Het Forum Standaardisatie heeft na een openbare procedure besloten om Webrichtlijnen 2 te vervangen door EN 301 549 en WCAG 2.0 (samen opgenomen onder de noemer 'Digitale Toegankelijkheid') op de 'Pas-toe-of-leg-uit'-lijst.</Toelichting_bij_opname><Adoptieadviezen>De 'pas-toe-of-leg-uit' verplichting voor Webrichtlijnen geldt voor web gebaseerde diensten die een overheidsorganisatie aanbiedt aan burgers, bedrijven en andere overheden. De 'pas-toe-of-leg-uit' verplichting geldt niet voor intranetten en websites die alleen binnen een overheidsorganisatie worden gebruikt. Toegankelijkheid van intranetten is daarom niet onbelangrijk. Door interne websites niet universeel toegankelijk te maken kan een organisatie bepaalde (groepen) werknemers uitsluiten. Ook kan het moeilijker worden voor gebruikers om informatie te vinden en hergebruiken. Het is daarom zeer aan te bevelen om ook voor intranetten, interne websites en web applicaties de Webrichtlijnen toe te passen.</Adoptieadviezen><Datum_van_aanmelding>01-12-2010</Datum_van_aanmelding><Datum_van_besluit>23-06-2011</Datum_van_besluit><Toelichting>Webrichtlijnen 2 zijn behalve op websites, ook van toepassing op de documenten die via die websites toegankelijk zijn. PDF en ODF documenten die door de overheid gepubliceerd worden moeten dus voldoen aan Webrichtlijnen 2.</Toelichting><Waarvoor_geldt_de_verplichting>Bij de bouw of aanschaf van een website of webapplicatie bedoeld voor burgers, bedrijven en andere overheden. Strikt genomen geldt de verplichting niet voor intranet-websites die alleen binnen een overheidsorganisatie worden gebruikt.</Waarvoor_geldt_de_verplichting><Leveranciers>SIMgroep</Leveranciers><Sjabloon-bestektekst>Voor Inkoop zal Webrichtlijnen met name voorkomen onder de volgende categorie&#xEB;n en CPV codes:
48224000-4 Software voor webpage-editen
72000000-5 IT-diensten: adviezen, softwareontwikkeling, internet en ondersteuning
72330000-2 Diensten voor inhouds- of datastandaardisatie en &#x2013;classificatie
72413000-8 Diensten voor het ontwerpen van websites
48300000-1 Software voor het maken van documenten, tekeningen, afbeeldingen, dienstregelingen en productiviteit
72212300-2 Diensten voor ontwikkeling van software voor het maken van documenten, tekeningen, afbeeldingen, dienstregelingen en productiviteit
72512000-7 Documentbeheerdiensten
72330000-2 Diensten voor inhouds- of datastandaardisatie en &#x2013;classificatie</Sjabloon-bestektekst><Advies_aan_beheerder>Bij de opname heeft het College Standaardisatie het ministerie van Binnenlandse Zaken opgeroepen om een viertal aanvullende acties ter verdere bevordering van de adoptie van Webrichtlijnen versie 2 uit te voeren, namelijk:
Bieden van voldoende implementatieondersteuning;
Uitwerken van adoptiestrategie;
Aanpassen en heroverwegen van regelgeving;
Webrichtlijnen internationaal inbrengen.</Advies_aan_beheerder></Standaard><Standaard><Naam>NTA9040</Naam><Omschrijving>Ondernemingsdossier</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Financi&#xEB;le administratie, Informatiemanagement</Trefwoorden><Beheerorganisatie>NEN</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>NTA 9040-1: Regelhulp, NTA 9040-2: Aanvraag en rapportage, NTA 9040-3: Toezicht</Versie><Domein>Economie en werk</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>De standaard is van toepassing voor overheden die expliciet met ondernemingen hebben afgesproken een Ondernemingsdossier in te zetten voor de informatie-uitwisseling met ondernemingen. De standaard werkt op drie functionele gebieden van de informatie-uitwisseling tussen ondernemingen en overheden:&#xD;
&#xD;
Het ondersteunen van ondernemingen bij het geautomatiseerd bepalen van de relevante voorschriften en bijbehorende maatregelen voor vastlegging in een Ondernemingsdossier;&#xD;
&#xD;
Het faciliteren van het digitaal indienen van aanvragen en meldingen vanuit een Ondernemingsdossier;&#xD;
&#xD;
Het gebruik van een Ondernemingsdossier als bron van bedrijfsinformatie in het kader van het toezicht.</Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>DEZE STANDAARD IS PER MEI 2016 VERWIJDERD VAN DE LIJST. De standaard is nog wel te gebruiken en toe te passen, maar bij de opname van de standaard was voorzien dat er vele branchespecifieke implementaties naast elkaar zouden ontstaan, waardoor de verplichting van een afsprakenstelsel (NTA 9040) wenselijk was. Door wijzigingen in de standaard en de plannen voor toekomstige ontwikkelingen van het Ondernemingsdossier maken dat opname op de lijst met open standaarden en bijbehorende verplichting geen toegevoegde waarde meer heeft.
Het doel van de standaard: Om de regeldruk voor ondernemers te verminderen is er het ondernemersdossier. Met deze applicatie kunnen ondernemers effici&#xEB;nt samenwerken met overheidspartijen via eenmalige gegevensuitvraag. Het &#xA0;ondernemingsdossier helpt ondernemers om zelfstandig hun weg te vinden bij het toepassen van regels, zoals het aanvragen van een vergunning, en helpt inspecties bij gericht toezicht. In de NTA9040 zijn de gedetailleerde afspraken m.b.t. de informatie-uitwisseling vastgelegd.</Nut><Werking>In de NTA worden afspraken over het koppelvlak waarover informatie wordt uitgewisseld binnen het ondernemingsdossier-concept beschreven.&#xA0;De standaard maakt het mogelijk dat meerdere aanbieders en branches in verschillend tempo en met eigen invulling een ondernemingsdossier kunnen starten.</Werking><Volledige_naam>Nederlandse Technische afspraak 9040</Volledige_naam><Specificatiedocument>Specificatiedocumenten zijn beschikbaar op website van NEN</Specificatiedocument><Hulpmiddelen>Refentiearchitectuur</Hulpmiddelen><Toelichting_bij_opname>In het Nationaal Beraad Digitale Overheid van 17 mei 2016 is op advies van het Forum Standaardisatie besloten om de NTA9040 te verwijderen van de lijst met standaarden. Informatie over de procedure is te vinden in onderstaande documentatie.&#xD;
&#xD;
Bij de oorspronkelijke opname had het College, als een voorwaarde voor opname,  de indiener gevraagd om toe te lichten welke onderdelen van StUF binnen de standaard worden gebruikt. Deze toelichting is gegeven waardoor de standaard op de 'Pas toe of leg uit' -lijst kon worden opgenomen. Zie toelichting op de relatie met StUF.&#xD;
 &#xD;
&#xD;
 </Toelichting_bij_opname><Adoptieadviezen>Additionele Forum-adviezen ten aanzien van de adoptie van de standaard:&#xD;
&#xD;
Het oproepen van het ministerie van EZ de kwaliteit en de duurzaamheid van het beheer te borgen door:&#xD;
&#xD;
&#xD;
	Afstemming met de beheerders van de in de NTA gebruikte standaarden, structureel onderdeel te maken van het beheerproces. Min. EZ wordt gevraagd hierover, een half jaar na opname, te rapporteren aan Forum Standaardisatie.&#xD;
	Voor het eindigen van het programma Ondernemingsdossier in 2016, een onderzoek uit te voeren naar het toekomstige beheer van de standaard, voordat in 2016 wordt besloten de markt het beheer van de standaard over te laten nemen.&#xD;
&#xD;
&#xD;
Het oproepen van het ministerie van EZ de vergoeding die moet worden betaald voor het verkrijgen van de standaard af te kopen voor minimaal de opstartfase van de standaard (tot 2016).&#xD;
&#xD;
Het oproepen van het ministerie van EZ een implementatieplan op te stellen, waarin concrete acties en beschikbare middelen worden benoemd die overheden en marktpartijen ondersteunen bij de implementatie van de standaard. Min. EZ wordt gevraagd hierover, een half jaar na opname, te rapporteren aan Forum Standaardisatie.&#xD;
&#xD;
Het oproepen van het ministerie van EZ om de ontwikkelingen rondom het &#x2018;Omgevingsloket&#x2019;, dat momenteel ook wordt uitgerold binnen gemeenten, te volgen en hier zo nodig afstemming in te zoeken.&#xD;
&#xD;
Tot slot wordt het ministerie van EZ opgeroepen om, in overeenstemming met VNG Realisatie, in de volgende versie van de NTA aanvullend de taxonomie van de StUF standaard op te nemen. Zodat die versie volledig StUF-compliant zal zijn. Deze volgende versie van de NTA dient ter toetsing te worden voorgelegd aan Forum en College.&#xD;
&#xD;
Het oproepen van NEN om de procesafspraken, die gelden bij het beheren en doorontwikkelen van de NTA, onderdeel te maken van de documentatie van de NTA zelf. Specifiek gaat het om de vermelding van de geldigheidsduur van de NTA en de procesafspraken die gelden voor kleine en grote wijzigingen aan de NTA.</Adoptieadviezen><Datum_van_besluit>29-11-2012</Datum_van_besluit><Toelichting>Tijdens de expertgroeptoetsing heeft een aantal partijen zorgen geuit over de wijze waarop StUF wordt toegepast binnen de standaard. De indiener heeft hierover de volgende notitie opgesteld waarin de relatie wordt toegelicht: - Reactie indiener op initieel expertadvies - Reactie VNG Realisatie- Reactie DIMPACT 1. De betekenis en schrijfwijze van de basisgegevens van een aanvrager/contactpersoon (NAW gegevens en KvK gegevens) zijn gebaseerd op het Referentiemodel Stelsel van Gemeentelijke Basisgegevens (RSGB van StUF). 2. De betekenis en schrijfwijze van een statusaanduiding van een aanvraag zijn gebaseerd op het Referentiemodel Gemeentelijke Basisgegevens Zaken (RGBZ van StUF). StUF kent ook berichtdefinities voor geautomatiseerde gegevensuitwisseling. De NTA 9040 hanteert eigen berichtdefinities, die niet gebaseerd zijn op StUF. Om die reden kunnen partijen die momenteel StUF niet gebruiken wel NTA9040 berichten verwerken (mits zij uiteraard de NTA9040 standaard volgen). Het Ondernemingsdossier hanteert het uitgangspunt dat voor de standaarden (NTA) zoveel mogelijk gebruik wordt gemaakt van bestaande (overheid)standaarden. Als sprake is van nieuwe ontwikkelingen worden die gevolgd en ingepast. Daarom wordt deelgenomen aan de discussie over de verbreding van de StUF standaard voor het stelsel van basisregistraties en zal in een volgende versie van de NTA altijd worden bezien of een bredere of nieuwe standaard in aanmerking komt voor gebruik in de NTA in plaats van de bestaande (StUF) standaard. Het NTA proces borgt dit ook omdat partijen die betrokken zijn of worden (VNG Realisatie e.a.) bij nieuwe versies van de NTA9040 hun inbreng kunnen leveren.&#xD;
&#xD;
Gezien de beperkte adoptie, de wijzigingen in de standaard en de plannen voor toekomstige ontwikkelingen van het Ondernemingsdossier maken dat de opname op de lijst met open standaarden en bijbehorende verplichting geen toegevoegde waarde meer heeft.  Op advies van Forum heeft het Nationaal Beraad besloten deze standaard te hierdoor verwijderen.</Toelichting><Waarvoor_geldt_de_verplichting>Deze verplichting is komen te vervallen. De standaard is toe te passen in de gevallen dat er sprake is van gegevensuitwisseling met bedrijfsleven is via een ondernemingsdossier.</Waarvoor_geldt_de_verplichting></Standaard><Standaard><Naam>COINS</Naam><Omschrijving>BIM uitwisselingsstandaard</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Metadata, BIM, Bouw</Trefwoorden><Beheerorganisatie>BIM Loket</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>2.0</Versie><Domein>Bouwen en wonen</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>COINS moet worden toegepast op het in samenhang vastleggen en uitwisselen van informatie en documenten tussen opdrachtgevers en opdrachtnemers in de grond-, weg- en waterbouw gedurende de gehele levenscyclus.</Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>In de ontwerp-, realisatie-, en onderhoudsfases van bouwprojecten wisselen opdrachtgevers en opdrachtnemers heel diverse informatie uit, die wel met elkaar verbonden is. Denk aan eisen- en functiespecificaties, objectenbomen, GIS-data, 2D-tekeningen, 3D-modellen, IFC-modellen en objecttype-bibliotheken.  De uitwisseling van deze informatie gaat vaak moeizaam omdat partijen verschillende software gebruiken waardoor de informatie niet uitwisselbaar of leesbaar is. &#xD;
&#xD;
COINS maakt het mogelijk om data over objecten, opgeslagen in verschillende digitale formaten die voldoen aan verschillende standaarden, in onderlinge samenhang en systeemonafhankelijk uit te wisselen. Dankzij COINS kunnen opdrachtgevers en opdrachtnemers die software van verschillende leveranciers gebruiken gemakkelijker samenwerken. </Nut><Werking>COINS gaat uit van een kernmodel dat een semantische beschrijving geeft van objecten, hun onderlinge relatie(s) en hun kenmerken. COINS maakt gebruik van de metadatastandaarden RDF en OWL, die beiden op de lijst aanbevolen standaarden van het Forum Standaardisatie staan.&#xD;
&#xD;
COINS beschrijft ook een standaard containerformaat om objecten met hun metadata uit te wisselen.  Leveranciersafhankelijke software exporteert data naar, en importeert data van een leveranciersonafhankelijk COINS containerbestand.  Zo kan de data in een neutraal formaat, leveranciersonafhankelijk uitgewisseld worden.</Werking><Volledige_naam>Constructieve Objecten en de Integratie van Processen en Systemen</Volledige_naam><Specificatiedocument>COINS 2.0 specificatiedocument</Specificatiedocument><Community>COINS 2.0 wordt onder andere gebruikt door Rijkswaterstaat, gemeente Rotterdam, gemeente Amsterdam, provincie Gelderland en provincie Noord-Holland. Daarnaast heeft onder andere ProRail ervaring opgebouwd met het gebruik van de standaard.</Community><Conformiteitstest>Het BIM Loket ontwikkelt momenteel een COINS Validation Service. Hiermee kunnen gebruikers hun COINS Containers (laten) testen op conformiteit met de standaard. De COINS Validation Service wordt naar verwachting in eind 2017 gepubliceerd op de website van het BIM Loket.</Conformiteitstest><Toelichting_bij_opname>Wanneer COINS wordt uitgevraagd als onderdeel van een bouwproject, dan is het gehele ICT perceel van het bouwproject bepalend voor het van toepassing zijn van de Instructie rijksdienst bij aanschaf van ICT producten of diensten (http://wetten.overheid.nl/BWBR0024717/2008-11-23). Dus niet alleen de kosten van de software licentie.</Toelichting_bij_opname><Adoptieadviezen>In de vergadering van 7 oktober 2020 besloot het Forum Standaardisatie om de bouwstandaarden te evalueren in het kader van regulier onderhoud op de &#x2018;Pas toe of leg uit&#x2019;-lijst. In 2021 is dit onderzoek afgerond. Het onderzoek richtte zich met name op de huidige relevantie van de standaard, het functioneel toepassingsgebied, het gebruik, belang, beheer en de stand van zaken rond de adoptie van de standaard. &#xD;
&#xD;
Hieronder de conclusies voor COINS:&#xD;
&#xD;
&#xD;
	De standaard heeft zijn &#x2018;end of life&#x2019; bereikt. Dit wordt onderschreven door alle ge&#xEF;nterviewde experts en ook actief uitgedragen op de website van de beheerder BIM Loket.&#xD;
	Er is al een vervangende standaard voor COINS: ICDD, die in combinatie met NTA 8035 wordt gezien als vervanger voor COINS. Ook dit wordt onderschreven door alle ge&#xEF;nterviewde experts en actief uitgedragen door de beheerder van COINS.&#xD;
	COINS wordt nog maar door twee partijen (Rijkswaterstaat en Provincie Gelderland) toegepast en deze geven aan het gebruik van de standaard af te bouwen.&#xD;
	Een standaard voor het in samenhang uitwisselen van bouwinformatie heeft toegevoegde waarde en verdient zijn plek op de lijst open standaarden van het Forum Standaardisatie.&#xD;
&#xD;
&#xD;
Ten aanzien van COINS worden aan het Forum Standaardisatie de volgende aanbevelingen gedaan:&#xD;
&#xD;
&#xD;
	Start per direct de procedure voor verwijdering van COINS van de lijst open standaarden van het Forum Standaardisatie.&#xD;
	Nodig BIM Loket per direct uit om ICDD en NTA 8035 aan te melden voor opname op de lijst open standaarden van het Forum Standaardisatie, en start op basis hiervan de procedure voor aanmelding van de standaard op de &#x2018;Pas toe of leg uit&#x2019;-lijst.</Adoptieadviezen><Consultatie_verwijdering>Reacties uit openbare consultatie</Consultatie_verwijdering><Datum_van_aanmelding>28-04-2017</Datum_van_aanmelding><Datum_van_besluit>24-05-2018</Datum_van_besluit><Toelichting>Naar aanleiding van de evaluatie is in het najaar van 2021 de procedure voor verwijdering van COINS gestart (zie voor meer informatie onder het kopje "Adoptieadviezen"). Op 2 februari 2023 stemde het OBDO in met het niet meer verplichten of aanbevelen van COINS aan de overheid.&#xD;
&#xD;
COINS 2.0 maakt gebruik van de standaarden RDF en OWL. COINS 2.0 kan gebruikt worden om IFC bestanden uit te wisselen in combinatie met gerelateerde data.</Toelichting><Waarvoor_geldt_de_verplichting>Voor het uitwisselen van samenhangende digitale bouwinformatie tussen opdrachtgevers en opdrachtnemers.</Waarvoor_geldt_de_verplichting><Software>Er zijn twee open source software implementaties beschikbaar de COINS Navigator en de COINS API.</Software></Standaard><Standaard><Naam>SAML</Naam><Omschrijving>Authenticatie en autorisatie</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Informatiebeveiliging, Internet</Trefwoorden><Beheerorganisatie>OASIS</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>2.0</Versie><Domein>Veilig internet</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>SAML moet worden toegepast op de uitwisseling van authenticatie- en autorisatiegegevens om gebruikers na eenmalig inloggen toegang te geven tot meerdere diensten.</Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-)publieke sector.</Organisatorisch_werkingsgebied><Nut>Security Assertion Markup Language (SAML) is een standaard voor het veilig uitwisselen van authenticatie- en autorisatiegegevens van gebruikers tussen verschillende organisaties. SAML maakt het mogelijk om op een veilige manier via het internet toegang te krijgen tot diensten van verschillende organisaties, zonder dat je per dienst eigen inloggegevens nodig hebt, of bij elke dienst apart moet inloggen.&#xD;
&#xD;
SAML wordt gebruik bij onder andere DigiD machtigen en eHerkenning.</Nut><Werking>Bij SAML spelen drie partijen een rol: de &#x2018;gebruiker&#x2019;, de &#x2018;Identity Provider (IdP)&#x2019; en de &#x2018;Service Provider (SP)&#x2019;. De IdP regelt het authenticatieproces van de gebruiker en kan na succesvolle authenticatie aan de SP gegevens verstrekken over de identiteit, attributen en rechten van een gebruiker.</Werking><Volledige_naam>Security Assertion Markup Language</Volledige_naam><Specificatiedocument>SAML Specifications</Specificatiedocument><Community>Kantara eGovernment SAML 2.0 Implementation Profile&#xD;
	SAML V2.0 Interoperability Deployment Profile V1.0</Community><Hulpmiddelen>SAML tracer Firefox Plugin</Hulpmiddelen><Toelichting_bij_opname>SAML staat al geruime tijd op de 'Pas toe of leg uit'-lijst en wordt nog actief gebruikt bij Nederlandse overheden. Voor single sign-on toepassingen wordt ook OpenID Connect (OID) steeds vaker gebruikt. Hoewel OpenID Connect nog geen 'Pas toe of leg uit'-status heeft, wordt de opkomst van deze standaard erkend. Het ligt in de verwachting dat SAML en OpenID Connect de komende tijd naast elkaar gebruikt zullen worden en dat OpenID Connect zal worden aangemeld voor de 'Pas toe of leg uit'-lijst.Het Overheidsbrede Beleidsoverleg Digitale Overheid (OBDO) heeft in 2018 het functioneel toepassingsgebied aangepast conform de in 2017 vastgestelde standaardsyntaxis. </Toelichting_bij_opname><Adoptieadviezen>Adviezen over SAML die in opdracht van het Forum Standaardisatie zijn uitgebrachtExpertadvies adoptie SAML 2.0 (3 april 2014)Evaluatie SAML 2.0 (29 januari 2018)Oplegnotitie Forum Standaardisatie Evaluatie SAML 2.0 (14 maart 2018) Advisering van het Forum Standaardisatie aan eID over SAML&#x200B;&#x200B;Adviesrol Forum Standaardisatie bij eID-stelsel (5 februari 2013)Invulling adviesrol Forum Standaardisatie t.b.v. eID-stelsel NL (29 maart 2013)Reactie op 'Ontwerp op hoofdlijnen van de werking van het eID Stelsel NL' (22 augustus 2013)Review Uniforme Set van Eisen - eID (14 juni 2017)Routeringsvoorziening en OIDC koppelvlak (7 november 2018)</Adoptieadviezen><Datum_van_aanmelding>31-03-2009</Datum_van_aanmelding><Datum_van_besluit>20-05-2009</Datum_van_besluit></Standaard><Standaard><Naam>OWMS</Naam><Omschrijving>Metadata overheidsinformatie</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Waardelijsten, Metadata, Website</Trefwoorden><Beheerorganisatie>KOOP</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>4.0</Versie><Domein>Openbaar en toegankelijk</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>OWMS moet worden toegepast op het aanbieden van metadata over publieke informatieobjecten op internet.&#xD;
 </Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>OWMS definieert meta-data die de eigenschappen en structuur beschrijven van informatie die de overheid op het Internet publiceert. Hierdoor wordt de overheidsinformatie op het Internet beter vindbaar en beter te interpreteren.</Nut><Werking>OWMS specificeert een verzameling meta-data, dat wil zeggen gegevens die gegevens beschrijven. Het doel van meta-data is de eigenschappen van ongestructureerde gegevens (bijvoorbeeld de inhoud van een website) te kenmerken zodat deze meer structuur krijgen en beter te zoeken en interpreteren zijn. OWMS is gespecificeerd als Dublin Core Application Profile (DCAP) volgens de principes van het Dublin Core Metadata Initiative (DCMI). OWMS beschrijft 'informatieobjecten' die de overheid op het Internet publiceert, zoals artikelen, kamerstukken, bekendmakingen en formulieren. Een beschrijving van een 'informatieobject' bestaat uit een verzameling eigenschappen met hun waarden, bijvoorbeeld 'Taal: Nederlands'. OWMS gebruikt deels eigenschappen gespecificeerd door het DCMI zoals 'Taal', en definieert daarnaast een aantal nieuwe eigenschappen zoals 'Eindverantwoordelijke'. Om aan OWMS te voldoen moet de beschrijving van een informatieobject tenminste een aantal vaste eigenschappen bevatten, waaronder 'Identificatie', 'Titel', 'Informatietype', 'Taal', 'Datum laatste wijziging' en 'Maker' of 'Eindverantwoordelijke'. Deze minimale set eigenschappen heet de 'OWMS kern'. De OWMS standaard laat uitbreiding toe met eigenschappen en waarden voor specifieke toepassingen. Doorgaans wordt OWMS toegepast in centrale voorzieningen die informatie verzamelen uit decentrale bronnen. Voor zo'n voorziening wordt dan een toepassingsprofiel gemaakt. Voorbeelden van dergelijke toepassingsprofielen staan op http://standaarden.overheid.nl/owms.</Werking><Volledige_naam>Overheid.nl Web Metadata Standaard</Volledige_naam><Specificatiedocument>Specificatiedocument OWMS</Specificatiedocument><Adoptieadviezen>Bij de opname heeft het College Standaardisatie de beheerder opgeroepen om een viertal aanvullende acties uit te voeren, namelijk:&#xD;
&#xD;
&#xD;
	Een lijst met leveranciers op te stellen die de standaard ondersteunen;&#xD;
	Een community met gebruikers vorm te geven die op termijn ook bij kunnen dragen aan de financiering van het beheer;&#xD;
	Binnen een jaar na opname ervoor te zorgen dat de waardelijsten ook onderdeel worden van de standaard en de nieuwe versie van de standaard opnieuw aan te melden bij het Forum;&#xD;
	Het initiatief Schema.org en de relatie met OWMS in de gaten te houden. Het Forum te informeren als er hieromtrent relevante ontwikkelingen zijn.&#xD;
&#xD;
&#xD;
Het Forum Standaardisatie heeft op 7 oktober 2020 groen licht gegeven voor het starten van een verwijderingsprocedure van OWMS van de &#x2018;pas toe of leg uit&#x2019;-lijst. Op 2 februari 2023 stemde het OBDO in met het niet meer verplichten of aanbevelen van OWMS aan de overheid.</Adoptieadviezen><Consultatie>Reacties uit openbare consultatie</Consultatie><Datum_van_besluit>15-11-2011</Datum_van_besluit><Datum_van_aanmelding>12-11-2010</Datum_van_aanmelding><Toelichting>SKOS en RDF zijn net als OWMS gebaseerd op de principes van het Dublin Core Metadata Initiative (DCMI). OWMS, RDF en SKOS kunnen worden gezien als verschillende lagen in de bouw van een semantische meta-data structuur. OWMS beschrijft een 'woordenboek' van eigenschappen en bijbehorende waarden voor overheidsinformatie. RDF kan eenvoudige relaties van het type 'onderwerp - werkwoord - lijdend voorwerp' tussen deze eigenschappen beschrijven. SKOS bouwt met behulp van RDF een kennissysteem door concepten te defini&#xEB;ren en betekenis te geven.</Toelichting><Waarvoor_geldt_de_verplichting>De standaard is verplicht bij de bouw of doorontwikkeling van een website waarop meta-data wordt gebruikt.
Het gebruiken van meta-data is op zich niet verplicht. Maar als een website meta-data gebruikt, is OWMS verplicht.</Waarvoor_geldt_de_verplichting><Sjabloon-bestektekst>Voor Inkoop zal OWMS met name voorkomen onder de volgende categorie&#xEB;n en CPV codes:
72330000-2 Diensten voor inhouds- of datastandaardisatie en &#x2013;classificatie
72413000-8 Diensten voor het ontwerpen van websites&#xA0;</Sjabloon-bestektekst></Standaard><Standaard><Naam>OIDC</Naam><Omschrijving>Authenticatie</Omschrijving><Lijst>Archief</Lijst><Trefwoorden/><Beheerorganisatie>OpenID Foundation</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>1.0</Versie><Domein>Veilig internet</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>OpenID Connect kan toegepast worden bij het beschikbaar stellen van federatieve authenticatiediensten.</Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>OpenID Connect (OIDC) is een open en gedistribueerde manier om &#xE9;&#xE9;n authenticatiedienst naar keuze te kunnen hergebruiken bij meerdere (semi-)overheidsdienstverleners, bij gebruik vanuit onder andere webapplicaties en mobiele apps. Belangrijkste redenen om op OIDC in te zetten is de actieve ontwikkelingen en de mobile-first strategie ondersteuning van digitale overheidsdiensten.</Nut><Werking>OIDC bouwt voort op OAuth 2.0. Het maakt het mogelijk om andere authenticatievoorzieningen middels een routeringsvoorziening te ontsluiten. Bovendien geeft het de mogelijkheid om meerdere attributen of andere type identifiers mee te geven.&#xD;
&#xD;
OIDC is een generieke standaard die meestal nog profielen (aanvullende afspraken) vereist voor toepassing in specifieke domeinen.&#xD;
&#xD;
 </Werking><Volledige_naam>OpenID Connect</Volledige_naam><Specificatiedocument>Final Specifications</Specificatiedocument><Hulpmiddelen>Er is een groot aantal configureerbare implementaties en libraries beschikbaar.</Hulpmiddelen><Toelichting_bij_opname>Er is geadviseerd zo snel mogelijk een breed gedragen Nederlands profiel te ontwikkelen voor OIDC. Dit Nederlands profiel zal dan moeten worden aangedragen voor plaatsing op de &#x2018;pas toe of leg uit&#x2019;-lijst.&#xD;
&#xD;
Op 9 december 2020 heeft Forum Standaardisatie besloten de aanmelding van Logius voor het Nederlandse profiel van de standaard OIDC (NL GOV Assurance Profile for OIDC) voor plaatsing op de &#x2018;pas toe of leg uit&#x2019;-lijst in procedure te nemen. Dit profiel spitst zich specifiek toe op de context van (semi-)overheidsorganisaties in Nederland. &#xD;
&#xD;
In gevallen waar een generieke standaard moet worden toegepast met een specifieker profiel, plaatst het Forum Standaardisatie het profiel op de 'pas toe of leg uit' lijst en de onderliggende generieke standaard op de lijst aanbevolen standaarden.</Toelichting_bij_opname><Datum_van_aanmelding>17-04-2019</Datum_van_aanmelding><Datum_van_besluit>23-03-2020</Datum_van_besluit></Standaard><Standaard><Naam>SMeF 2.0</Naam><Omschrijving>Elektronische facturen (binnenkort vervangen door NLCIUS!)</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>E-facturering, Financi&#xEB;le administratie</Trefwoorden><Beheerorganisatie>NEN</Beheerorganisatie><Uitstekend_beheer>Ja voor deze standaard</Uitstekend_beheer><Versie>2.0</Versie><Domein>Economie en werk</Domein><EuropeseStatusMsp/><Functioneel_toepassingsgebied>De verzending van elektronische facturen door organisaties die deelnemen aan het economisch verkeer in Nederland (waaronder overheden) en de ontvangst hiervan door overheden.</Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>Het Semantische factuurmodel is een standaard voor electronisch factureren. Het model geeft duidelijkheid aan overheden en bedrijven (gebruikers en ICT-aanbieders) over de elementen en gegevens die op facturen naar overheidsorganisaties gebruikt dienen te worden (specifiek voor de Nederlandse situatie).</Nut><Werking>De standaard beschrijft welke gegevenselementen er in een elektronische factuur opgenomen dienen en kunnen worden, wat de samenhang is tussen deze elementen en wat de betekenis is van deze elementen.&#xD;
&#xD;
NB. SMeF 2.0 zal op de 'Pas toe of leg uit' lijst vervangen worden door de standaard NLCIUS die beter aansluit op de Europese normen.</Werking><Volledige_naam>Semantisch Model e-Factuur</Volledige_naam><Specificatiedocument>Documentatie Semantisch Model eFactuur</Specificatiedocument><Hulpmiddelen>Bij de beheerorganisatie NEN en TNO zijn hulpmiddelen te vinden over hoe de standaard te implementeren, hoe de standaard werkt en hoe de standaard wordt beheerd. Voor meest recente ontwikkelingen lees meer op de vernieuwde website www.stpe.nl.</Hulpmiddelen><Conformiteitstest>https://stpe.semantic-treehouse.nl/#/Home </Conformiteitstest><Datum_van_aanmelding>21-04-2016</Datum_van_aanmelding><Datum_van_besluit>15-11-2016</Datum_van_besluit><Toelichting>SMeF heeft tot doel om op semantisch niveau te komen tot &#xE9;&#xE9;n model voor elektronische facturen. Hierdoor wordt het eenvoudiger om meerdere standaarden te ondersteunen omdat een dergelijk model overheid en bedrijfsleven duidelijkheid biedt over welke elementen er op een elektronische factuur opgenomen dienen te worden ongeacht de onderliggende techniek van uitwisseling. De onderliggende techniek is gespecificeerd in bijvoorbeeld de SETU en UBL standaard. Dit zijn twee veelgebruikte standaarden voor elektronisch factureren.Dankzij mappings kunnen gebruikers van deze standaarden op een eenvoudige uniforme wijze elektronisch naar de overheid factureren. Mappings naar andere standaarden zijn bovendien ook mogelijk. UBL wordt nu getoetst voor opname op de aanbevolen lijst met standaarden van Forum Standaardisatie.&#xD;
&#xD;
NB. SMeF 2.0 wordt binnenkort vervangen door NLCIUS. Bij nieuwe investeringen in e-facturatiesystemen wordt dan ook aangeraden om NLCIUS te gebruiken.</Toelichting><Waarvoor_geldt_de_verplichting>SMeF 2.0 wordt binnenkort vervangen door NLCIUS. Bij nieuwe investeringen in e-facturatiesystemen wordt aangeraden om NLCIUS te implementeren.</Waarvoor_geldt_de_verplichting><Aandachtspunten>Voor de volgende inkoopnummers en beschrijvingen is de standaard sowieso relevant&#xD;
&#xD;
 &#xD;
&#xD;
Financieel /administratieve systemen&#xD;
48400000-2 Software voor zakelijke transacties en persoonlijke zaken&#xD;
48440000-4 Software voor financi&#xEB;le analyse en boekhouding&#xD;
48444100-3 Factureringssysteem&#xD;
79999200-5 Factureringsdiensten</Aandachtspunten></Standaard><Standaard><Naam>STABU2</Naam><Omschrijving/><Lijst>Archief</Lijst><Trefwoorden>BIM, Bouw</Trefwoorden><Beheerorganisatie>Stichting STABU</Beheerorganisatie><Uitstekend_beheer>Nog niet getoetst</Uitstekend_beheer><Versie>1.0</Versie><Domein/><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>Om de technische en functionele eisen voor bouwwerken vast te leggen, wordt in de bouwsector een bestek gebruikt. Dit bestek vormt de basis voor het contract tussen opdrachtgever en aannemer en de prijsvorming bij aanbestedingen. STABU2 is de besteksystematiek voor Burger en Utiliteitsbouw. De standaard draagt bij aan de interoperabiliteit tussen de overheid en marktpartijen in de B&amp;U als het gaat om het opstellen van een bestek en het uiteindelijke contract tussen Rijksoverheid en marktpartij(en).&#xD;
&#xD;
STABU2 biedt faciliteiten voor:&#xD;
&#xD;
&#xD;
	Volledigheid: STABU2 biedt een vaste indeling en structuur en een eenduidige en relevante bestekadministratie;&#xD;
	Gelijkwaardige contractpartners: STABU2 beschrijft een eenduidige afbakening van verantwoordelijkheden.&#xD;
	Standaardisatie: STABU2 is gebaseerd op het aanbestedingsstelsel&#x2013; ARW 2005.&#xD;
	Interoperabiliteit: STABU2 zorgt ervoor dat het bestek geschikt is voor een automatische verwerking en bevordert uitwisseling van informatie met volgende fasen in het proces zoals calculatie en planning.&#xD;
	Juridische waarde: een bestek geschreven op basis van STABU2 bezit een zekere juridische waarde.&#xD;
	Kwaliteit en contracteren: Opdrachtnemers kunnen aantonen welke kwaliteit zij leveren en het in de keten gebruiken om onderaannemers te contracteren.</Nut><Werking>Bestekdocumenten bevatten onder meer de beschrijving van het werk, de daarbij behorende tekeningen en de voor het werk geldende voorwaarden. Sinds de jaren negentig worden bestekken ook automatisch verwerkt. Door afspraken te maken over de structuur van bestekdocumenten worden deze beter uitwisselbaar en vergelijkbaar. STABU2 beschrijft afspraken voor het opstellen van bestekdocumenten voor projecten in de burger- en utiliteitsbouw (B&amp;U). De standaard is het resultaat van een evolutie van bestekstandaarden door de jaren heen.</Werking><Specificatiedocument>Documentatie STABU2</Specificatiedocument><Toelichting_bij_opname>STABU2 is door de Stichting STABU aangemeld voor plaatsing op de lijst aanbevolen standaarden. Op dit moment is STABU2 in behandeling voor toetsing door het Forum Standaardisatie.</Toelichting_bij_opname><Datum_van_aanmelding>28-10-2018</Datum_van_aanmelding></Standaard><Standaard><Naam>Stosag</Naam><Omschrijving>Afvalinzameling- en verwerking</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Afvalinzameling, Milieu</Trefwoorden><Beheerorganisatie>STOSAG / NVRD</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>1.0</Versie><Domein/><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Stosag moet worden toegepast op digitaal container- en pasmanagement voor afval en grondstoffen.</Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>Bij afvalregistratie wordt vastgelegd welk soort afval, in welke hoeveelheden door een persoon of partij wordt aangeboden. Voor deze registratie worden verschillende digitale middelen gebruikt zoals passen, om containers te openen, chips op containers en afvalwagens, om onderling te communiceren en tenslotte de backoffice systemen, om de afvalgegevens te verwerken.
Deze digitale middelen zijn veelal zodanig op elkaar afgestemd dat ze moeten worden afgenomen bij dezelfde leverancier. Gemeentelijke afvalinzamelaars zijn echter gebaat bij een leveranciersonafhankelijke uitvoering waarmee een vendor lock-in wordt voorkomen, innovatie wordt bevorderd en (gemeentelijke) samenwerking makkelijker en goedkoper wordt gemaakt. De STOSAG standaard voorziet hierin.</Nut><Werking>De STOSAG standaard beschrijft het proces van informatieuitwisseling op een viertal koppelvlakken tussen chippas, bechipte containers, chiplezer en backoffice systemen, elk voor een afzonderlijk proces van informatie-uitwisseling. De processen zijn:
Communicatie tussen chipkaarten en (ondergrondse)verzamelcontainers met toegangsidentificatie;
Communicatie tussen bechipte minicontainers en identificatiesystemen op de inzamelwagen;
Communicatie tussen verzamelcontainers en back-office systemen;
Communicatie tussen de systemen op de inzamelwagen en back-office systemen.</Werking><Volledige_naam>Stuurgroep Open Standaarden Afval en Grondstoffen</Volledige_naam><Specificatiedocument>Specificatiedocument STOSAG</Specificatiedocument><Hulpmiddelen>Op de website van de beheerorganisatie STOSAG is meer informatie over de standaard te vinden: www.stosag.nl</Hulpmiddelen><Toelichting_bij_opname>Het Overheidsbreed Beleidsoverleg Digitale Overheid (OBDO) besloot op 29 november 2018 op advies van het Forum Standaardisatie om STOSAG 1.0 te verwijderen van de pas-toe-of-leg-uit lijst.  Voor details zie het Forumadvies STOSAG zoals overgenomen door het OBDO.</Toelichting_bij_opname><Datum_van_aanmelding>03-05-2011</Datum_van_aanmelding><Datum_van_besluit>15-11-2011</Datum_van_besluit><Waarvoor_geldt_de_verplichting>Bij investeren in ICT-systemen die gebruikt worden bij afvalinzameling en afvalverwerking.</Waarvoor_geldt_de_verplichting><Aandachtspunten>Meer informatie over hoe om te gaan met STOSAG in aanbestedingen kunt u vinden in dit document: http://www.stosag.nl/files/Toelichting%20STOSAG%20bij%20aanbestedingen.pdf</Aandachtspunten></Standaard><Standaard><Naam>Principe Universeel</Naam><Omschrijving>Bouwkwaliteit websites</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Internet, Website</Trefwoorden><Beheerorganisatie>Logius</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie/><Domein/><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Principe Universeel kan worden toegepast op het aanbieden van webgebaseerde informatie-, interactie-, transactie- en participatiediensten. </Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>Principe Universeel bevat richtlijnen voor de bouwkwaliteit van websites  waardoor deze duurzaam, uitwisselbaar en goed te onderhouden worden.&#xD;
&#xD;
 &#xD;
&#xD;
 </Nut><Werking>Principe Universeel bevat een verzameling regels die bij de bouw en het onderhoud van een website of webapplicatie toegepast dienen te worden om de duurzaamheid en bruikbaarheid van (de content op) de website te bevorderen.&#xD;
&#xD;
Principe Universeel wordt doorgaans gebruikt in aanvulling op de toegankelijkheidseisen van WCAG 2.1. Waar WCAG 2.1 de toegankelijkheid van de informatie dient (in het bijzonder ook voor mensen met functiebeperking), richt Principe Universeel zich vooral op bouwkwaliteit, in het bijzonder structuur, vindbaarheid, duurzaamheid en onderhoudbaarheid van de informatie.</Werking><Specificatiedocument>Niet meer beschikbaar&#xD;
&#xD;
 </Specificatiedocument><Datum_van_besluit>29-04-2021</Datum_van_besluit><Toelichting>Principe Universeel maakte voorheen deel uit van de standaard Webrichtlijnen 2. Naar aanleiding van Europese regelgeving verving het Forum Standaardisatie Webrichtlijnen 2 eind 2016 door EN 301 549 (in Nederland bekend als 'DigiToegankelijk') op de 'pas-toe-of-leg-uit- lijst.  EN 301 549 baseert zich, net als Webrichtlijnen 2, op de toegankelijkheidsstandaard WCAG 2.1 van het W3C.&#xD;
&#xD;
Het Forum Standaardisatie besloot na raadpleging van experts en publieke consultatie om Principe Universeel in 2018 op de lijst met 'aanbevolen' standaarden te plaatsen. Europese regelgeving vereist namelijk dat EN 301 549 zonder aanvullende specificaties door de lidstaten wordt overgenomen.&#xD;
&#xD;
In augustus 2020 gaf Logius aan het beheer van Principe Universeel definitief te hebben be&#xEB;indigd, en geen andere organisatie bereid te hebben gevonden om het beheer over te nemen. Op advies van Logius is Forum Standaardisatie toen overgegaan tot de procedure om Principe Universeel van de lijst te verwijderen. Op 29 april 2021 heeft het OBDO ingestemd met verwijdering van Principe Universeel van de lijst aanbevolen standaarden.</Toelichting></Standaard><Standaard><Naam>DHCP</Naam><Omschrijving>Toewijzing netwerkadressen</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Internet, Netwerk</Trefwoorden><Beheerorganisatie>IETF</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>35490</Versie><Domein>Veilig internet</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Netwerken, configureren van hosts</Functioneel_toepassingsgebied><Nut>DHCP maakt het mogelijk om automatisch netwerkadressen toe te wijzen aan hosts en maakt het bijvoorbeeld ook mogelijk om de netwerkadressen van DNS server mee te sturen.</Nut><Werking>Het DHCP protocol specificeert een framework dat het mogelijk maakt om configuratie-informatie door te sturen naar hosts op een TCP/IP netwerk.&#xA0;</Werking><Volledige_naam>Dynamic Host Configuration Protocol</Volledige_naam><Specificatiedocument>Specificatiedocument DHCP</Specificatiedocument><Datum_van_besluit>20-08-2009</Datum_van_besluit></Standaard><Standaard><Naam>MTOM</Naam><Omschrijving/><Lijst>Archief</Lijst><Trefwoorden>Informatiemanagement, Internet</Trefwoorden><Beheerorganisatie>W3C</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>MTOM januari 2005, (voor SOAP versie 1.2)</Versie><Domein>Veilig internet</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Het verzenden van grote hoeveelheden data (bijvoorbeeld attachments) in SOAP-berichten.</Functioneel_toepassingsgebied><Nut>Message Transmission Optimization Mechanism of kortweg MTOM is een methode om op effici&#xEB;nte wijze binaire data naar en van webservices te versturen.</Nut><Werking>MTOM wordt gebruikt voor het effici&#xEB;nt verzenden van grote hoeveelheden data (bijvoorbeeld attachments) in SOAP-berichten. MTOM wordt bijvoorbeeld gebruikt in Digikoppeling in combinatie met WUS, in de online registratie bij KvK, en het Aktenverkeer met Notarissen. Hiernaast wordt verwacht dat het uitwisselen van gegevens met overheidsorganisaties nog meer relevant wordt wanneer brondocumenten worden uitgewisseld tussen basisregistraties.</Werking><Volledige_naam>SOAP Message Transmission Optimization Mechanism</Volledige_naam><Specificatiedocument>Specificatiedocument MTOM</Specificatiedocument><Datum_van_besluit>04-10-2013</Datum_van_besluit><Toelichting>Met betrekking tot Digikoppeling wordt MTOM slechts gebruikt voor attachments in combinatie met WUS. Met betrekking tot SOAP maakt MTOM het mogelijk om effici&#xEB;nter de binary data van grote bestanden in een SOAP-request (aanvraag) of response (reactie) te plaatsen.</Toelichting></Standaard><Standaard><Naam>IPP</Naam><Omschrijving>printen via een netwerk</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Internet, Netwerk</Trefwoorden><Beheerorganisatie>IEEE-ISTO</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>1.1</Versie><Domein>Veilig internet</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Printen over een netwerk</Functioneel_toepassingsgebied><Nut>IPP zorgt ervoor dat een printserver kan communiceren met verschillende cli&#xEB;nten (apparaten) waardoor printen via een netwerk mogelijk wordt.</Nut><Werking>IPP zorgt voor de communicatie tussen cli&#xEB;nten en servers. Print opdrachten worden naar een server gestuurd en het protocol maakt het mogelijk om verschillende administratieve taken uit te voeren zoals wachttijd van de printopdracht of het annuleren van een printopdracht. De standaard is IP-gebaseerd en kan via een lokaalnetwerk of via het internet worden uitgevoerd. IPP ondersteunt tevens toegangsbeheer, verificatie en codering waardoor het mogelijk is om veilig te printen.</Werking><Volledige_naam>Internet Printing Protocol</Volledige_naam><Specificatiedocument>Specificatiedocument IPP RFC2910&#xD;
	Specificatiedocument IPP RFC2911&#xD;
	Specificatiedocument IPP RFC8010</Specificatiedocument><Datum_van_besluit>20-08-2009</Datum_van_besluit></Standaard><Standaard><Naam>EI-standaarden</Naam><Omschrijving>Declaratieverkeer zorgverzekeraars en zorgverleners</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Financi&#xEB;le administratie</Trefwoorden><Beheerorganisatie>Vektis</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>zie toelichting bij opname</Versie><Domein>Economie en werk</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Declaratieverkeer in de gezondheidszorg</Functioneel_toepassingsgebied><Nut>Externe Integratiestandaarden (EI) is een set declaratieberichten en bijbehorende retourberichten ten behoeve van het declaratieverkeer tussen zorgverzekeraars en zorgverleners in het kader van de zorgverzekeringswet. Het gaat om semantische standaarden.</Nut><Werking>Een EI-standaard bestaat uit een standaardbeschrijving en berichtspecificaties. Het gaat om semantische standaarden en voorbeelden van EI-berichten zijn: indicatiebesluitbericht, &#xA0;zorgtoewijzingbericht, &#xA0;melding aanvangzorgbericht en &#xA0;mutatie-/eindezorgbericht.&#xA0;</Werking><Volledige_naam>Externe-Integratiestandaarden</Volledige_naam><Specificatiedocument>Specificatiedocument EI-standaarden</Specificatiedocument><Toelichting_bij_opname>Oorspronkelijke zijn er 11 standaarden die vielen onder de ei-standaarden opgenomen. In de loop der jaren is deze set uitgebreid, november 2016 is de set standaarden op de aanbevolen lijst bijgewerkt. De Ei-standaarden zijn met name sterk uitgebreid als gevolg van de decentralisatie van Jeugd, Werk en Zorg naar de gemeenten (3 D&#x2019;s). Meer informatie hierover is te vinden bij VEKTIS. Hierna volgt een overzicht van de individuele standaarden:AP304/AP305 (V8.0)AW319/AW320 (V1.4)DG301/DG302 (V1.0)EF301/EF302 (V1.1)EP301/EP302 (V1.2)FZ301/FZ302 (V2.0)FZ303/FZ304 (V1.0)GZ311/GZ312 (V2.1)GZ321/GZ322 (V1.0)GZ340 (V1.0)HA304/HA305 (V4.2)JW303/JW304 (V2.1)JW321/JW322 (V2.0)KZ301/KZ302 (V3.2)LH307/LH308 (V5.2)MA801 (V4.3)MZ301/MZ302 (V1.3)OS301/OS302 (V1.0)PM304/PM305 (V3.2)QA301/QA302 (V2.0)QD301 (V1.0)QDG301/302 (V1.0)QE301 (V1.0)QF301/QF302 (V2.0)QG301/QG302 (V2.0)QG321/QG322 (V1.0)QH301 (V1.1)QK301/302 (V1.0)QM301 (V1.1)QP301 (v1.0)QV301/302 (V1.0)QX301/QX302 (V2.1)QZ301/QZ302 (V2.0)SB311/SB312 (V2.0)VE303/VE304 (V4.2)VK301/VK302 (V2.2)VZ301 (V1.0)VZ801/VZ802 (V1.0)WMO303/WMO304 (V2.1)ZH308/ZH309 (V9.0)ZH310/ZH311 (V1.0)De oorspronkelijke 11 standaarden waren (AP304/AP305 (v.7.0), EP301/EP302 (v.1.2), GZ311/GZ312 (v.1.1), HA304/HA305 (v.4.2), KZ301/KZ302 (v.3.2), LH307/LH308 (v.5.2), MZ301/MZ302 (v.1.3), PM304/PM305 (v.3.2), VE303/VE304 (v.4.2), VK301/VK302 (v2.2), ZH308/ZH309 (v7.2), VZ37/VZ38 (v.4))</Toelichting_bij_opname><Datum_van_besluit>15-11-2016</Datum_van_besluit></Standaard><Standaard><Naam>Digikoppeling 1.0</Naam><Omschrijving>veilige berichtuitwisseling</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Basisregistraties, Informatiebeveiliging, Netwerk, Zaakgegevens</Trefwoorden><Beheerorganisatie>Logius</Beheerorganisatie><Uitstekend_beheer/><Versie>1.0</Versie><Domein>Uitwisselingsfundament</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Geautomatiseerde gegevensuitwisseling tussen informatiesystemen voor sectoroverstijgend berichtenverkeer, op basis van twee koppelvlakstandaarden:&#xD;
&#xD;
&#xD;
	DK ebMS standaard voor meldingen tussen informatiesystemen&#xD;
	DK WUS standaard voor de bevraging van informatiesystemen&#xD;
&#xD;
&#xD;
 </Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>Zoals een brief in een envelop gaat voor verzending, zo gaat een elektronisch bericht in een digitale verpakking. Digikoppeling bestaat uit koppelvlakstandaarden, die logistieke afspraken bevatten voor berichtenuitwisseling tussen overheden.</Nut><Werking>Digikoppeling bestaat uit een set standaarden voor elektronisch berichtenverkeer tussen overheidsorganisaties. &#xD;
&#xD;
Digikoppeling onderkent twee hoofdvormen van berichtenverkeer: &#xD;
&#xD;
&#xD;
	Bevragingen; een vraag waar direct een reactie op wordt verwacht. Hierbij is snelheid van afleveren belangrijk. Als een service niet beschikbaar is, dan hoeft de vraag niet opnieuw worden aangeboden.&#xD;
	Meldingen; men levert een bericht en pas (veel) later komt eventueel een reactie terug. In dat geval is snelheid van afleveren minder belangrijk. Als een partij even niet beschikbaar is om het bericht aan te nemen, dan is het juist wel gewenst dat het bericht nogmaals wordt aangeboden. &#xD;
&#xD;
&#xD;
Aan versie 2.0 van Digikoppeling is o.a. de specificatie voor grote berichten toegevoegd, de mogelijkheid om attachments toe te voegen en om security op berichtniveau toe te passen.</Werking><Volledige_naam>ebMS WUS zoals nader gespecificeerd binnen Digikoppeling (voorheen OSB)</Volledige_naam><Specificatiedocument>Specificatiedocument Digikoppeling 1.0</Specificatiedocument><Toelichting_bij_opname>Deze versie is vervangen door versies 2.0 en 3.0&#xA0;</Toelichting_bij_opname><Datum_van_besluit>20-05-2009</Datum_van_besluit><Toelichting>Deze versie is inmiddels vervangen door versie 2.0 van de standaard</Toelichting></Standaard><Standaard><Naam>HTTP</Naam><Omschrijving>webcommunicatie</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Website</Trefwoorden><Beheerorganisatie>IETF</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>1.1 en 2.0</Versie><Domein>Veilig internet</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Uitwisseling van gegevens via het web</Functioneel_toepassingsgebied><Nut>In HTTP is vastgelegd welke vragen een cli&#xEB;nt aan een server kan stellen en welke antwoorden de server kan teruggeven. Een vraag wordt gesteld in de vorm van een URL. Dit maakt communicatie tussen een webclient zoals een webbrowser en een webserver mogelijk.</Nut><Werking>Hypertext Transfer Protocol (HTTP) is h&#xE9;t protocol voor communicatie tussen een webclient (zoals een browser) en een webserver. HTTP ondersteunt gegevensuitwisseling over datacommunicatienetwerken gebruikmakend van TCP. Het is een protocol voor gedistribueerde, samenwerkende, hypermedia informatiesystemen. De standaard kan worden gebruikt voor vele doeleinden naast het uitwisselen van hypertext.</Werking><Volledige_naam>Hypertext Transfer Protocol</Volledige_naam><Specificatiedocument>RFC2616, obsolete. Deze versie is vervangen door:RFC7230 - HTTP/1.1: Message Syntax and Routing - low-level message parsing and connection managementRFC7231 - HTTP/1.1: Semantics and Content - methods, status codes and headersRFC7232 - HTTP/1.1: Conditional Requests - e.g., If-Modified-SinceRFC7233 - HTTP/1.1: Range Requests - getting partial contentRFC7234 - HTTP/1.1: Caching - browser and intermediary cachesRFC7235 - HTTP/1.1: Authentication - a framework for HTTP authentication</Specificatiedocument><Toelichting_bij_opname>November 2016 is besloten om naast de 1.1 versie ook de 2.0 versie toe te voegen. De HTTP/1.1 versie is nog zeer gangbaar en eenvoudiger, maar versie HTTP/2 biedt voor gevallen waar de snelheid van het laden en gebruiken van (interactieve) webpagina&#x2019;s van belang is, ten behoeve van de gebruikerservaring, meer en betere functionaliteit. HTTP/2 is backwards compatibel aan versie 1.1. en worden ondersteund door de meeste webbrowsers.</Toelichting_bij_opname><Datum_van_besluit>15-11-2016</Datum_van_besluit><Toelichting>TLS: de standaard ondersteunt tevens gegevensuitwisseling over TLS (voor HTTPS URI&#x2019;s), gangbare webbrowsers ondersteunen zelfs HTTP/2 alleen in combinatie met TLS.TCP: de standaard maakt gebruik van TCP als onderliggend transportprotocol.</Toelichting></Standaard><Standaard><Naam>SLD</Naam><Omschrijving>geografische informatie</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Geo-informatie</Trefwoorden><Beheerorganisatie>Open Geospatial Consort</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>1.1.0</Versie><Domein/><EuropeseStatusMsp/><Functioneel_toepassingsgebied>Voor de visualisatie van geografische informatie</Functioneel_toepassingsgebied><Nut>De SLD standaard is een standaard voor visualisatie van geografische gegevens binnen het WMS protocol.&#xA0;</Nut><Werking>SLD definieert een encoding die de WMS standaard uitbreidt waardoor het mogelijk is om door de gebruiker gedefinieerde symbolen en kleuren te gebruiken in geografische gegevens.</Werking><Volledige_naam>Styles Layer Descriptor</Volledige_naam><Specificatiedocument>Specificatiedocument SLD</Specificatiedocument><Hulpmiddelen>https://www.geonovum.nl/geo-standaarden/services
https://www.geonovum.nl/geo-standaarden/geo-op-het-web</Hulpmiddelen><Toelichting_bij_opname>November 2016 is besloten om SLD van de aanbevolen lijst te verwijderen omdat SLD is een optionele standaard die alleen werkt tezamen met WMS en WFS en het werkt niet voor andere geo-standaarden. Het is daarmee een te kleine en specifieke standaard. Verder is de huidige versie deprecated (op dit moment is er versie 1.1.0). Ook dekt SLD niet alle visualisatie, de standaard SE hoort hier ook bij. Net zoals de standaarden WMS en WFS staat SE niet op de lijst. Alleen SLD op de lijst hebben staan is niet consistent en geeft verwarring.</Toelichting_bij_opname><Datum_van_besluit>20-08-2009</Datum_van_besluit><Toelichting>Een Web Map Services (WMS) is een protocol voor het, via de standaard webbrowser, aanroepen van geo-kaarten gegenereerd uit een GIS databank.</Toelichting></Standaard><Standaard><Naam>Secure Software Development</Naam><Omschrijving>Ontwikkeling van veilige software&#xA0;&#xA0;</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Informatiebeveiliging, Informatiemanagement</Trefwoorden><Beheerorganisatie>CIP</Beheerorganisatie><Uitstekend_beheer/><Versie>2.0</Versie><Domein/><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Nut>Secure Software Development (SSD) beschrijft een basisset maatregelen die moeten worden genomen om de inbouw van kwetsbaarheden bij de bouw van software te voorkomen. Met SSD krijgt een opdrachtgever grip op het ontwikkelen van veilige software. Toepassing van SSD zorgt dat de ontwikkelde software een standaard niveau van veiligheid heeft, en bijvoorbeeld het risico van gegevenslekken minimaliseert.</Nut><Werking>SSD beschrijft wat de partijen in de keten opdrachtgever- softwareontwikkelaar- hosting moeten doen en hoe de veiligheid van software kan worden getest of geaudit. De drie pijlers daarbij zijn standaard beveiligingseisen, contactmomenten en het inrichten van SSD processen. De normen zijn zo op gesteld dat zij het gesprek tussen de opdrachtgever en de opdrachtnemer ondersteunen.</Werking><Volledige_naam>Grip op Secure Software Development</Volledige_naam><Specificatiedocument>Grip op Secure Software Development</Specificatiedocument><Datum_van_aanmelding>20-11-2017</Datum_van_aanmelding><Toelichting>Secure Software Development 2.0 richt zich op het proces van softwareontwikkeling binnen een organisatie. Hierdoor valt SSD buiten de scope van de criteria voor toetsing ter opname op de 'Pas toe of leg uit' lijst (zie het intakeadvies). De meerwaarde van SSD voor de bouw van veilige software en met name voor software die de bescherming van persoonsgegevens waarborgt, wordt echter terdege onderkend.</Toelichting></Standaard><Standaard><Naam>SMeF v1.3</Naam><Omschrijving>e-Facturatie</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>E-facturering, Financi&#xEB;le administratie</Trefwoorden><Beheerorganisatie>NEN</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>1.3</Versie><Domein>Economie en werk</Domein><EuropeseStatusMsp/><Functioneel_toepassingsgebied>De verzending van elektronische facturen door organisaties die deelnemen aan het economisch verkeer in Nederland (waaronder overheden) en de ontvangst hiervan door overheden.</Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>Versie 1.3 is vervangen door versie 2.0. Het Semantische factuurmodel is een standaard voor elektronisch factureren. Het model geeft duidelijkheid aan overheden en bedrijven (gebruikers en ICT-aanbieders) over de elementen en gegevens die op facturen naar overheidsorganisaties gebruikt dienen te worden (specifiek voor de Nederlandse situatie).&#xD;
&#xD;
 </Nut><Werking>De standaard beschrijft welke gegevenselementen er in een elektronische factuur opgenomen dienen en kunnen worden, wat de samenhang is tussen deze elementen en wat de betekenis is van deze elementen. Daarnaast bevat de standaard mappings van de gegevenselementen naar SETU (staat op de 'Pas toe of leg uit' &#x2013;lijst) en de internationale UBL standaard zoals UBL SI (Simpler Invoicing) en UBL OHNL. Dit zijn twee veelgebruikte standaarden voor elektronisch factureren. Dankzij de mappings kunnen gebruikers van deze standaarden op een eenvoudige uniforme wijze elektronisch naar de overheid factureren. Mappings naar andere standaarden zijn bovendien ook mogelijk.</Werking><Volledige_naam>Semantisch Model e-Facturatie</Volledige_naam><Specificatiedocument>Documentatie Semantisch Model eFacturatie</Specificatiedocument><Hulpmiddelen>Op het standaardisatieplatform e-factureren waaraan de beheerorganisatie NEN en TNO bijdrage levert, vindt u meer informatie voor implementatie.</Hulpmiddelen><Conformiteitstest>https://stpe.semantic-treehouse.nl/#/Home </Conformiteitstest><Toelichting_bij_opname>Forum Standaardisatie heeft in 2010 de aanbeveling gedaan om te komen tot een nationale semantische standaard voor elektronisch factureren. Het semantisch model e-factureren geeft invulling aan deze aanbeveling.&#xD;
&#xD;
 &#xD;
&#xD;
In het Forumadvies van oktober 2012 worden een aantal criteria genoemd waar op dat moment nog niet (volledig) aan werd voldaan. College standaardisatie besloot in november 2012 dat deze standaard kon worden opgenomen, mits deze laatste punten naar tevredenheid zijn ingevuld. In mei 2013 heeft de beheerder gerapporteerd over de laatste openstaande punten en heeft het Forum geconstateerd dat in voldoende mate is voldaan aan de laatste openstaande voorwaarden. In juni is daarom de standaard op de 'Pas toe of leg uit' -lijst opgenomen. &#xD;
&#xD;
 &#xD;
&#xD;
Nationaal en internationaal zijn verschillende e-factuurstandaarden in ontwikkeling en in gebruik. Om de waarde van het semantische factuurmodel voor elektronisch factureren verder te vergroten is het noodzakelijk deze ontwikkelingen actief te volgen en hier vanuit het semantische model aansluiting bij te zoeken. Om deze ontwikkelingen inzichtelijk te maken heeft het Forum een samenhang en adoptie onderzoek laten uitvoeren naar de verschillende e-facturatie standaarden. Zie hiervoor ook de themapagina over e-facturatie.&#xD;
&#xD;
 &#xD;
&#xD;
Februari 2015 heeft het Forum besloten om versie 1.2.7. op de lijst aan te passen naar versie 1.3, dit vanwege de beperkte wijzigingen tussen beide versies.&#xD;
&#xD;
 &#xD;
&#xD;
Op dit moment loopt er een toets naar de 2.0 versie van de standaard. Tegelijkertijd wordt gekeken of de standaard in aanmerking komt voor uitstekend beheer.</Toelichting_bij_opname><Datum_van_aanmelding>11-06-2011</Datum_van_aanmelding><Datum_van_besluit>17-06-2013</Datum_van_besluit><Toelichting>SMeF heeft tot doel om op semantisch niveau te komen tot &#xE9;&#xE9;n model voor elektronische facturen. Hierdoor wordt het eenvoudiger om meerdere standaarden te ondersteunen omdat een dergelijk model overheid en bedrijfsleven duidelijkheid biedt over welke elementen er op een elektronische factuur opgenomen dienen te worden ongeacht de onderliggende techniek van uitwisseling. De onderliggende techniek is gespecificeerd in bijvoorbeeld de SETU en UBL standaard. Dit zijn twee veelgebruikte standaarden voor elektronisch factureren. Dankzij mappings kunnen gebruikers van deze standaarden op een eenvoudige uniforme wijze elektronisch naar de overheid factureren. Mappings naar andere standaarden zijn bovendien ook mogelijk.&#xD;
&#xD;
UBL staat niet op de lijst met standaarden van Forum Standaardisatie.</Toelichting><Waarvoor_geldt_de_verplichting>Bij het investeren in ICT-systemen voor elektronisch betalingsverkeer dienen de uitwisselingsberichten (denk aan UBL of HR-XML) te voldoen aan SMEF.</Waarvoor_geldt_de_verplichting><Sjabloon-bestektekst>Voor de volgende inkoopnummers en beschrijvingen is de standaard sowieso relevant&#xD;
&#xD;
 &#xD;
&#xD;
Financieel /administratieve systemen&#xD;
48400000-2 Software voor zakelijke transacties en persoonlijke zaken&#xD;
48440000-4 Software voor financi&#xEB;le analyse en boekhouding&#xD;
48444100-3 Factureringssysteem&#xD;
79999200-5 Factureringsdiensten</Sjabloon-bestektekst><Advies_aan_beheerder>Bij de toetsingsprocedure zijn de volgende adviezen meegegeven&#xD;
&#xD;
&#xD;
	Stel een roadmap op waarin concreet wordt weergegeven hoe vanuit het beheer van het Semantische model aansluiting wordt gezocht bij de ontwikkeling van Europese standaardisatie-initiatieven. Hoe de beheerder de implementatie van het semantische model ondersteund bij die delen van de overheid, waar het model nog niet wordt gebruikt. De beheerder wordt gevraagd bij het opstellen van de roadmap zoveel mogelijk belanghebbenden te betrekken en het resultaat na opname van het semantische factuurmodel, aan het Forum te rapporteren.&#xD;
	Biedt de documentatie van het Semantisch Model Elektronische Factuur aan onder een Creative Commons licentie.   Status: Deze licentie wordt weergegeven op de website en deze is ook in de documentatie zelf opgenomen.&#xD;
	Neem in het beheermodel de criteria op die de stuurgroep hanteert wanneer zij nieuwe leden benoemt.&#xD;
	Vermeld in het beheermodel dat de mogelijkheid om wijzigingsverzoeken in te dienen voor iedere belanghebbende open staat.&#xD;
	Breng een scheiding aan tussen het semantisch factuurmodel en de mappings naar de factuurstandaarden en geef duidelijk weer hoe het (versie)beheer van deze onderdelen zich tot elkaar verhoudt. Status:  het model en de bijbehorende zijn mappings gescheiden. In de documentatie zal nog wel beter moeten worden weergegeven hoe verschillende versies van documentatie/specificaties en mappings aan elkaar relateren.</Advies_aan_beheerder></Standaard><Standaard><Naam>IPM</Naam><Omschrijving>Publiceren van vergunningen</Omschrijving><Lijst>Archief</Lijst><Trefwoorden/><Beheerorganisatie/><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>4.0</Versie><Domein/><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Voor het centraal publiceren van vergunningen via overheid.nl</Functioneel_toepassingsgebied><Nut>Met het IPM publiceert u uw vergunningen op uw eigen website. Hierdoor worden alle verleende vergunningen via internet doorzoekbaar via &#xE9;&#xE9;n centrale zoekmachine op http://www.overheid.nl/</Nut><Werking>Het Informatie Publicatie Model &#x2018;xyz&#x2019; (IPM) beschrijft de randvoorwaarden voor het publiceren van informatie over &#x2018;xyz&#x2019; op internet en bevordert daarmee de vindbaarheid van dienst of product &#x2018;xyz&#x2019;. Voorbeelden zijn Samenwerkende Catalogi en Vergunningen (beheer is in handen van KOOP). Het IPM beschrijft de metadata standaard waarmee gegevens worden uitgewisseld, beschrijft de mogelijkheden die de centrale zoekdienst de deelnemende overheden biedt en geeft een toelichting op de aansluitvormen.</Werking><Volledige_naam>Informatie Publicatie Model Vergunningen</Volledige_naam><Specificatiedocument>Specificatiedocument IPM</Specificatiedocument><Toelichting_bij_opname>November 2016 is besloten om de standaard van de aanbevolen lijst te verwijderen. IPM is namelijk een onderdeel van een Contentmodel en beschrijft het component 'Structuurmodel'. Het is daarmee te weinig een generieke standaard. Verder wordt IPM als zodanig niet als open standaard beheerd (dit betreft niet de afzonderlijk contentmodellen). De standaard voldoet daardoor niet (meer) aan de criteria voor opname op de lijst aanbevolen standaarden.</Toelichting_bij_opname><Datum_van_besluit>20-08-2009</Datum_van_besluit><Toelichting>OWMS (Overheid.nl Web Metadata Standaard): standaard voor het beschrijven van metadata van informatie van de Nederlandse Overheid op internet. In IPM zijn een aantal metadatavelden gegroepeerd in een toepassingsprofiel.</Toelichting></Standaard><Standaard><Naam>POP3</Naam><Omschrijving>e-mail ophalen</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>E-mail, Netwerk</Trefwoorden><Beheerorganisatie>IETF</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>3</Versie><Domein>Veilig internet</Domein><EuropeseStatusMsp/><Functioneel_toepassingsgebied>E-mail ophalen</Functioneel_toepassingsgebied><Nut>POP3 is een internetstandaard voor het ophalen van e-mail van een server naar een cli&#xEB;nt over een TCP/IP-verbinding.</Nut><Werking>POP3 servers houden inkomende e&#x2011;mailberichten vast totdat de mail wordt opgehaald,  op dat moment worden ze naar de computer overgebracht. Wanneer de e&#x2011;mail is opgehaald, worden berichten meestal van de server verwijderd.</Werking><Volledige_naam>Post Office Protocol</Volledige_naam><Specificatiedocument>Specificatiedocument POP3</Specificatiedocument><Toelichting_bij_opname>November 2016 is besloten om de standaard van de aanbevolen lijst af te halen. POP3 is weliswaar een veelgebruikte standaard, maar kent een beter alternatief in standaard IMAP. Functioneel verschilt IMAP van POP3 er in dat IMAP de e-mailberichten op de server laat staan. De e-mailberichten blijven met IMAP beschikbaar voor meerdere clients (devices). POP3 haalt het e-mailbericht over naar de client en verwijdert het bericht op de e-mailserver. Daarmee is het e-mail bericht niet meer beschikbaar voor andere devices. Met de hoge penetratiegraad van smartphones en tablets, naast laptops en PC&#x2019;s, beschikken mensen vaak over meerdere verschillende devices die ook naast elkaar worden gebruikt voor activiteiten als e-mail en surfen. POP3 ondersteunt dit karakteristieke gebruik van meerdere verschillende devices voor dezelfde e-mailbox niet en neemt af in belang.</Toelichting_bij_opname><Datum_van_besluit>20-05-2009</Datum_van_besluit><Toelichting>Via TLS kan de POP3-verbinding worden versleuteld (RFC2595). Bij POP3 worden de berichten opgehaald en naar de computer gedownload, met IMAP e-mailberichten is het ook mogelijk om met berichten te werken zonder dat deze naar de computer zijn gedownload. Hierdoor is het mogelijk om berichten te verwijderen, bekijken en organiseren op de e-mailserver. IMAP wordt meer gebruikt voor de zakelijk e-mailaccounts. SMTP-servers verwerken de verzending van een e&#x2011;mailberichten naar internet. De SMTP-server verwerkt uitgaande e&#x2011;mail en wordt gebruikt in combinatie met een POP3 of IMAP inkomende e&#x2011;mailserver.</Toelichting></Standaard><Standaard><Naam>URL</Naam><Omschrijving>Standaard voor de identificatie van bronnen van&#xA0;informatie op het Internet</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Internet, Netwerk, Website</Trefwoorden><Beheerorganisatie>IETF</Beheerorganisatie><Uitstekend_beheer/><Versie>RFC 2718</Versie><Domein>Veilig internet</Domein><EuropeseStatusMsp/><Functioneel_toepassingsgebied>Netwerken: lokaliseren van informatie</Functioneel_toepassingsgebied><Nut>Een URL is een URI die speciaal bedoeld is om bronnen van informatie op het Internet eenduidig te identificeren.</Nut><Werking>Een Uniform Resource Locator (URL) (als het begint met 'http://' vaak ook wel webadres genoemd), is een URI met een bepaalde syntax en semantiek die een bron van informatie op het Internet identificeert.  Een URL bestaat uit de volgende onderdelen: protocol, authenticatiegegevens, domeinnaam, poortnummer, padnaam, een "querystring" en een "fragementidentifier". &#xD;
&#xD;
Een URL biedt een unieke identificatie van informatie op het Internet, maar deze is onafhankelijk van het netwerkadres van de machine waar de informatie opgeslagen is. Het domain name system (DNS) van het Internet geeft op basis van een URL het netwerk adres (IP adres) van de machine waar de informatiebron opgeslagen is.  Het voordeel hiervan is, dat informatie op het Internet eenduidig kan worden benoemd op een gebruikersvriendelijke manier, zonder het specificeren van fysieke netwerkadressen. &#xD;
&#xD;
Informatie kan daarmee worden verplaatst op het Internet en blijft beschikbaar met dezelfde URL.</Werking><Volledige_naam>Uniform Resource Locator</Volledige_naam><Specificatiedocument>Specificatiedocument URL</Specificatiedocument><Toelichting_bij_opname>November 2016 is besloten om de URL te verwijderen van de aanbevolen lijst omdat deze is opgenomen in de URI-standaard (alle URL&#x2019;s zijn een specifieke vorm van URI&#x2019;s) en de URI standaard RFC2717 met status &#x2018;Best current practice&#x2019; is vervallen en vervangen door standaard RFC4395 (status &#x2018;Best current practice&#x2019;) met richtlijnen en registratie procedures voor URI&#x2019;s.</Toelichting_bij_opname><Datum_van_besluit>20-08-2009</Datum_van_besluit></Standaard><Standaard><Naam>URN</Naam><Omschrijving>Netwerkprotocol voor identificatie van informatie</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Internet, Netwerk</Trefwoorden><Beheerorganisatie>IETF</Beheerorganisatie><Uitstekend_beheer/><Versie>RFC 2141</Versie><Domein/><EuropeseStatusMsp/><Functioneel_toepassingsgebied>Netwerk: voor het identificeren van informatie (bronnen)</Functioneel_toepassingsgebied><Nut>Een URN is een URI die slechts gebruikt wordt als een (unieke) naam, maar niets zegt over waar en hoe deze bron gevonden kan worden. Dit zorgt ervoor dat links persistent blijven</Nut><Werking>URN's verwijzen niet naar de fysieke plaats van een bestand op een server. Een URN verwijst naar een tabel ('name space') waarin de instelling op een generieke wijze bijhoudt welke bestanden zij beheert. Als een bestand wordt verplaatst, hoeft alleen de tabel aangepast te worden. Alle externe verwijzingen naar het bestand kunnen dan ongewijzigd blijven. Op deze wijze blijven links 'persistent'. Het gebruik van URN's vergt wel afspraken over dergelijke tabellen om beide eigenschappen te combineren: zowel persistente identificatie als permanente adressering. Diensten die deze eigenschappen kunnen combineren worden 'resolvers' of 'resolution services' genoemd. (bron: www.den.nl)</Werking><Volledige_naam>Uniform Resource Names</Volledige_naam><Specificatiedocument>Specificatiedocument URN</Specificatiedocument><Toelichting_bij_opname>November 2016 is besloten om de URN als losse standaard te verwijderd van de lijst omdat deze al onderdeel is van de URI-standaard. Net zoals URL, zijn alle URN&#x2019;s een specifieke vorm van URI&#x2019;s. Wel is de URN (IETF-standaard RFC2141) niet komen te vervallen zoals bij URL. Maar aangezien de URN een onderdeel is in de URI standaard is het niet nodig om deze standaard als aparte standaarden op de lijst te laten staan.</Toelichting_bij_opname><Datum_van_besluit>20-08-2009</Datum_van_besluit></Standaard><Standaard><Naam>UDDI</Naam><Omschrijving>Register voor webservices</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Internet</Trefwoorden><Beheerorganisatie>OASIS</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>3.0.2</Versie><Domein>Veilig internet</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Register van web services</Functioneel_toepassingsgebied><Nut>Als je als mens informatie zoekt op het internet, dan gebruik je meestal eerst een zoekmachine om die informatie te vinden.  UDDI ondersteunt een soortgelijk zoekmechanisme voor webservices: online applicaties die via het Internet kunnen worden aangeroepen.&#xD;
&#xD;
UDDI biedt een wereldwijd, op XML gebaseerd register waarmee organisaties zichzelf en de online diensten (webservices) die ze leveren, via het Internet kunnen presenteren. Het doel is het stroomlijnen van online transacties door het voor bedrijven mogelijk te maken elkaar te vinden, en om hun systemen te kunnen laten samenwerken. UDDI ondersteunt alleen de publicatie- en zoekfunctie, niet de protocollen voor het gebruik van de webservices zelf.</Nut><Werking>UDDI is een open standaard die het mogelijk maakt voor bedrijven om webservices (applicaties die via het web toegankelijk zijn) te publiceren en in te zien. UDDI beschrijft webservices in een op XML gebaseerd, machine leesbaar formaat.  Daardoor kan een klant applicatie inzien hoe de webservice moet worden aangeroepen, en wat de structuur is van de data die wordt teruggeleverd.</Werking><Volledige_naam>Universal Description Discovery Integration</Volledige_naam><Specificatiedocument>Specificatiedocument UDDI</Specificatiedocument><Community>Er is een online community voor UDDI.</Community><Datum_van_besluit>20-05-2009</Datum_van_besluit></Standaard><Standaard><Naam>DCAT-AP-DONL</Naam><Omschrijving>Profiel die de Nederlandse overheid gebruikt voor uitwisseling van metadata over datasets tussen datacatalogi.</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Metadata</Trefwoorden><Beheerorganisatie>KOOP</Beheerorganisatie><Uitstekend_beheer/><Versie>1.1</Versie><Domein>Openbaar en toegankelijk</Domein><EuropeseStatusMsp/><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>Veel organisaties brengen hun beschikbare databronnen in kaart in zogenaamde data catalogi. Veel Nederlandse overheden hebben ook zo&#x2019;n data catalogus beschikbaar die zowel intern als deels publiek beschikbaar is om te doorzoeken. Om te voorkomen dat gebruikers alle individuele catalogi moeten bezoeken, wordt metadata van verschillende regionale, nationale en thema catalogi verzameld. Om de uitwisseling van de metadata tussen catalogi te standaardiseren is de DCAT standaard ontwikkeld. De interoperabiliteit tussen catalogi maakt eenmalige invoer en meervoudig gebruik mogelijk.</Nut><Werking>Het toepassingsprofiel bestaat uit een beschrijving van het datamodel, de waardenlijsten die worden gebruikt voor de invulling van het model en de wijze van uitwisselen van informatie over datasets.&#xD;
&#xD;
Begin 2015 is een nieuwe versie van het dataportaal van de overheid live gegaan, gebaseerd op een nieuwe versie van het open source platform voor open data CKAN. Het nieuwe portaal is gebouwd volgens DCAT-AP-DONL. Hierbij is volledige compatibiliteit met de Europese DCAT-AP standaard bereikt voor Nederlandse datasets. Er is ook een vertaling gemaakt naar ISO 19115, de metadata standaard voor geo-datasets die door het Nationaal GeoRegister (NGR) gebruikt wordt.</Werking><Volledige_naam>DCAT Application Profile for data.overheid.nl</Volledige_naam><Specificatiedocument>DCAT-AP-DONL-1.1</Specificatiedocument><Datum_van_aanmelding>13-11-2020</Datum_van_aanmelding><Toelichting_bij_opname>De Nederlandse overheid heeft op basis van het Europese toepassingsprofiel DCAT-AP 1.1 (ook wel aangeduid als DCAT-AP-EU 1.1) een Nederlands toepassingsprofiel uitgewerkt: DCAT-AP-DONL 1.1. Het toepassingsprofiel voor datasets is de specificatie van de metadata die de Nederlandse overheid gebruikt voor de uitwisseling van metadata over datasets tussen datacatalogi. Het centrale dataregister van de overheid, data.overheid.nl, is opgezet op basis van DCAT-AP-DONL.</Toelichting_bij_opname></Standaard><Standaard><Naam>NL GOV Assurance Profile for OIDC</Naam><Omschrijving>Het profiel vult de standaard OpenID Connect aan met additionele eisen en richtlijnen.</Omschrijving><Lijst>Archief</Lijst><Trefwoorden>Informatiebeveiliging</Trefwoorden><Beheerorganisatie>Logius</Beheerorganisatie><Uitstekend_beheer>Nee</Uitstekend_beheer><Versie>1.0</Versie><Domein>Veilig internet</Domein><EuropeseStatusMsp>Nee</EuropeseStatusMsp><Functioneel_toepassingsgebied>Het NL GOV OpenID Connect profiel moet worden toegepast bij het beschikbaar stellen en het gebruik van federatieve authenticatiediensten, inclusief vertegenwoordiging- en attribuutverstrekking.</Functioneel_toepassingsgebied><Organisatorisch_werkingsgebied>Nederlandse overheden (Rijk, provincies, gemeenten en waterschappen) en instellingen uit de (semi-) publieke sector.</Organisatorisch_werkingsgebied><Nut>Het NL GOV Assurance profile for OIDC 1.0 geeft door dienstverleners aangeboden diensten de mogelijkheid om de identiteit van een eindgebruiker te controleren gebaseerd op verschillende authenticatieservices (zoals DigiD), waarbij profielinformatie van de eindgebruiker volgens een gestandaardiseerde wijze beschikbaar wordt gesteld aan de daarvoor geautoriseerde diensten.</Nut><Werking>Het profiel maakt het mogelijk dat gebruikers zelf een keuze kunnen maken voor een (goedgekeurde) authenticatievoorziening, zoals DigiD, en niet steeds opnieuw in hoeven te loggen, bijvoorbeeld wanneer er gebruik wordt gemaakt van een routeringsvoorziening.&#xD;
&#xD;
OpenID Connect is een generieke standaard die meestal nog aanvullende afspraken vereist voor de toepassing in specifieke domeinen. NL GOV Assurance Profile for OIDC legt nadere afspraken vast over het gebruik van OpenID Connect bij de Nederlandse (semi-)overheid.</Werking><Volledige_naam>NL GOV Assurance profile for OpenID Connect</Volledige_naam><Specificatiedocument>NL GOV Assurance profile for OpenID Connect 1.0</Specificatiedocument><Datum_van_aanmelding>20-11-2020</Datum_van_aanmelding><Consultatie>Reacties uit openbare consultatie</Consultatie></Standaard><Standaard><Naam>SBOM</Naam><Omschrijving>Inzicht in samenstelling van softwareproducten</Omschrijving><Lijst>Archief</Lijst><Trefwoorden/><Beheerorganisatie>CycloneDX: OWASPSPDX: The Linux Foundation</Beheerorganisatie><Uitstekend_beheer/><Versie>CycloneDX: 1.5SPDX: 3.0</Versie><Domein/><EuropeseStatusMsp/><Status>Gearchiveerd</Status><Nut>Als SBOM-standaarden bieden CycloneDX en SPDX inzicht in de samenstelling van een softwareproduct, wat bijdraagt aan transparantie, hergebruik, veiligheid en beheer van deze producten. Het stelt organisaties in staat om naleving van licenties en regelgeving beter te waarborgen, mogelijk hergebruik van componenten te beoordelen, afhankelijkheden in kaart te brengen en sneller te reageren op veiligheidsincidenten rond componenten. </Nut><Werking>Beide standaarden specificeren de manier waarop softwarecomponenten, licenties, versies en relaties in een softwareproduct vastgelegd kunnen worden. Hierdoor is integratie en uitwisseling tussen verschillende systemen eenvoudiger en wordt het beheer van het softwarelandschap verbeterd.</Werking><Volledige_naam>CycloneDXSystem Package Data Exchange</Volledige_naam><Specificatiedocument>De specificaties van CycloneDX zijn vrij beschikbaar via de CycloneDX Specification Overview.De specificaties van SPDX zijn vrij beschikbaar, met toegang via de Specifications - SPDX.</Specificatiedocument><Datum_van_aanmelding>25 juni 2024</Datum_van_aanmelding><Additionele_adviezen>Deze zijn als volgt (bron: intakeadvies SBOM 25 juni 2025):Aan de indiener en Forum Standaardisatie om het Europese standaardisatieproces voor SBOM-standaarden actief te monitoren. Heroverweeg het intakeadvies zodra geharmoniseerde EU-normen beschikbaar komen. Tot die tijd moet het Forum Standaardisatie terughoudend zijn met het adviseren tot verplichten (&#x2018;Pas toe of leg uit&#x2019;) of aanbevelen van een specifieke SBOM-standaard.Betrokken partijen zoals het Nationaal Cyber Security Centrum (NCSC), het Ministerie van Economische Zaken en het Nederlands Normalisatie Instituut (NEN) zouden niet alleen een volgende rol moeten hebben, maar ook een actieve rol kunnen pakken in het behartigen van de Nederlandse belangen binnen de Europese normontwikkeling. Door vroegtijdige en inhoudelijke betrokkenheid kunnen Nederlandse praktijkervaringen worden ingebracht in het Europese proces. Het is van belang dat deze partijen actief deelnemen aan werkgroepen, consultaties en afstemmingsoverleggen binnen de Europese normalisatie-instellingen om zo invloed uit te kunnen oefenen op de totstandkoming van werkbare en toepasbare normen.</Additionele_adviezen></Standaard></LijstOpenStandaarden>
