2015-03-03-Endringsanmodning - Alternativ 2 Videresending post_v1_0 Sak:Videresending av post til Innbyggers postkasse via Altinn Fagansvarlig: Morten Græsby. Endringsanmodning Til: Altinn Leverandør Fra: Altinn/Morten Græsby. Dato: 18.03.2015 Endring: Videresending av post til Innbyggers postkasse via Altinn Endringslogg Dato Versjon Beskrivelse Forfatter 03.03.15 0.5 Initiell forespørsel Morten Græsby 18.03.15 1.0 Avklart at kan sendes Leverandør for vurdering (løsningsbeskrivelse) Morten Græsby Problem I forbindelse med Utredning «Vurdering av samspillet mellom Digital postkasse til innbyggere og Altinn» som pågår frem til uke 22, skal man komme frem til et endelig alternativ for samspill mellom de to løsningene. Oppdraget til Utredninger er i hovedsak å vurdere samspillet mellom Digital postkasse til innbyggere og Altinn og muligheten for å inkludere enkelte utsendinger i forbindelse med skattedialogen i Digital postkasse til innbyggere. I den forbindelse er ett av flere alternative løsninger å videresende innbyggerpost fra Altinn til Innbyggers postkasse via den etablerte Meldingsformidler. Altinn må benytte det eksisterende grensesnittformatet som forvaltes av Difi og som benyttes i dagens Meldingsformidler. Side 1 av 5
Figur 1: Altinn videresender Meldinger som Post til innbygger postkasse Forslag til endring Dagens Tjenesteeiere kan fortsatt kunne benytte Altinn for forsendelse av post til innbyggere, men samtidig kunne parameterstyre denne forsendelsen slik at post som skal til innbygger havner i dennes valgte private postkasse ihht Digitaliseringsrundskrivet P-4/2013. Dette kan løses ved å videresende slik post til dagens Meldingsformidler. Altinn må da opptre som rollen Avsendervirksomhet på vegne av Tjenesteeier. Siden Altinn allerede støtter Varsling ihht Eforvaltningsforskriften kan dagens varslingsfunksjonalitet i Altinn gjenbrukes. Altinn har også lokal kopi av Kontakt- og Reservasjonsregister og støtter fullt ut «Regelverk for digital kommunikasjon». Funksjonalitet for å støtte dette er allerede implementert i Altinn og bør gjenbrukes mest mulig. Altinns lokale kopi av Kontakt- og Reservasjonsregister vil også inneholde aktuelle innbygger-sertifikat som skal benyttes i kommunikasjon med Meldingsformidler ihht det gjeldende integrasjonsformat. (Merk at det inntil videre er den valgte Postkasse-leverandør sitt virksomhetssertifikat som ligger lagret pr innbygger i KRR). Tjenesteeier skal derfor kunne benytte de eksisterende integrasjonsgrensesnitt mot Altinn også når meldinger skal videresendes som post til innbygger. Side 2 av 5
Det ønskes altså mest mulig gjenbruk av dagens logikk og grensesnittspesifikasjoner. Følgende Altinn grensesnitt påvirkes for at en Tjenesteeier kan få videresendt meldinger via Altinn som post til innbyggers postkasse: Correspondence Batch: Satsvis overføring Meldinger Correspondence Web Service: Web Service basert metode for overføring av enkeltmeldinger. Herunder også status på meldinger (Created, Read, Confirmed, Reserved). I dag gjelder dette hhv operasjon InsertCorrespondenceV2 og GetCorrespondenceStatusDetailsV2. GetReceipt Evt nye grensesnitt/operasjoner som må implementeres En tjenesteeier i Altinn vil da selv kunne konfigurere hvorvidt en Melding som sendes via Altinn skal videresendes til innbyggers valgte postkasse. Dette kan gjøres ved å parametersette dette i dagens grensesnittformater mellom Altinn og Tjenesteeiere. Følgende må kunne parametersettes av Tjenesteeier i Correspondence Batch og Correspondence Web Service: Om en Melding skal videresendes til innbyggers postkasse Om en Melding skal tilgjengeligjøres i sluttbrukers Meldingsboks i Altinn i tillegg til Innbyggers postkasse Dette vil gi en fleksibel og tjenesteeierstyrt videresending, slik at Tjenesteeierne selv må vurdere ønsket videresending ihht gjeldende forskrifter. I tillegg må dagens Web Service for å innhente status på en sendt melding fra Tjenesteeier via Altinn (GetCorrespondenceStatusDetailsV2) inneholde informasjon om en Melding er videresendt til Innbyggers postkasse. Andre relevante tilbakemeldinger fra postkasseløsningen og dens Meldingsformidler må også kunne returneres til Tjenesteeier via Altinns grensesnitt. Det må vurderes om dette kan implementeres i dagens Altinn Web Service (GetCorrespondenceStatusDetailsV2) eller om det må utvikle en egen operasjon. Det generelle arkitekturbildet for dagens «Digital Postkasse til innbyggere»: http://begrep.difi.no/sikkerdigitalpost/innledning/arkitektur. Altinn skal i dette løsningsforslaget ha rollen «Avsendervirksomhet» og kommunisere med Meldingsformidler. Dette betyr at Altinns virksomhetsertifikat skal benyttes i integrasjon mot Meldingsformidler. Leverandør skal i størst mulig grad basere løsningen på eksisterende kodebibliotek som utvikles og forvaltes av Difi. Denne finnes på https://github.com/difi (sikker-digitalpost-net-klient). Dokumentasjon på Integrasjonsformat mellom «Avsendervirksomhet» og «Meldingsformidler»: http://begrep.difi.no/sikkerdigitalpost/ Sende (ekspedere) post via Altinn fra Tjenesteeier til Digital Post til Innbygger Overordnet beskrivelse hvordan Altinn kan opptre som en videresender av post: Side 3 av 5
1. Meldinger/Post produseres av Tjenesteeier og sendes til Altinn. Angis i Altinns grensesnitt at skal videresendes til Digital Postkasse til Innbygger 2. Mottaker identifiseres med fødselsnummer eller d-nummer og mottakers kontaktinformasjon hentes ved bruk av Altinns kopi av Kontakt- og Reservasjonsregister. Forsendelsen adresseres og kontaktinformasjon legges til på bakgrunn av: a. Reservasjonsstatus b. digital postkasseadresse c. varslingsadresse (epost og mobilnummer). Denne kan avklares mer detaljert senere, siden Altinn kan ivareta denne funksjonaliteten selv. d. sertifikatinformasjon (enten postkasseleverandørens eller postmottakerens sertifikat). Pt er det postkasseleverandørens sertifikat som ligger lagret pr Innbygger i Kontakt-og reservasjonsregisteret. e. Hvis bruker har reservert seg vil dette ivaretas med dagens funksjonalitet i Altinn, der Tjenesteeier får tilbakemelding om dette. Merk: Inntil videre skal altså ikke Altinn i denne endringen implementere integrasjon mot en Utskrift- og forsendelsestjeneste. 3. Posten klargjøres gjennom at Avsender (Altinn): a. tilpasser postforsendelsen til Sikker digital posttjenestens meldingsspesifikasjoner b. signerer postforsendelsen med Avsenders (Altinns) private nøkkel. c. sikrer postforsendelsen mot uautorisert innsyn ved å kryptere posten med sertifikatinformasjon fra Oppslagstjenesten. 4. Postforsendelsen sendes til Meldingsformidleren 5. Ekspedering av post avsluttes ved at utgående post loggføres. Det må logges metadata om en forsendelse slik at man kan utlede statistikk og sporbarhet over hva som videresendt post. Logg skal også kunne bli brukt til mulig fakturering, men dette er ikke avklart i detalj pt. Altinn må kunne ta imot kvitteringer fra Meldingsformidler ihht grensesnittspesifikasjonen. Kvitteringer for mottatt digital post kan være av ulike typer. Figur 2: Kvitteringer Altinn må ta imot og kunne returnere videre til Tjenesteeier kvitteringer og status. I dette løsningsoverslaget bør et minimum av kvitteringer kunne hånderes og formidles tilbake til Tjenesteeier via Altinns (eksisterende) kvittering- og Status tjenester, jfr Figur 2. Kvittering for mottatt digital post til formidlertjenesten Informasjon til avsender om at formidlertjenesten har tatt i mot en digital Side 4 av 5
Kvittering for mottatt digital post til postkassetjenesten Kvittering for åpnet post postforsendelse, og status på forsendelsen Informasjon til avsender og formidlertjenesten om at postkassetjenesten har tatt i mot en digital postforsendelse, og status på forsendelsen. Informasjon til avsender om at mottaker av post har åpnet denne. Det er ikke gitt at mottaker kan lese posten 6. Tjenesteeier vil kunne få tilbakemelding fra Altinn i en utvidelse av dagens kvittering- og Status tjenester (GetCorrespondenceStatusDetailsV2, GetReceipt) Krav Kravene kan utledes utifra behovsbeskrivelsen, men vil bli detaljert etter at leverandør har gjort et kostnadsoverslag. Kravene er foreløpig basert på behovet for kostnadsoverslag, og at Leverandør gjør seg kjent med detaljene i integrasjonsformat som gjelder for Meldingsformidler samt en vurdering av gjenbruksnivå av det ferdige kodebibliotek. Tabellen nedenfor angir krav som skal dekkes av denne endringsanmodningen: Krav-ID Område Krav 1 2 3 4 5 6 7 8 9 10 11 12 13 Andre innspill Risiko Ingen identifiserte. Side 5 av 5