Dokumenter signering per mottaker og dokumentversjon
Skill sendt forespørsel, delvis signering og endelig signert dokument med bevart bevisgrunnlag.
Et dokument sendt til signering er ikke nødvendigvis signert av alle aktuelle mottakere. Et grønt merke på en oppgave kan gjelde bare én del av forløpet. For etterprøvbar datautveksling trengs signeringsoppdrag, dokumentversjon og mottakerhendelser som separate koblede objekter.
Digdirs eSignering-dokumentasjon beskriver en offentlig signeringstjeneste og viser til teknisk dokumentasjon hos leverandøren. Den er et relevant kildeeksempel på tjenesteavgrensning, ikke bevis på at et privat økonomisystem bruker denne løsningen. Rettstype, signaturnivå og juridisk virkning må vurderes særskilt i den aktuelle saken.
Bevar hva mottakeren faktisk signerte
Et oppdrag bør peke på en bestemt dokumentutgave med identitet eller annen kontrollerbar innholdsreferanse. Hvis filen endres etter første signatur, må systemet kunne vise hva som skjer med allerede mottatte signaturer. En fil med samme navn er ikke nødvendigvis samme innhold.
Skil et sendt varsel fra en gjennomført signeringshendelse. Mottakeren kan ha fått e-post uten å ha åpnet eller signert dokumentet. Statusbeviset må kunne knyttes til tjenestens faktisk dokumenterte svar, ikke til at avsenderens e-postjobb kjørte uten feil.
Syntetisk oppdrag med tre mottakere
Eksemplet bruker lokale testreferanser og oppdiktede statusnavn. Det beskriver ingen bestemt signeringstjenestes API.
| Mottakerrolle | Dokumentutgave | Hendelse | Samlet betydning |
|---|---|---|---|
| Part A | D-07 versjon 1 | Signert | Ett mottakerkrav er oppfylt |
| Part B | D-07 versjon 1 | Signert | To mottakerkrav er oppfylt |
| Part C | D-07 versjon 1 | Venter | Oppdraget er ikke fullført i testregelen |
| Arkiv | D-07 versjon 1 | Ikke ferdigstilt | Endelig bevispakke gjenstår |
Dersom testavtalen krever alle tre mottakere, kan oppdraget ikke lukkes etter de to første. Dersom en annen avtale har annen rollefordeling, må kontrollregelen beskrive den konkret. Antall signaturer alene fastsetter ikke hvem som skulle signere eller hvilken fullmakt vedkommende hadde.
Avvisning og ny versjon
Prøv en mottaker som avviser, en forespørsel som utløper og et oppdrag som trekkes tilbake. Disse hendelsene er forskjellige fra vellykket signering. Gjentatt uthenting av status skal ikke opprette nye signaturer i historikken.
Prøv deretter at versjon 2 sendes med et endret beløp. Historikken må ikke flytte signaturen fra versjon 1 til versjon 2 bare fordi dokument-ID-en er lik. Bevar hvilken utgave hvert bevis gjelder og hvilken endringsregel den faktiske tjenesten bruker.
Et arkiv må kunne oppbevare det signerte dokumentet og det relevante bevisgrunnlaget med forståelige referanser. En lokal kopi uten kobling til signeringshendelsen kan være nyttig for lesing, men er svakere som dokumentasjon av hvem som signerte hva. Kontroller gjenfinning med en annen rolle enn den som opprettet oppdraget.
- Dokumentér mottakerkrav og dokumentutgave før utsending.
- Bevar hendelser uten å likestille varsel og signatur.
- Test at endret innhold ikke arver gammelt signeringsbevis.
Dokumentversjoner og sjekksum for filer gir beslektede kontroller. Modellen støtter etterprøvbarhet, men avgjør ikke fullmakter eller dokumentets gyldighet.
Roller må ikke utledes fra e-post
En mottakeradresse viser hvor forespørselen ble sendt, men ikke alene hvilken rolle eller fullmakt personen hadde. Avklar det nødvendige rollegrunnlaget i den aktuelle arbeidsflyten, og bevar referansen med riktig tilgang. En oppgave kan ha teknisk komplette signaturhendelser og likevel kreve en annen vurdering av mottakerrollen. Ved kontroll bør disse spørsmålene ikke få én felles status «gyldig». Hold teknisk bevis, dokumentinnhold og rettslig eller organisatorisk vurdering i forskjellige spor, slik at en senere ansvarlig kan se nøyaktig hvilken kontroll som faktisk ble utført.