Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Digdir/Altinn som uavhengig tredjepart knyttet til signering #777

Open
RonnyB71 opened this issue Sep 17, 2024 · 1 comment
Open

Digdir/Altinn som uavhengig tredjepart knyttet til signering #777

RonnyB71 opened this issue Sep 17, 2024 · 1 comment

Comments

@RonnyB71
Copy link
Member

RonnyB71 commented Sep 17, 2024

Description

Dagens signeringsløsning i Altinn 3 legger opp til partene involvert i signering (TE og signerer) begge sitter på kopi av dataene inkl. signaturen. Ved en evt. uenighet vil man måtte se på data på begge sider, inkludert signatur objekter, og sammenligne for å se hvor evt. avvik fra originalen har skjedd.

Digdir har kun data så lenge den som har opprettet instansen velger å ikke slette dataene. Den som eier instansen kan velge å slette data, inkl. signatur, etter at TE har kvittert ut for å ha hentet alle data. At den som har opprettet instansen kan velge å slette sine data skyldes praksisen med at det som presenteres i Altinn Innboks sees på som sluttbrukers arkiv og under deres kontroll. Logger som dokumenterer signaturhandlingen vil arkiveres i 13 måneder før de slettes på Digdir sin side. Avhengig av regelverket kan det være aktuelt med opp mot 10 års arkivering. Dette er knyttet opp mot den enkelte TE og den enkelte tjeneste.

For lettere å kunne avgjøre hvem som har rett i en evt. tvist er det ønskelig at Digdir/Altinn står som en uavhengig tredjepart og beholder data og logger så lenge det er nødvendig. Dette tilsvarer TTP (Trusted Third Party) funksjonaliteten som fantes på Altinn 2.

Additional Information

Dette krever også at diskusjonen om skjemaer skal være en del av sluttbrukers arkiv og hvordan evt. tjenesteeier skal kunne bestemme over disse dataene.

@kimbjornjensen
Copy link

Bare for å utdype behovet litt. Det vanlige tilfellet av TE som har en Altinn3-tjeneste er vel at TE selv er bruker av tjenesten som mottakende part og skal saksbehandle en henvendelse.
For DiBK og Fellestjenester Bygg og Plan (FtB/FtP) er tjenesten en annen. DiBK bruker ikke informasjonen, som sendes gjennom FtB/FtP-tjenestene, til egen saksbehandling. FtB/FtP er som en "hub", der private aktører, på den ene siden, sender byggesøknad/planvarsel til validering, formidling til saksbehandlende myndighet, typisk en kommune, og/eller distribusjon til berørte parter, som kan være høringsparter, naboer o.likn.
Til FtB/FtP trenger vi en signaturløsning, som dokumenterer at en sluttbruker har gjennomført en aktivitet som har ført til formidling/distribusjon av en søknad/et varsel. Både søknader og varsler kan bestå av flere dokumenter av forskjellig type. Det å kunne få et signeringsobjekt, med en hash, som dekker alle data, også vedleggsdokumenter, er derfor nyttig. For å være trygg på, å kunne verifisere, at det som ble sendt inn gjennom TE's løsning i Altinn3, er det som har blitt formidlet/distribuert og blir brukt som saksbehandlingsgrunnlag, er det viktig å kunne kontrollere signeringsobjektet, som kommer sammen med dokumentene til saksbehandling, mot det som ble generert i Altinn3-prosessen. Siden både plan- og byggesaker kan leve lenge er det viktig at verifikasjonsmuligheten eksisterer like lenge. Og derfor trenger FtB/FtP-tjenestene også å ha Altinn som TTP.
I tillegg er det et grunnleggende prinsipp for FtB/FtP at "hub'en" ikke har persistente data, utover det som kreves for den aktuelle transaksjonsbehandlingen og evt feilretting, i egen tjeneste eller hos IT-løsningsleverandører opp- eller nedstrøms i verdikjeden.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: No status
Development

No branches or pull requests

2 participants