Støtte for å sende signerte dokumenter

[sindrebn]

I forbindelse med at signeringstjenesten utvides med videresending av signerte dokumenter (PAdES) til innbyggers postkasse har det dukket opp et behov for å skille disse signerte dokumentene fra «vanlige» dokumenter.

Rasjonalet bak dette er at et signert dokument kan ha en litt annen rolle enn et «vanlig dokument» – kanskje ønsker man for eksempel å markere dokumentet som «Signert dokument» e.l. i grensesnittet til innbygger. I tillegg kan man se for seg at dersom signeringstjenesten sender med metadata (for eksempel om når dokumentet ble signert), kan dette også vises i grensesnittet til innbygger. Dette vil føre til bedre brukeropplevelse for innbyggeren og bygge opp under en helhetlig opplevelse av signeringstjenesten og postkassene som felleskomponenter.

Endringen bør gjøres bakoverkompatibel slik at postkasseleverandørene kan velge om de ønsker å implementere støtte for denne nye dokumenttypen. Dette kan for eksempel realiseres ved at typen Dokument blir utvidet med frivillige felt(er) som tillater avsenderen (signeringstjenesten) å spesifisere at et gitt dokument er et signert dokument.

Posten kommer tilbake med konkret forslag til XSD-endring.

[sindrebn]

Opprettet dette issuet, som avtalt @aberner og @ramung, slik at vi kan komme frem til en løsning som funker bra for alle parter.

[sindrebn]

Posten foreslår som nevnt at Dokument utvides med et frivillig element signert-dokument. Dette elementet har to obligatoriske under-elementer: signeringstidspunkt og antall-undertegnere.

Et hoveddokument kan dermed se slik ut, dersom det er en PAdES med to signaturer:

<hoveddokument href="ansettelsesavtale.pdf" mime="application/pdf">
    <tittel lang="no">Ansettelsesavtale</tittel>
    <signert-dokument>
        <signeringstidspunkt>2017-03-06T08:45:00+02:00</signeringstidspunkt>
        <antall-undertegnere>2</antall-undertegnere>
    </signert-dokument>
</hoveddokument>

Ser Difi behov for at signeringstjenesten sender mer eller annen metadata til postkassene? Andre kommentarer?

[kjorlaug]

Kvifor utvide dokument-typen? Dette handlar om å synleggjera samanheng mellom dokument og strukturerte data relatert til dokumentet - signeringsdata er ikkje einaste bruksscenarie. Er det ikkje betre å endre dokument slik at ein kan referere til andre dokument i same dokumentpakke?

Døme:

<hoveddokument href="ansettelsesavtale.pdf" mime="application/pdf">
    <tittel lang="no">Ansettelsesavtale</tittel>
</hoveddokument>
<vedlegg href="signeringsdata.xml" mime="text/xml-sign" extends="#ansettelsesavtale.pdf">
</vedlegg>

Skalerer litt betre :)

[sindrebn]

Jeg er usikker på om jeg forstår rasjonalet bak forslaget ditt. Forslaget vårt kan fint utvides til å støtte andre bruksscenarier ved å legge til ytterlige frivillige typer tilsvarende signert-dokument som kan knyttes til Dokumentet.

Slik jeg tolker det er det du foreslår heller ikke generisk. Dersom det skal kunne behandles som strukturerte data må det defineres et schema som beskriver hvordan vedlegg av typen text/xml-sign skal se ut også. Jeg er dermed usikker på hvordan det forslaget skalerer bedre, det virker sågar litt unødig komplekst for meg. Spesielt for postkasseleverandørene som skal implementere tolkningen av dette ser jeg for meg at det er vesentlig økt kompleksitet i å håndtere dokumenterer som refererer til hverandre sammenliknet med vårt forslag hvor metadataen er direkte knyttet til det relevante dokumentet og er lett tilgjengelig for uthenting.

Kan du utdype litt hvorfor du mener ditt forslag skalerer bedre?

[aberner]

Bakgrunnen for forslaget er at vi ønsker å unngå at Digitalpost melding må endres for hver eneste dokument/funksjonstype som skal overføres. Dette er ganske likt som overføring av strukturerte data knyttet til faktura, som vi har diskutert med dere inngående i lang tid. Der også er det to alternativer, enten å utvide digitalpostMelding med noen strukturerte datafelter spesifikt for faktura området, eller å legge ved en strukturert.xml fil for å bære den samme informasjonen. Der har vi valgt å bruke den metoden som @kjorlaug henviser til.

Difi tror at signert-dokument og fakturaer er kun to eksempler på et stort antall forskjellige dokumenttyper. Derfor mener vi også at dette heller bør lages som egne meldingstyper som ligger i dokumentpakken.

For faktura så bruker vi EHF formatet for å sende de strukturerte dataene. For signerte dokumenter har vi ikke tilsvarende standard kanskje, jeg antar at kanskje http://docs.oasis-open.org/dss/v1.0/oasis-dss-core-spec-v1.0-os.html kan inneholde relevante deler som kunne vært brukt.

jeg ser argumentet med at denne løsningen vil være mer omfattende for akkurat behovet signert-dokument, men Difi sitt argument er at dette vil være en mer robust løsning over tid.

[kjorlaug]

Som @aberner er inne på så er tanken at det er meir framtidsretta ved at det gjer det mogleg med "glidande overgang" mellom ustrukturerte format over til meir strukturerte (best illustrert med EHF-formatet) hjå mottakar.

Vi ynskjer ein overgang til meir strukturerte format, derav forventinga om at dette berre er dei to første av ei rekke andre xml-format som må støttast. Forslaget er då ein "laus" kobling mellom dei to filene, slik at vi enklare kan stimulere overgang til standard-format slik som EHF, i stadan for "proprietære" DPI format. Det vil i teorien og bli enklare å integrere inn programvare/fagsystem som allereie genererer slike standard-format.

Er ikkje heilt einig i at dette gjer jobben meir kompleks for deg - xml-elementet må uansett byggast. Det som er spørsmålet er kva skjema du skal bruke, uavhengig av denne så blir brukt til å utvide "Dokument" eller standalone xml-dom.

(Strengt tatt så burde mimetypen inn som text/xml og ein eigen attributt for namnerom/dokumenttype, men det var det ingen som reagerte på :-))

[runeflobakk]

Kort oppsummering dagens møte:

• Enighet om å frikoble "berikende metadata om dokumenter" fra DPI-meldingene.
  • Bruker eksempel fra @kjorlaug i https://github.com/difi/begrep-SikkerDigitalPost/issues/193#issuecomment-277997437 som utgangspunkt
  • Utvider manifest-XSDen i DPI til å støtte vedlegg som er en utvidelse av annet dokument i samme dokumentpakke. Disse vedleggene refererer til filer i dokumentpakken med strukturerte data om dokumentet (typisk PDFen) det er en "utvidelse" av.
• Posten signering definerer en egen XSD som definerer de metadataene som skal sendes med signerte PDFer (PAdES) til mottakers postkasse. Posten signering blir dermed eier av dette formatet, og står for ev. videre utvidelser av dette.
• anses tilstrekkelig å definere en mimetype for å angi formatet på vedlegget med signeringsmetadata.
• metadataene som sendes med signerte dokumenter er å anse som "berikende" i betydningen at postkassene kan selv velge om de vil behandle og ev. tilpasse visning/oppførsel/etc på bakgrunn av disse, men selve dokumentet som blir beriket av metadataene er i seg selv å anse som komplett.

Posten skal komme tilbake med et konkret løsningsforslag som følge av punktene over.

@aberner, @kjorlaug: Gjerne kom med innspill om dette er dekkende for utfallet av dagens møte, om det er noe som bør legges til eller endres.

[kjorlaug]

Ser for det meste greitt ut. Kanskje poengtere at det signerte dokumentet blir sendt som på punkt 1.

Er litt usikker på punkt 2 - det eine er kven som skal eige formatet (Posten signering er vel ikkje ein eigen identitet), men det må og inn i eitt eller anna forvaltningsregime relatert til DPI - kva seier du @aberner ?

[sindrebn]

Hei igjen,

Posten foreslår følgende endringer:

1. Det innføres et frivillig attributt id av typen ID på typen Dokument. Dette kan enten være en vilkårlig string, eller for eksempel filnavnet.
2. Det innføres et frivillig attributt utvider av typen IDREF på typen Dokument. Denne refererer til et annet dokuments id og et dokument kan dermed ha 0 til mange dokumenter som utvider/beriker med metadata.
3. Vedlegget med metadata får mime-type application/vnd.posten.signert-dokument+xml.

Eksempelet du, @kjorlaug, skisserer tidligere i tråden kan derfor bli representert på følgende måte:

<hoveddokument id="ansettelsesavtale" href="ansettelsesavtale.pdf" mime="application/pdf">
    <tittel lang="no">Ansettelsesavtale</tittel>
</hoveddokument>
<vedlegg href="signeringsdata.xml" mime="application/vnd.posten.signert-dokument+xml" utvider="ansettelsesavtale" />

Rasjonalet bak å velge ID- og IDREF-typene er at JAXB (og muligens andre tilsvarende rammeverk) kan konfigureres opp slik at de genererte klassene får felt med «riktig» type (SDPDokument.utvider med tilhørende get- og set-metoder vil være av typen SDPDokument i stedet for String e.l.). Dersom man sender inn et SDPDokument som ikke har fått spesifisert en id, vil JAXB kaste exception ved marshalling. På denne måten får vi validert klientside at manifestet er riktig bygget opp i de klientene som bruker JAXB.

Når det gjelder navngiving av mimetypen tar vi gjerne i mot innspill fra dere. Vi ser for oss at dersom det blir aktuelt å legge til flere slike «metadatadokumenttyper», kan det være greit å ha et fast mønster. Vi er klar over at for EHF er mimetypen bare definert til application/ehf+xml, men det virker hensiktsmessig å namespace mimetypene under vendor-treet (vnd.* som subtype) for å slippe ev. navnekollisjoner med allerede definerte mimetyper – hvis vi på et senere tidspunkt vil/ser oss nødt til å lansere en ny, ikke bakoverkompatibel versjon av en dokumenttypes XSD tror vi det kan være nyttig å ha egendefinerte mimetyper med versjonsnummer i navnet. Vi kan eventuelt legge inn et versjonsnummer allerede nå, slik at det blir application/vnd.posten.signert-dokument-v1+xml e.l.

Hva tenker Difi om dette forslaget?

[sindrebn]

Har dere fått anledning til å se på forslaget over, @kjorlaug @aberner ? :)

[aberner]

@SindreNordbo jeg støtter deres forslag og tenker at vi skal bruke denne samme måten å definere utvidelser på både for #198 og #187

[sindrebn]

Det høres fornuftig ut 👍 Hva blir veien videre her – skal Posten komme med en pull request med de foreslåtte XSD-endringene hvor vi ev. kan diskutere detaljene ytterligere?

[aberner]

@SindreNordbo det er en god idee om dere gjør. Det må så følges opp av produktsjef/kontraktsansvarlig utenfor github.