search

nl-digigo / visi

Beheeromgeving van de VISI open standaard.
https://nl-digigo.github.io/visi/
6 stars 4 forks source link

User story "Betrouwbaarheid van archiefdata" #70

Open ElisabethKloren opened 5 years ago

ElisabethKloren commented 5 years ago

Actiehouder gebruikerscommissie: Suzan van der Broek en Henk Wieggers

ArneBruinse commented 4 years ago

Wat komt er binnen (vraag /opmerking) (uitgangspunt: de vraagsteller is ‘bewust onbekwaam’)

Omschrijving van de vraag/opmerking zelf (bij voorkeur in het format van ‘userstory’): a. Als organisatie b. Wil ik Garantie op betrouwbaarheid van VISI gegevens in de applicatie (tijdens project) en in het archief (= buiten de applicatie) c. Zodat ik weet dat het archief niet aangepast is achteraf/ de data die ik uit het archief haal correct is (zowel het "door VISI inleesbare archief", als het "door mensen te lezen dossier")

Naam, functie (soort gebruiker/rol), diens organisatie, en de soort organisatie van de vraagsteller (stakeholder) - Gebruikerscommissie, Suzan, Maartje, Henk (Amsterdam, ProRail, Rijksvastgoedbedrijf)

Datum en oorsprong van het verzoek - – Gebruikerscommissie 23-01-2020

Waarop heeft de vraag betrekking: a. Open Standaard (VISI / COINS)

Wat is de urgentie ) ‘M’ (must have; hindert de dagelijkse procesgang/doorgang van een project; moet zo spoedig mogelijk worden opgelost)

Toelichting op de urgentie*

De wettelijke verplichting; 2. Dat je betrouwbare gegevens hebt; 3. Dat een applicatiebeheerder of leverancier niet zomaar berichten kan wissen.

ElisabethKloren commented 4 years ago

Format voor (intake en afhandeling van) issues GC180508-09

GC / 8 mei 2018

Wat komt er binnen (vraag /opmerking) (uitgangspunt: de vraagsteller is ‘bewust onbekwaam’)

  1. Omschrijving van de vraag/opmerking zelf (bij voorkeur in het format van ‘userstory’): a. Als organisatie b. Wil ik Garantie op betrouwbaarheid van VISI gegevens in de applicatie (tijdens project) en in het archief (= buiten de applicatie) c. Zodat ik weet dat het archief niet aangepast is achteraf/ de data die ik uit het archief haal correct is (zowel het "door VISI inleesbare archief", als het "door mensen te lezen dossier")

  2. Naam, functie (soort gebruiker/rol), diens organisatie, en de soort organisatie van de vraagsteller (stakeholder) - Gebruikerscommissie, Suzan, Maartje, Henk (Amsterdam, ProRail, Rijksvastgoedbedrijf)

  3. Datum en oorsprong van het verzoek - – Gebruikerscommissie 23-01-2020

  4. Waarop heeft de vraag betrekking: a. Open Standaard (VISI / COINS)

  5. Wat is de urgentie ) ‘M’ (must have; hindert de dagelijkse procesgang/doorgang van een project; moet zo spoedig mogelijk worden opgelost)

  6. Toelichting op de urgentie*

      1. De wettelijke verplichting; 2. Dat je betrouwbare gegevens hebt; 3. Dat een applicatiebeheerder of leverancier niet zomaar berichten kan wissen.

‘Open Standaard’

  1. Stel vast of het een ‘bug’ is, of een ‘verbetervoorstel’, of een ‘ander verzoek’

  2. Verbetervoorstel a. Maak de userstory expliciet; mogelijk valt die uiteen in meerdere user stories

    a. Een bericht moet niet veranderd kunnen worden
    Reactie expertcommissie: hiervoor zou een digitale handtekening gebruikt kunnen worden; omdat er een hash bij het bericht wordt gestopt met een public key, het bericht hoeft dan verder niet te worden versleuteld. Advies zou wel zijn, om een digitale handtekening om organisatieniveau af te geven. De kosten / betaalbaarheid van deze oplossing moet wel worden onderzocht.

    b. Een bericht moet niet verwijderd kunnen worden Reactie expertcommissie: Tijdens het project: Hiervoor is het soap-protocol waarin de ontvangende partij confirmation stuurt van het ontvangen bericht. Dus een heel bericht verwijderen aan de andere kant kan tijdens het projectverloop worden aangetoond. Na archivering: Advies om bij archivering het hele archief te hashen. De kosten / betaalbaarheid van deze oplossing moet wel worden onderzocht.

    c. Indien dit aan de ene zijde wel is gedaan, moet de andere partij kunnen aantonen dat het ontvangen bericht wel degelijk door tegenpartij is verstuurd.

    Reactie expertcommissie: zie a

    b. Beschrijf de randvoorwaarden a. De garantie moet tijdens het project en na archivering gelden;

    c. Completeer de ‘definition of ‘done’ Het verzoek is als eis opgenomen in de volgende versie van de VISI standaard. d. Beschrijf het verbetervoorstel / of gewenst gedrag Tijdens of na een project moet het dossier uit een VISI applicatie gegarandeerd de juiste berichten bevatten. e. Beschrijf de voordelen van de verbetering f. Beschrijf eventuele “Alternate Flows” (“capture the less common user/system interactions, such as being on a new computer and answering a security question). g. Beschrijf eventuele “Exception Flows” (“things that can happen that prevent the user from achieving their goal, such as providing an incorrect username and password).

  3. Plaats de gedocumenteerde bug, verbetervoorstel of ander verzoek op de verzamellijst ter prioritering in het kader van de release cyclus (ook op github??)

‘VISI Raamwerk’ of ‘COINS Referentiekader’

  1. Stel vast of het een ‘bug’ is of een ‘verbetervoorstel’ in de standaard, of een probleem bij het gebruik van de standaard (bij VISI: het maken van raamwerken; bij COINS: het gebruik van een referentiekader)

  2. Indien ‘Bug’ of ‘verbetervoorstel’ voor de Standaard a. Verplaats de vraag naar het bakje ‘Standaard’ en handel daar af conform procedure

  3. Indien probleem bij gebruik a. Beschrijf de vraag zo gedetailleerd mogelijk (indien alsnog een probleem met de standaard blijkt: zie 2.) b. Beschrijf de voordelen van het voldoen aan het verzoek c. Plaats op lijst ter afhandeling (door beheerder van de OS, helpdesk of adviseur)

‘Software’

  1. Betreft het VISI-software of COINS-software a. Is het een generiek probleem -> zie punt 2 b. Is het een specifiek probleem: informeer (de helpdesk) van de desbetreffende softwareleverancier c. Informeer eventueel de desbetreffende Expertcommissie en Gebruikerscommissie

  2. Generiek probleem voor de Standaard a. Verplaats naar het bakje ‘Standaard’ en handel daar af

  P.S. Definition of ‘DONE’ (checklist):

De ‘definition of done’ is de checklist van dingen die gedaan moeten zijn voordat je klaar bent met een issue. Er is een generieke definitie, maar ‘done’ moet goed aansluiten bij de vraag. Het kan dus voorkomen dat er nog specifieke dingen aan moeten worden toegevoegd. Dat moet dan gebeuren voordat het oplossen van de vraag start. • Generieke ‘definition of ‘done’ is helder • Eventuele specifieke dingen die ook moeten zijn gedaan, moeten aan de generieke definition of ‘done’ worden toegevoegd

De check van de oplossing is dan (voor zover relevant): • Alle ‘to do’ items voor de User Story zijn voldaan, inclusief de specifiek toegevoegde dingen. • Relevante gebruikersdocumentatie is gemaakt of aangepast. • Relevante technische documentatie is bijgewerkt en geactualiseerd. • De ‘reporter’ heeft het werk geaccepteerd. • Er is feedback van eindgebruiker(s)/vraagsteller gevraagd/gekregen op het opgeleverde product. • Alle unit- (bouwer), integratie (productowner) functionele (key users) testen zijn succesvol gedraaid. • Indien hiervan afgeweken wordt dan is dit opgenomen in de userstory (afwijkingen opgenomen in userstory).

ElisabethKloren commented 4 years ago

Uit verslag beheercommissie, 15 mei 2020: Gaat om: te kunnen controleren of een bericht origineel is. Stel: een bericht wordt verstuurd met VISI, van de ene partij naar de andere. Later blijkt dat dit bericht bij de ene partij anders is dan bij de andere. Wie heeft het bericht gewijzigd? Dat kan door een softwareleverancier, of een systeembeheerder gedaan worden. Of iemand die toegang heeft tot het archief. Amsterdam met IBR discussie gehad. Als beheerder kan je bij berichten en gebruikers van VISI. Wat doe je daar zelf in de organisatie aan. Dat wordt in VISI strak geregeld. Een digitale handtekening is iets anders: dat is om te kunnen controleren, dat de persoon in het bericht ook echt degene is die het bericht heeft verstuurd. Dit voorstel gaat over het hele bericht, met bijlages en al. De standaard regelt dit, maar via vertrouwen in de softwareleveranciers en beheerders. Terwijl er een eenvoudige technische oplossing voor bestaat. Hoe strak is handtekening in VISI. Opdracht voor Expertcommissie: Wij willen dat een VISI-bericht met een hash wordt verstuurd, met een public key, zodat tijdens en na het project gecontroleerd kan worden dat het bericht niet gewijzigd is.

jvgeijlswijk commented 3 years ago

Voor geschiedenis over dit onderwerp zie: https://github.com/bimloket/visi/issues/11

ArneBruinse commented 3 years ago

Hier ook het in #11 genoemde vervolg item uit codeplex: Prio-323: Open Standaard Digikoppeling gebruiken voor communicatie tussen SOAP servers Achtergrond Zie https://visi.codeplex.com/workitem/4602 voor het onderzoek naar DigiKoppeling Zie https://visi.codeplex.com/workitem/1010 voor Waarborgen integriteit en authenticiteit van VISI-berichten

Technische oplossing ...

Backwards compatibility ...

Acties:

stuf.bindingen.030203.pdf Digikoppeling_3.0_Architectuur_v1.2.pdf Digikoppeling.docx e-mail Peter Willems vr 8-4-2016 1307.pdf Stuf0301_20160603_pre-patch25.zip stuf.bindingen.030200.docx

ArneBruinse commented 3 years ago

Het in codeplex 4613 genoemde item 4602: Doel is om in VISI 2.0 de Digikoppeling te gebruiken voor de communicatie tussen SOAP servers, en daarmee een aantal zaken uit de VISI standaard te halen en in plaats daarvan te verwijzen naar de Digikoppeling. Hiervoor is issue 4613 aangemaakt.

Ge Spees schreef op 8 juni 2015: Alle punten waar wij gebruik van maken of nog willen gaan maken bij het verzenden van VISI berichten over internet lijken terug te komen in deze standaard. Het lijkt erop dat wij redelijk eenvoudig kunnen aansluiten bij Digikoppeling. Voor we dit definitief kunnen beoordelen zullen we dit zorgvuldig moeten onderzoeken.

Wanner het mogelijk blijkt deze standaard toe te passen kunnen we een deel van de kennis uit de VISI-Systematiek halen en daarmee de standaard eenvoudiger maken. Een ander voordeel is dat de organisatie achter deze standaard zich volledig hier op richt en in de toekomst tot betere aanbevelingen kan komen.

Digikoppeling PDF documentatie

Op 9-6-2015 schreef Paul Jansen: Digikoppeling is een zogeheten ‘Stelselvoorziening’ wat het aansluiten erbij misschien nog wel belangrijker maakt. http://www.digitaleoverheid.nl/onderwerpen/stelselinformatiepunt/stelsel-van-basisregistraties/stelselvoorzieningen Zie de attachment.

Digikoppeling 2.0 staat al op de lijst van Open Standaarden. https://lijsten.forumstandaardisatie.nl/open-standaard/digikoppeling Logius blijkt deze standaard te beheren/ondersteunen. https://www.logius.nl/diensten/digikoppeling/ Als je even doorklikt kom je (toch niet direct) op http://www.digitaleoverheid.nl/onderwerpen/stelselinformatiepunt/stelsel-van-basisregistraties/stelselvoorzieningen/digikoppeling waar de nodige verdere informatie over 2.0 wordt gegeven. Closed

4602 | Created 2015-06-08 | Updated 2017-11-10

ArneBruinse commented 3 years ago

Samenvatting van de oorspronkelijke vraagstelling/stakeholder requirements:

Men wil de betrouwbaarheid van de gegevens verhogen, zowel tijdens het gebruik als in de archief fase. Men wil altijd kunnen aantonen/ controleren dat de data niet aangepast zijn. Men wil dat het niet mogelijk is om visi berichten te wissen, bijv door een database administrator of iemand die in de zip van het archief kan.

Oplossingsrichting voor systematiek 1.7:

We kiezen niet voor Digikoppeling zoals in het verleden is voorgesteld, omdat dit vooral over soap verzending gaat en juist niet over het signen. Ook omdat dit vooral bedoeld is voor verkeer tussen overheden onderling en daardoor niet geschikt voor het bedrijfsleven. Het idee is net zoals in de visi 1.5 systematiek, maar dit keer volgens een europese standaard.

@jvgeijlswijk ik hoorde van @gspees dat jij tijdens de programmeerfase van de 1.5 standaard goede argumenten had waarop dit uit de 1.5 standaard gehaald is. Weet jij nog wat die argumenten waren?

@ all : ik heb net ruggespraak met Ge gehad en wij willen toch echt graag met jullie onderzoeken wat de mogelijkheden zijn voor een echte digitale handtekening, zodat wij als software leverancier 100% afgedekt zijn wat betreft de originaliteit van het bericht. Als wij nu nog steeds alle interne berichten zomaar kunnen aanpassen of alle berichten waar beide klanten dezelfde leverancier hebben, gewoon kunnen aanpassen, dekken we helemaal niet de gestelde eis af. Dus wat B&S betreft nemen we liever meer tijd om dit echt meteen goed te doen. Het voorstel dat we vanochtend besproken helpt nu eigenlijk maar voor een minimaal percentage visi berichten, dat tussen 2 leveranciers is gestuurd en verder niet.

Wat we ook niet moeten vergeten is de eis van het niet verwijderen van berichten. Moeten we ook hele archieven gaan signen?

Voorgestelde techniek:

Het hashen en signen van de visi berichten volgens de europese Digital Signature Service (DSS) techniek: https://ec.europa.eu/cefdigital/DSS/webapp-demo/doc/dss-documentation.html#_xades_baseline_t_2

Uitleg werking van de techniek:

Zie voor een completen en nog leesbare uitleg deze wikipedia pagina: https://nl.wikipedia.org/wiki/Certificaat_(PKI)

Kort gezegd werkt dit als volgt: Jip wil een bericht aan Janneke sturen. Jip heeft een certificaat bestand met daarin een geheime sleutelcode. (de private key) Jip heeft ook een bij de private key behorende openbare sleutelcode die hij met iedereen deelt (de public key) Als jip zijn bericht verstuurt, kan zijn software een unieke code oproepen die de exacte inhoud van zijn bericht weergeeft (de hash). Als iemand later 1 karakter wijzigt aan dat bericht, komt er een andere hash uit. Zijn software bouwt op basis van die hash code met de private key een sign code op. Het bericht komt bij janneke binnen met die sign code.

Janneke of wie dan ook, kan nu altijd dat bericht van Jip controleren. Janneke roept zelf de hash van het bericht op die als het goed is dus hetzelfde is als hij bij Jip was. Daarna rekent Janneke de public key , de hash en de sign code van het bericht door of deze drie bij elkaar passen. Want alleen met de private key in je bezit, kun je een sign code voor een hash maken die klopt met de public key.

Wat dekt dit af:

De oplossing van vanochtend alleen berichten die tussen Alfamail en B&S of andersom gestuurd zijn

Wat dekt dit nog niet af:

Persoonlijke signing Het aan kunnen passen van een bericht aan de kant van de verzender. Als beide partijen bij de zelfde leverancier zitten kan dit leiden tot integriteitsconflicten.

Mogelijke toekomstige ontwikkelingen / aanbevelingen:

Om de haalbaarheid voor de 1.7 systematiek te garanderen, stellen we nu bovenstaande oplossing voor.

JensCobussen commented 3 years ago

Op basis van een discussie/onderzoek op 29-05-2020 (door Gé, Ed en Jens)

Zijn wij op de volgende oplossing gekomen een eSignature van de Europese commissie. https://ec.europa.eu/cefdigital/wiki/display/CEFDIGITAL/eSignature

De eSignature kan gebruikt worden om Signatures aan te maken en te verifiëren in lijn met de Europese standaarden. Een van deze standaarden is de XAdES (XML Advanced Electronic Signatures) standaard. https://www.w3.org/TR/XAdES/

Naast eSignature is het mogelijk om zelf ook deze oplossing te implementeren, hiervoor levert de Europese commisie documentatie: https://ec.europa.eu/cefdigital/DSS/webapp-demo/doc/dss-documentation.html#_introduction'

Daarnaast zijn er ook implementaties van de XAdES standaard te vinden: https://github.com/giosil/xades

Op basis van de hierboven gegeven informatie moet er nog een onderzoek worden gedaan over hoe en wat we hiervan willen gebruiken en hoe deze geïmplementeerd kan/gaat worden.

ArneBruinse commented 3 years ago

Speuren naar aanvullende informatie heeft me nog dit opgeleverd de afgelopen periode:

Documentatie van een open source sgning tool van de EU als ik het goed snap? Naamloze bijlage 00837.pdf

https://joinup.ec.europa.eu/collection/eidentity-and-esignature/news/dss-tool-esignatures-crea

https://ec.europa.eu/cefdigital/DSS/webapp-demo/home https://ec.europa.eu/cefdigital/DSS/webapp-demo/doc/dss-documentation.html#_purpose_of_the_document

ArneBruinse commented 3 years ago

Ons voorstel voor de 1.7 standaard is om eerst de basis op orde te maken: Dus heel lean eerst de eerste stap bouwen in 1.7 en daarna verder kijken. De eerste stap is VISI berichten kunnen signen conform de XAdES richtlijn

En om alles overzichtelijk te houden, zou dit Epic in verschillende userstorys/issues opgeknipt moeten worden. Dus eerst eentje om visi berichten volgens XAdES te kunnen signen in 1.7

Daarna de verschillende andere eisen in dit issue identificeren en per eis een issue uuitwerken.

De eis om geen enke bericht als software leverancier weg te kunnen gooien uit een nog lopend project is iets heet anders dan dezelfde vraag voor een archief, de eis dat een software leverancier zelf geen bericht kan ondertekenen zonder instemming van de gebruiker is ook weer iets heel anders.

Daarnaast moet er ook per eis bekeken worden of de eis wel een eis is die in de standaard thuis hoort of dat het een eis is die aan een software leverancier gesteld moet worden door een klant,. Dat is gelukkig bij de eerst uit te voeren eis geen discussie, die kan alleeen maar middels de standaard geimplementeerd worden.

jvgeijlswijk commented 3 years ago

Tijdens VISI Expertcommissie op 27-11-2020 besproken om deze grote user story op te knippen in kleinere user stories. Te beginnen met de user story om het berichtenverkeer tussen twee VISI systemen te verrijken met signing en hashing. Dit wordt een apart ticket en verwerkt in versie 1.7 van de VISI Standaard. Dit ticket blijft open staan om de overige wensen van gebruikers in versie 1.8 of hoger te verwerken. Dit ticket is: https://github.com/bimloket/visi/issues/96

ArneBruinse commented 3 years ago

@ElisabethKloren We hebbenb afgesproken dat jij dit issue opknipt in meerdere issues. Misschien een extra "project" aanmaken, waar al deze items aan hangen?

ArneBruinse commented 2 years ago

Deze US is de verzamelbak, waaruit meerdere mogelijke userstories kunnen volgen. Voor stap 1: Zie https://github.com/bimloket/visi/issues/96 voor de uitwerking van stap 1: het ondertekenen van alle visi berichten. mogelijke stap 2: Onderzoeken of en hoe tijdens de looptijd van een project gegarandeerd kan worden dat er niets is verwijderd. mogelijke stap 3: Als dit in productie is, kan er een nieuwe US gestart worden waarin ook de volledigheid van een archief export kan worden gecontroleerd, door bijvoorbeeld het gehele archief te ondertekenen.

tessaderoos commented 4 months ago

Signen van archief inclusief confirmations