introduktion
Jeg deltager i så meget som muligt forarbejde i arbejdet frem mod Næste Generation Digital Post.
Jeg har lige været til Workshop i leverandørforum om NgDP.
Der modelleres stadig rigtigt meget. Meget lidt er skrevet i sten. Så nedenstående er virkelig bare et øjebliksbillede.
Der er tre præ-kvalificerede leverandører (IBM, Netcompany og E-boks), og deres første bud skulle indleveres i dag, den 2/3-2018.
Indledning
Materiale til workshoppen er her: https://www.digitaliser.dk/resource/3921164
Meget fokus på at skabe nytte for virksomheder.
Forsendelse er gratis. Det er staten der betaler. Afsender betaler ikke.
Man overvejer et myndighedsID. Så man kan adressere til CVR, CPR, myndighedsID. Det er nyt at man nedtoner denne. Det skyldes at det er svært at lave.
Man vil bruge Fællesoffentlig brugerrettighedsstyring.
Man vil stadig gerne have mulighed for at der findes 3.parts visningsklienter for post. Svarende til i dag, hvor e-boks.dk har en visningsklient for både e-boks-indhold og Digital Post-indhold.
Hændelseslog på platformen for:
Underskrift (signering) vil være understøttet. Bemærk "understøttet". Det er borger.dk og virk.dk der skal implementere det i brugergrænsefladen - som ligger udenfor udbudet.
Underskrift vil være understøttet gennem Actions.
Piloter udpeges i 2018.
Pilot afvikles i 2019.
MeMo
Markering af sikkerhedsniveau - for at kunne respektere GDPR - kommer nok i formatet. Så sender skal tage stilling.
Der vil være regler for html. Så der ikke kommer noget der ikke er OK - cross-site scripting og den slags.
RDF - det er noget man stærkt regner med at bruge. https://www.w3.org/RDF/
RDF muliggør at man - i selve XMLen der sendes - kan henvise til kilde for autoritative nøgleordslister.
RDF findes der tools til. f.eks. validatorer.
Det er centralt at man ønsker at formatet er self-contained.
Man ønsker ikke at selve Digital post platformen modificerer XML på vej gennem platformen.
Når vi ser på Document-noden i XML
Plads til Dokument-versioner. Både platform - pdf/html/txt, men også sprogvariater.
Så man kan sende samme Dokument i flere varianter i samme forsendelse.
Det er senderens ansvar at dokumentvarianter er ens.
Man ser på at tillade at filer kan være serialiserede i meddelelsen (som i dag - base64), men også at man kan henvise til ressourcer.
Det betyder at man inde i Meddelelsen kan henvise til andre ressourcer i samme meddelelse.
Det betyder også at man kan henvise ressourcer på internettet.
Actions
Hvis man sender Actions med, atså f.eks. kalender-ical eller Signering, så skal man samtidigt sørge for at der er information om det i Dokumentet. Fordi man risikerer at visningsklienten ikke kan vise Actions.
Lige nu kendte typer:
- Kalender-information - ical.
- Signering
- Dybt link
Dybt link skal kunne føre til betalingsløsning (ikke drevet af digitaliseringsstyrelsen) med overførsel af medatadata: pengebeløb,, modtager, tekst.
Trådning og svar og returdata
Dialogtråd som teknologi udgår.
I stedet skal vi se på ReturnData og messageID.
Når man sender en Meddelelse giver man den en messageID.
i ReturnData kan man oprette en returnData-klump som har samme messageId.
Konvention er at når nogen så svarer så skal de sende den samme returnData-klump med tilbage uberørt, og den der nu svarer kan vælge selv at tilføje sin egen returnData-klump med den messageID som svaret har.
Dermed har man mulighed for - i begge ender af kommunikationen - at have egne returdata.
MeMo over SMTP
Stadig meget åbent. Men det tyder på:
Man vil bruge MIME-parts.
MeMo i en selvstændig XML-mimepart
Filer fra MeMo kopieret ud i egne mime-parts. F.eks. en PDF-mimepart og en HTML-mimepart.
Og også at benytte sprog-tags på disse mime-parts, så hvis man sender i flere sprog så kan vise-klienten vælge at tage hensyn til sprog.
Der er nogle problemstillinger her omkring emails størrelse. Og kan man eventuelt henvise fra en PDF-mimepart til den samme PDF i MeMo xml-mimepart'en, så man ikke skal tage plads op to gange for samme fil?