Open sindrebn opened 7 years ago
Opprettet dette issuet, som avtalt @aberner og @ramung, slik at vi kan komme frem til en løsning som funker bra for alle parter.
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?
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 :)
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 Dokument
et.
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?
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.
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å :-))
Kort oppsummering dagens møte:
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.
Ser for det meste greitt ut. Kanskje poengtere at det signerte dokumentet blir sendt som
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 ?
Hei igjen,
Posten foreslår følgende endringer:
id
av typen ID
på typen Dokument
. Dette kan enten være en vilkårlig string, eller for eksempel filnavnet.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.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?
Har dere fått anledning til å se på forslaget over, @kjorlaug @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
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?
@SindreNordbo det er en god idee om dere gjør. Det må så følges opp av produktsjef/kontraktsansvarlig utenfor github.
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.