Autentisitetsstøtte

[oivkru]

Beskrivelse av behov

Det er behov for å kunne bekrefte/påvise at et informasjonsobjekt (dokument) er hva det gir seg ut for å være. Felles forståelse av hvordan man kan oppnå autentisitet - en metodisk tilnærming til hvordan det kan bevises.

Mål/motivasjon

For å kunne ha tillit til informasjon, må vi kjenne informasjonens opphav - hvem (person eller system) som har skapt det, og når det skjedde.

Suksesskriterier

Brukeren av informasjonsobjektet har tillit til at det er hva det gir seg ut for å være.

Område/prosess

Gir retningslinjer for dokumentasjonsprosessen, hvordan den skal dokumenteres for å inngi tillit til dokumentasjonen.

Målgrupper

Alle som har behov for tillit til dokumentasjonen.

Hastegrad

Middels. Er kravstilt i Noark, men ikke enkelt overførbart.

Forslag til løsning

Noark 5 inneholder krav og metadata for autentisitetsstøtte i dag, med blant annet krav til logging av hvem som oppretter en arkivenhet og når det skjer, samt en endringslogg. Det er ikke uten videre gitt at kravene, slik de er i standarden, passer andre løsninger. Tilsvarende krav kan gjøres mer generiske. Behovet er også berørt i flere ISO-standarder.

• Krav til fangstprosessen
• Krav til hvilke metadata som skal logges (hvem har gjort hva)

Anbefalinger, men også potensielt enkelte obligatoriske krav for å ivareta bestemmelser i ny arkivlov (jf. KUDs forslag §4) med eventuelle forskrifter. Ikke egnet som separat standard --> må passes inn som del av annen standard.

Risiko

• Kan være kilde til uenhighet at det tolkes ulikt
• Resultat har større potensial til å være vanskelig å forstå
• Vanskelige vurderinger rundt normeringsgrad

[yonyonson]

Begrunnelse for prioritering av behovet etter sesjon den 6. oktober 2022. Lenke til alle prioriteringer: github.com/arkivverket/standardlab/blob/master/styrende/veikart.md

Gjennomførbarhet

• Finnes løsninger fra før (trekker opp)
• Område er ganske omfattende og er ikke rett frem (trekker ned)"

Verdi

Verdifult, siden dette bidrar til bedre og mer forutsigbar kvalitet på dokumentasjonen.
Å fjerne behov for integrasjon mot arkivløsninger har verdi. Å løse dette vil gi arkiv med høy verdi mtp tillit.

Hastegrad

Dette henger sammen med sanering og integritet. Hastegrad vurderes for å være likt.

Risko

Autentisitet og integritet er ganske uavhengige og abstrakte behov

Redusjon av eksisterende risiko

• Risiko reduseres ved at vi kan få bedre, mer hensiktsmessige arkiveringsløsninger enn i dag
• Standardisering på riktig nivå gir lavere risiko
• Reduserer en kjent risiko ved suboptimale løsninger ved overføring til arkivløsninger.

Skapning av ny risiko

• Lav risiko for å standardisere på steder/nivå hvor det ikke er hensiktsmessig.

[sturtzel]

Ser stadig referanser til at Noark ikke er hensiktsmessig. Ja, det finnes fagsystemer som ikke produserer vedtak, men alt jeg har sett av angrep på Noark har vært synsing og ikke konkrete vurderinger av hva som er problemene slik at disse kunne vært adressert. Det jeg vet er at sluttbrukere vegrer seg fordi de synes det er vanskelig å angi alle metadata som forlanges. Men det går ikke nødvendigvis på strukturen.

[petterreinholdtsen]

[Ragnar Sturtzel]

Ser stadig referanser til at Noark ikke er hensiktsmessig. Ja, det finnes fagsystemer som ikke produserer vedtak, men alt jeg har sett av angrep på Noark har vært synsing og ikke konkrete vurderinger av hva som er problemene slik at disse kunne vært adressert. Det jeg vet er at sluttbrukere vegrer seg fordi de synes det er vanskelig å angi alle metadata som forlanges. Men det går ikke nødvendigvis på strukturen.

Enig. Klagesangen virker å være en salig saus av hva Noark 5-spesifikasjon sier, hva systemer som hevder å implementere Noark 5-spesifikasjonen gjør, hva Noark 4 sa, hva folk tror Noark 5-spesifikasjonen sier, hva Arkade5 klager over og en rekke andre varianter over temaet. Jeg tenker at når en uttaler seg om hva Noark 5 kan og ikke kan gjøre, så må en begrense seg til hva spesifikasjon, lovverk og forskrifter sier og gjør mulig, ikke hvordan de er tatt i bruk.

…

-- Vennlig hilsen Petter Reinholdtsen

[yonyonson]

Begrunnelse for prioritering av behovet etter sesjon den 31. januar 2022. Lenke til alle prioriteringer: github.com/arkivverket/standardlab/blob/master/styrende/veikart.md

Verdi

• 🟩 Kjerneverdi som må være på plass for at dokumentasjon skal kunne være en del av arkiv
• 🟨Denne verdien kan ikke kompenseres for om den går tapt, i motsetning til anvendbarhet.

Hastegrad

• 🟥 Lav hastegrad, siden vi har arbeidet noe med dette behovet, og lagt grunnlag. Kan sees på ved neste prioriteringsrunder.

Risko

• 🟥 STOR risiko for at vi mislykkes dersom vi gjør nytt forsøk på å behandle dette som separat behov
• 🟨 Relativt lav risiko for feilstandardisering hvis dette inngår i større normeringsprodukt - vi har allerede gjort viktige betraktninger

[Swoy]

Jeg er enig med @sturtzel og @petterreinholdtsen her. Det virker som om noen har lest introduksjonen til NOARK og konkludert med at det er vanskelig å lese resten, og derfor har bestemt seg for å starte på nytt.

Det er helt klart rom for forbedringer. Jeg mener at NOARK 6 bør videreføres og tilpasses slik at det er mulig å bruke ulike typer systemer, ikke bare de som er basert på vedtak. Det bør også stilles høyere krav til dokumentasjon av virksomhetsspesifikke datatyper og innhold. Standarden bør dessuten tilrettelegge for overordnet dokumentasjon av funksjonalitet, formatering og autentisitet.

Når det er sagt, så er jeg også enig i momentene som ytres i #25 rundt obligatoriske metadata. Vi bør se på hva som bør utgjøre dokumentasjonen og beskrivelser av et atomisk objekt i et dokumentasjonsmiljø - uavhengig av formål. Autentisitetsstøtte bør utgjøre en av datapunktene i det som blir grunnlaget for beskrivelsen av et objekt.

<metadata>
    <object oid="3.2.840.10003.5.109.12.1">
        <type oid="3.0.0.12334">document</type>
        <identifier type="uuidv4">550e8400-e29b-41d4-a716-446655440002</identifier>
        <version>2.1</version>
        <title>Dokumenteksempel</title>
        <creator oid="3.0.4.9238">Ola Nordmann</creator><!-- agentregister -->
        <organization oid="3.0.5.2039">Etaten</organization>
        <creationDate 
              timestamp="2023-03-24T15:30:00Z"
              signature="sha256::8ed4b4ed952526d89899e723f3488de4a9b2b5ab9f5ff2b09d8b6c5f5cd2e60e"/>
        <language>no</language>
        <format puid="fmt/477" mime="application/pdf">pdf-a-2b</format> <!-- pronom -->
        <description>Dette er et eksempel på et atomisk dokumentobjekt i en XML-standard.</description>
        <keywords>
            <keyword oid="3.0.3.14852">saksdokument</keyword> <!-- Identifikator i vokabularregister -->
            <keyword oid="3.0.3.12334">dokumentobjekt</keyword>
            <keyword oid="3.0.2.342">XML</keyword>
        </keywords>
        <rights oid="3.0.1.24">Åpen tilgang</rights>
        <dependencies>
            <filepath>atomic_document_example.pdf</filepath>
            <chain oid="3.0.0.2.477" function="executable" behaviour="pdf-viewer" />
            <sidecar id="550e8400-e29b-41d4-a716-446655440002_1" puid="fmt/101" mime="text/xml" ocrdata="true" />
        </dependencies>
        <signature version="RSA" encoding="Base64">
            MIIEpAIBAAKCAQEAzmtPzmn5G7kKw2CRgai7iUnJzFpjF7rcuoyjDl9XVaaZhdMx
            V7gJdQxZf7Jb0Y1yV7ogOJN0joV7ZTtT0TmTlBH0EePR3q1DR+bQlciYfR/XhRcE
            9QDGe2jKUZGo+8EwAxRgxyaUzFoYKcWk8nq3+kexB6jK1hZHE4xB4ydtkxay+J6G
            Y6YPAQ5S2E6UkQ+QDn0Bm8Ew0xJx6URy+GKrYgI8F3Wq3vEG+c0IgZc/z1d4wJ4o
            xg5K6Y5O6QIDAQABAoIBAQCUt65gZVyrOZ2urqp1x7xxtlYJyB7EOy8MCrPYV7E9
            hZTJa7ZM8aYY+q3e3QULh1Y7yFt8nRt9sEHDiDmTtPp0Dm3CmF3aTeiBA0YhGm8R
            9tjbcfB0ZFZVfg7VpWbH9X7VlNQ2uY3qN3Ox6s7Un6o2J4c3M4WJ1X9eL+0f0JjO
            Tzecf6+lnU6pFP1vPk8y6K+Qz0kI6FFhyZvYKZ6WUxI6f7wo6U1GvD8W6QI9Xb1a
        </signature>
        <relationships>
            <realm oid="3.2.840" />
            <parent>550e8400-e29b-41d4-a716-446655440000</parent>
            <sibling>550e8400-e29b-41d4-a716-446655440001</sibling>
        </relationships>
    </object>
</metadata>

En av de viktigste tiltakene for å øke bruken og kvaliteten av standarden er å introdusere flere referanseimplementasjoner som kan brukes i offentlig sektor for å håndtere systemer som omfattes av standarden. Dette vil bidra til å øke interoperabiliteten mellom systemene og sikre at de oppfyller kravene i standarden, særlig med tanke på autentisitet og forskriftskontroll.

Det er spesielt nødvendig å få på plass et nasjonalt verktøy for signering og validering av dokumenter, som kan sammenlignes med kontrollprosessene som allerede finnes for resepter i dag. Bruk av en slik implementasjon må deretter lovfestes for å sikre at informasjonsflyten fra det offentlige er kontrollert og pålitelig, uavhengig av hvilket system som brukes. Dette vil være relevant for alle typer dokumenter og systemer, inkludert sosiale medier og dokumenthåndteringssystemer som ephorte.

[oivkru]

@sturtzel @petterreinholdtsen @Swoy Intensjonen med det som står beskrevet om Noark 5 og autentisitetsstøtte over, er ikke å si at Noark ikke fungerer, eller at den ikke sørger for autentisitetsstøtte innenfor sitt domene. Poenget er at den ikke nødvendigvis er dekkende for autentisitet utover sitt domene. Det ligger altså ingen kritikk av Noark 5 i dette. (Undertegnede har tross alt vært med på å utarbeide standarden, og har forfattet mesteparten av ny tekst i siste versjon, så tro meg når jeg sier at det ikke er poenget med det som står.)

StandardLab skal ikke videreutvikle dagens Noark, eller lage en ny Noark (6), men utforske ny standardisering. Noark 5 er en aktuell gjenbrukskilde i dette arbeidet, så det handler ikke om å forkaste standarden, men vi skal heller ikke la ny standardisering styres av hva som har vært. Men siden den er aktuell som gjenbrukskilde, er det nyttig for oss å få kommentarer på hva som fungerer og hva som ikke fungerer, sånn at vi også har mulighet for å kvitte oss med gammel bagasje, jf. #25

Til det du skriver i tredje avsnitt, @Swoy , så er det nettopp det vi prøver å gjøre i arbeidet med en ny minimums informasjonsmodell nå. Ta gjerne en titt på det vi foreløpig har gjort på det her: https://github.com/arkivverket/standardlab/blob/master/standarder/infomodell-mvp.md

[Swoy]

@oivkru Jeg har lest innholdet du lenker til. Jeg har noen spørsmål:

1. Hvor mange er involvert i arbeidet med dette mandatet?
   Det kan virke som det bare er folk i arkivverket som har direkte innflytelse på valg og retning her, stemmer det?
2. Har det blitt gjennomført noen undersøkelser eller analyser i statlig, fylkeskommunal og kommunal sektor angående de aktuelle problemstillingene før utarbeidelsen av det nåværende forslaget?
3. Har det blitt vurdert flere ulike inndelingsmetoder og kombinasjoner av disse, for å sikre at standarden kan brukes av alle fagsystemer på tvers av disipliner og alle enheter med dokumentasjonsplikt i Norge?
4. Er det tatt høyde for utfordringer knyttet til sentraliserte løsninger, endringsutfordringer og fremtidig lesbarhet?
5. Hvilke vurderinger er gjort med hensyn til valg av en smidig metodikk i gjennomføringen av dette arbeidet?
6. Hvordan vil dere addressere bekymringer fra kommunal sektor om forslaget kanskje er for avgrenset i forhold til behovene utenfor Arkivverket, og hva er mulighetene for kommunal sektor til å direkte påvirke valgene som tas?

Er det mulighet for at jeg kan sende pull requests på forslag til endringer som jeg eventuelt har?
Jeg observerer ofte bruk av vi skal ta det med oss videre i arbeidet. Det gir et inntrykk av at dere ønsker å distansere dere fra interessenter i forvaltningen. Ville det ikke vært bedre om vi fikk lov til å ta del i dette på en aktiv måte, hvor vi kan være med i prosessen fremfor å sitte på gjerdet å vente på fôr?

[yonyonson]

1. Hvor mange er involvert i arbeidet med dette mandatet?
   Det kan virke som det bare er folk i arkivverket som har direkte innflytelse på valg og retning her, stemmer det?

Mandatet av StandardLab (som er dessverre ikke publisert på Github, men dette skal vi rette) er utarbeidet etter en bred prosess, med flere involverte (arkivverket.no/arkivutvikling/innebygd-arkivering/standardlab/dette-er-forprosjekt-standardlab). Selve beslutningen av mandatet er det Arkivverket selv som har gjort. Justeringer på mandatet skjer også i regi av Arkivverket, men på forslag fra team StandardLab som har faste deltakere fra andre deler av forvaltningen og ledes av ekstern arkivfaglig prosjektleder.

2. Har det blitt gjennomført noen undersøkelser eller analyser i statlig, fylkeskommunal og kommunal sektor angående de aktuelle problemstillingene før utarbeidelsen av det nåværende forslaget?

Det er gjennomført flere runder med intervjuer med aktører i statlig og kommunal sektor, samt leverandører og premissgivere gjennom både forprosjektet og i behovsinnhentingen etter at prosjektet kom i gang ( github.com/arkivverket/standardlab/blob/master/rapporter/funn-behovsinnhenting-2022q4.md ). Det konkrete forslaget til minimumsmodell har foreløpig ikke vært diskutert med relevante aktører, men det er noe vi kommer til å gjøre.

3. Har det blitt vurdert flere ulike inndelingsmetoder og kombinasjoner av disse, for å sikre at standarden kan brukes av alle fagsystemer på tvers av disipliner og alle enheter med dokumentasjonsplikt i Norge?

Vi skal ikke lage én ny standard, men ser for oss flere mindre moduler/standarder/normerende produkter, som enten er uavhengig av hverandre, eller som støtter opp om hverandre. Men vi har ikke oversikt over det komplette landskapet enda, vi har begynt med en minimumsmodell for å dekke ett behov.

Målet med disse normeringsproduktene (standardene) er å dekke alle løsninger som ivaretar arkivplikten, som er en del av arkivlova. Dokumentasjonsplikt fører til at dokumentasjon skapes, men ikke alt som skapes som følge av dokumentasjonsplikt faller under arkivplikten. Arkivplikten er innenfor omfanget til StandardLab, og dokumentasjonsplikten er ikke det.

4. Er det tatt høyde for utfordringer knyttet til sentraliserte løsninger, endringsutfordringer og fremtidig lesbarhet?

Minimumsmodellen skal kunne være grunnlag også for slike løsninger, men må utvides for å håndtere alle behov. Den er foreløpig kun ment som minimumsmodell for hva enhver registrering og aggregering må ha i danningsøyemed.

Vi sikrer for at alle modellene og APIene våre ivaretar arkivfaglige hensyn slik de defineres i §4 2. avsnitt av forslag til den nye arkivlova ( regjeringen.no/no/dokumenter/hoyring--forslag-til-ny-arkivlov/id2872622/ ). Utfordringer med mulig fremtidig lesbarhet adresseres i bokstav b “informasjonsinnhaldet kan nyttast”. Utfordringer med endringer som kjent opphav adresseres i bokstav c “opphavet til informasjonen alltid er kjent”. Utfordringer med endringer som sikring av informasjonsinnholdet er ikke endret er bokstav a “informasjonsinnhaldet ikkje blir endra”.

For å svare kort – ja, vi tenke på dette siden vi har alltid §4 i den kommende arkivlova foran oss.

5. Hvilke vurderinger er gjort med hensyn til valg av en smidig metodikk i gjennomføringen av dette arbeidet?

Bruk av smidig metodikk har alltid vært integral del av prosjektet. Vi har bevisst variert mellom forskjellige varianter av ren smidig utvikling, kanban og andre måter å jobbe på siden oppstart av forsprosjektet i 2021.

Teamene både i forprosjektet og selve arbeidet sørget for å justere sine planer og forutsetninger kontinuerlig, og vi fortsetter å gjøre dette gjennom bl. a. å ha denne Github repo og holde dialog med alle interessenter.

6. Hvordan vil dere adressere bekymringer fra kommunal sektor om forslaget kanskje er for avgrenset i forhold til behovene utenfor Arkivverket, og hva er mulighetene for kommunal sektor til å direkte påvirke valgene som tas?

Målet med StandardLab er at vi skal være åpne og involverende (ref prinsipper github.com/arkivverket/standardlab/blob/master/styrende/maal-og-prinsipper.md ), så det har vi tenkt å adressere.

Vi jobber med dette gjennom forløpende dialog i form av intervjuer (se f.eks. resultater av behovssamtaler i 4. kvartal 2022: github.com/arkivverket/standardlab/blob/master/rapporter/funn-behovsinnhenting-2022q4.md ). Vi tar også folk fra kommunal forvaltning i teamet for StandardLab som hospitanter, og i dag er ansatt fra Nordland fylkeskommune som deltar i vårt arbeid daglig.

Vi kommer antagelig aldri å sette opp helt konkrete planer på hvordan vi kommer å adressere bekymringer fra kommunal sektor siden vi jobber smidig, men vi er alltid åpne for dialog og utveksling av meninger, og vi lar oss påvirke.

Er det mulighet for at jeg kan sende pull requests på forslag til endringer som jeg eventuelt har?

Klart det. Det blir veldig mye lettere å snakke om endringsforslag når de blir mer konkrete, så kjør på.

Jeg observerer ofte bruk av vi skal ta det med oss videre i arbeidet. Det gir et inntrykk av at dere ønsker å distansere dere fra interessenter i forvaltningen. Ville det ikke vært bedre om vi fikk lov til å ta del i dette på en aktiv måte, hvor vi kan være med i prosessen fremfor å sitte på gjerdet å vente på fôr?

Det er intensjonen at vi skal ha aktiv deltakelse, både når behov meldes inn, raffineres og prioriteres. Formålet med bruk av GitHub er nettopp dette. Du (og andre) er velkomne til å komme med både pull requests på endringer (hvis du har konkrete forslag til formuleringer) og til å foreslå endringer uten å komme med formuleringsforslag via Issue-malen «Endringsønske».

Når vi svarer at vi tar med oss innspill i det videre arbeidet, handler det primært om at vi ikke jobber med det innspillet handler om konkret akkurat nå, vi må ta en bit av gangen.

[yonyonson]

Vi har lagt ut nåværende mandatet til StandardLab her: https://github.com/arkivverket/standardlab/blob/master/styrende/2022juli%20Prosjektmandat%20StandardLab-publiseringsversjon.pdf