B.1. Beviskraft

Dette vedlegget er en diskusjon av BankID_SDO's mulige beviskraft for "ikke-benektelse", og er ikke en del av selve standarden. Det er tatt med for å gi eksempler på aktuelle problemstillinger hvis et BankID_SDO skal benyttes som bevis i en tvist. Hva som faktisk blir regnet som tilstrekkelig bevis i en tvistesak må avgjøres av domstolene.

Syntaksen til BankID_SDO-formatet stiller ikke krav til noen bestemt kommunikasjonsflyt i forbindelse med signering. I sin enkleste form kan et BankID_SDO bestå av kun hash av data som er signert, og en signatur av denne hashen. Et slikt objekt er lite verdt som bevismateriale.

Det er tre forhold som i etterhånd kan gi en signatur en høy grad av "ikke-benektelse":

• Tidsstempel som ikke kan forfalskes,
• OCSP-respons eller annen statusinformasjon som viser at sertifikatet var gyldig på det tidspunktet signaturen ble laget
• Sikker og gjenfinnbar lagring av signaturer og signerte data.

En ES-C (se A.4) inneholder nok data til å gi en betydelig grad av "ikke-benektbarhet" av signaturen. "Ikke-benektbarhet" er ingen juridisk term, og det antas at også en ES-C(bis) (se A.3) er holdbar juridisk sett under mange omstendigheter, for eksempel hvis signaturen er gjort av en sluttbruker, mens VA-oppslaget er gjort av en annen part, og denne parten har "bundlet" sammen signatur og oppslag. En høy grad av "ikke-benektbarhet" vil stille krav til bruk av tiltrodde tredje parter. En lavere grad av "ikke-benektbarhet" kan oppnås ved at kommuniserende parter samvirker og oppretter en felles tillitsstruktur for signerte data. Dette vil i praksis stille krav til kommunikasjonsflyten rundt signaturprosessen.

For å oppnå nødvendig sikkerhet rundt BankID_SDO må altså bruken nøye overveies, da det ikke er formatet i seg selv som setter rammene for beviskraft.

B.2 Lagring av BankID_SDO

Et BankID_SDO kan i prinsippet konstrueres av enhver som har den nødvendige informasjonen tilgjengelig: Et datasett, og en liste med signaturer knyttet til dette. Det å konstruere et BankID_SDO, og signere dette, innebærer ingen forpliktelse ifht grunnlagsdata (Her menes de dataene som er signert av de involverte partene, altså de dataene som er grunnlaget for beregningen av hashverdien i feltet "HashedData"), og hva dette innebærer for involverte parter. I praksis vil objektet bli laget av en av de involverte partene (typisk et brukersted på web-kanalen).

Når et BankID_SDO lagres er det valgfritt hvorvidt selve grunnlagsdataene skal lagres som en integrert del av objektet, eller om de skal ligge eksternt. Dersom de lagres eksternt er det valgfritt hvorvidt man angir lokasjonen av dataene i LocationURL-feltet i objektet. Både LocationURL-feltet, og eventuelle data lagret internt i objektet er utenfor den signerte delen av BankID_SDO, slik at feltene fritt kan endres uten å lage selve BankID_SDO- på nytt. Dette letter oppbevaringen av grunnlagsdata, samtidig som det gir mulighet for å benytte feltet når det er hensiktsmessig. Samtidig krever dette at man har kontroll på oppbevaringen av grunnlagsdataene. Uten disse kan man ikke verifisere hashverdien i BankID_SDO, og da vil objektet være verdiløst.