FESD Sikker epostløsning

Størrelse: px
Starte visningen fra side:

Download "FESD Sikker epostløsning"

Transkript

1 FESD Sikker epostløsning Standard IT- og Telestyrelsen København den 11. december FESD-standardisering Sikker epostløsning. Grænsesnit. Version 1.1

2 Kolofon: FESD-standardisering. Sikker epostløsning. Grænsesnit. Version 1.1 Denne standard kan frit anvendes af alle. Citeres der fra standarden i andre publikationer til offentligheden, skal der angives korrekt kildehenvisning. Forslag til FESD-standarder udarbejdes af IT- og Telestyrelsen, Kontoret for standardiserings- og arkitekturpolitik, FESD-standardiseringsgruppen i samarbejde med de tre FESD-leverandører Software Innovation A/S, Traen Informationssystemer A/S og CSC Danmark A/S. Kontaktperson i FESD-standardisering: Projektleder Rita Lützhøft, Mail-adresse Telefon (direkte) Traen Informationssystemer A/S Vesterbrogade 95 A 1620 København K Telefon: Web-adresse: CSC Danmark A/S Retortvej København V Telefon: Web-adresse: Software Innovation A/S Nærum Hovedgade Nærum Telefon: Web-adresse: Ministeriet for Videnskab, Teknologi og Udvikling IT- og Telestyrelsen Kontoret for standardiserings- og arkitekturpolitik Holsteinsgade 63 DK-2100 København Ø Telefon: Fax / 33

3 Indholdsfortegnelse 1 Forord Teknisk forord DEL A Indledning Formål Grænseflader og afgrænsninger edag Baggrund Formålet edag2 og digital signatur Signering og kryptering i relation til ESDH-systemer Anvendelse af medarbejdersignatur avanceret Baggrund for medarbejdersignatur avanceret Funktion Noark Afgrænsninger S/MIME Registrering af afsender- og modtageroplysninger Sikkerhed Bevisværdi Eksterne parter Beskyttelse af fortrolige oplysninger DEL B Infrastruktur i organisationen Brugsscenarier Modtagelse af epost i organisationen Case Løsningsscenarie Afsendelse af epost Case Løsningsscenarie DEL C Logisk model / 33

4 4.1.1 Epost Message Signaturbevis Generelt for ind- og udgående signaturbevis Specifikt for indgående signaturbevis Specifikt for udgående signaturbevis Epost headere for udgående epost Udvidelse af FESD-datamodel Anvendte typer i FESD-modellerne / 33

5 1 Forord Den offentlige sektors IT-systemer på statsligt, kommunalt og regionalt niveau skal kunne spille sikkert og effektivt sammen. Derfor arbejdes der målrettet på at få gennemført fælles standarder for elektronisk sagsog dokumenthåndtering - den såkaldte FESD-standard. Målet med standardiseringsarbejdet er at fremme digital forvaltning i den offentlige sektor, og midlet er at sikre, at de forskellige elektroniske sags- og dokumenthåndteringssystemer (ESDH) får en fælles kernefunktionalitet, og at det samtidig sikres, at denne kerne videreudvikles ensartet. En fælles kernefunktionalitet skal sikre: at der kan foretages sagsbehandling på tværs af flere organisationer at myndigheder, der arbejder med åbne sager, kan lægges sammen at der kan flyttes opgaver mellem forskellige myndigheder I forlængelse af FESD-projektkonkurrencen, som havde sin afslutning primo 2004, og hvor der blev fundet tre FESD-leverandører, blev det i forbindelse med kontraktforhandlingerne besluttet at starte en standardiseringsproces den såkaldte FESD-standardisering. For at sikre interoperabiliteten, både til andre systemer, men også så tredjepart kan udvikle moduler til systemet, blev det anset for afgørende, at der udvikles en fælles offentlig datamodel samt andre standarder på ESDH-området. Koordinering af FESD-standardiseringen er efterfølgende lagt i IT- og Telestyrelsen (ITST). Den konkrete udarbejdelse af forslag/udkast til standarder foregår i et samarbejde mellem de tre FESD-leverandører og en FESD-standardiseringsgruppe i ITST. Arbejdet med forslag/udkast til standarder tager udgangspunkt i Noark 4 s datamodel og databeskrivelser samt leverandørernes løsninger. Standarderne kan afvige fra Noark 4 på de områder, hvor det er nødvendigt for at understøtte dansk forvaltningspraksis, eller hvor parterne i FESD-standardiseringen kan opnå enighed om en afvigelse. Udkast/forslag sendes herefter i offentlig høring i ca. 1 måned. FESD-standardiseringsgruppen tilretter og færdiggør på baggrund af høringen de endelige Forslag til standarder. Standardforslagene forelægges herefter OIO-komiteen til godkendelse. Efter den samlede godkendelse bliver standarderne således offentliggjort og indgår i IT- og Telestyrelsens OIO-Katalog (digitaliser.dk), som indeholder en oversigt over godkendte og anbefalede standarder til digital forvaltning i det offentlige. I standarden kan forekomme brug af særligt ordvalg. Følgende termer anvendes konsekvent i den følgende betydning: skal / obligatorisk : betyder, at den nævnte metode/element/mulighed/etc. skal benyttes eller skal forefindes dvs. må ikke udelades. må ikke : betyder, at den nævnte metode/element/mulighed/etc. ikke må forefindes eller må ikke benyttes. bør / anbefalet : betyder, at det i høj grad anbefales, at den nævnte metode/element/mulighed/etc. benyttes eller forefindes. Der skal være tungtvejende grunde til at udelade. kan / optionel : betyder, at den nævnte metode/element/mulighed/etc. er en valgmulighed og derfor valgfri at medtage. 5 / 33

6 Denne udgave af standarden er såkaldt konsolideret i forhold til version 1.0. På grund af den måde FESDstandardiseringsarbejdet er tilrettelagt på forskellige afleveringer på forskellige tidspunkter siden 2004 udkommer FESD-datamodellen som deldatamodeller. Det har betydet, at enkelte detaljer i det forventede slutresultat altså den samlede FESD-datamodel kan være overset. Det har endvidere været nødvendigt at konsekvenstilføje noget, der tidligere er sprunget over fx på grund af manglende standardisering på det tidspunkt, den aktuelle standard blev udarbejdet. Endvidere har NDR (Name and Design Rules) reglerne givet anledning til en del ændringer i sprogbrug (semantik) vedrørende attributter af hensyn til efterfølgende generering af XML Den samlede FESD-datamodel (i form af deldatamodellerne) til og med 2008 er derfor gennemgået og genvurderet i forbindelse med denne standard. Denne genvurdering har ikke medført forretningsmæssige radikale ændringer i deldatamodellen, men har dog givet anledning til en del justeringer, typisk af præsentationsmæssig (semantik) karakter, især pga. NDR-reglerne. 1.1 Teknisk forord Grundlaget for FESD-datamodellen er blevet udarbejdet på en periode på mere end fire år, hvor der er udarbejdet standarder for de forskellige delområder. Arbejdsmetoder, terminologi og anvendelse af datatyper har ændret sig i denne periode FESD-standardiseringsgruppen har f.eks. indført en konsekvent brug af UMLnotation i de senere standarder. Konsolideringen af datamodellen har derfor forudsat, at der blev defineret en fælles modelleringsmetode og et sæt af primitive datatyper, der var kompatibelt med alle del-datamodellerne. De primitive datatyper, som modellen er opbygget af, fremgår af kapitel 5. 6 / 33

7 2 DEL A 2.1 Indledning Det er besluttet, at som et led i FESD-standardiseringsarbejdet, skal der gennemføres en standardisering vedrørende digitale signaturer, der dækker den anvendelse, der i dag finder sted i det offentlige. I standardiseringsarbejdet har der været en dialog med en gruppe sikker epost leverandører på markedet og IT- og Telestyrelsens IT-sikkerhedskontor. Alle klasse- og attributreferencer i diagrammerne i denne standard er på engelsk. Den danske reference kan findes i tabellerne i Del C (attribut dan., klasse dan.). Det danske attributnavn er en oversættelse af det tilsvarende engelske attributnavn. 2.2 Formål Denne standard omhandler integration af sikker epostløsninger med ESDH-systemer med det formål at understøtte udveksling af sikker epost mellem en organisation og dens eksterne parter. Sikker epostløsninger også kaldet Mail sweepere eller Mail gateways er løsninger, der håndterer en organisations fælles certifikater og sørger for kommunikation med certifikater. I en udvekslingssituation er det sikker epostløsningens rolle at håndtere signering og kryptering i forhold til virksomhedscertifikater og at validere informationer omkring forsendelsen. ESDH-systemets rolle i relation til en brevudveksling er først og fremmest at være arkiv for de dokumenter og informationer, der udveksles, og dernæst at være en sikker container for oplysningerne omkring forsendelsen. Der er derfor allerede lavet en række løsninger, hvor sikre epostløsninger er integreret med ESDH-systemet, i den forbindelse er der aftalt sikkerhedsprocedurer og den tekniske integration for løsningerne individuelt for hver implementering. Det, at der ikke findes nogen standard for eller vejledning i, hvordan denne type af integrationer skal laves, betyder en væsentlig fordyrelse af den enkelte integration. Både ESDH-leverandøren og leverandøren af sikker epostløsningen skal lave specialtilpasninger og det er typisk myndigheden selv, der har ansvaret for, at løsningen som helhed fungerer. Derudover er der en risiko for, at den integration, der aftales lokalt, ikke er sikkerhedsmæssigt i orden, således at myndigheden står svagt, hvis der skal føres bevis for, at en konkret epost kommunikation har fundet sted. 2.3 Grænseflader og afgrænsninger Den her beskrevne standard er afgrænset til epost og har ikke fokus på andre anvendelser af certifikater til sikker kommunikation, der evt. skal dokumenteres i ESDH-systemer. Standarden kan på et senere tidspunkt udvides til at omhandle andre anvendelser af certifikater til sikring af levering af meddelelser eller dokumenter til eller fra ESDH-systemer, så den eksempelvis kunne udvides til at dække, hvordan et Content Management system afleverer en signeret blanket til et ESDH-system. Epost kommunikation mellem organisationer er også temaet for standarden vedrørende FESDudvekslingspakke trin 1, der er en protokol til udveksling af dokumenter mellem ESDH-systemer via epost. Standarden vedrørende FESD-udvekslingspakke beskæftiger sig i trin 1 ikke med sikkerhed eller autenticitet (kryptering eller signering) ved udvekslingen, men beskæftiger sig med hvordan en epost opbygges af dokumenter, der skal udveksles, og hvordan metadata beskrives i en vedhæftet efølgeseddel i dokformformat. Den her beskrevne standard er komplementær til standarden vedrørende FESD-udvekslingspakken trin 1 - idet det er forskellige aspekter af en forsendelse de to standarder beskæftiger sig med. 7 / 33

8 Der er planlagt et trin 2 til standarden FESD-udvekslingspakken, som sigter på at beskrive en udvekslingspakke udelukkende i XML-format uden epost-indpakningen af dokumenter og følgeseddel. Trin 2 kan evt. også indeholde muligheden for at signere eller kryptere dele af udvekslingspakken. Det kan derfor være, at Trin 2 vil være funktionelt overlappende i forhold til denne standard, idet der tilbydes en anden måde at kommunikere sikkert mellem to organisationer med ESDH-systemer edag2 Den 1. februar 2005 var det edag2. Med edag2 har alle myndigheder forpligtet sig til at have en officiel sikker epost adresse, der som noget nyt muliggør sikker og fortrolig epost kommunikation med den offentlige sektor. Efter den dato har alle offentlige myndigheder i stat, amt og kommune som udgangspunkt ret til at sende breve og dokumenter med følsomme og fortrolige oplysninger fuldt elektronisk til andre myndigheder og droppe papirversionen. Tilsvarende har de også ret til at kræve, at andre myndigheder sender fuldt elektronisk til dem. Endvidere har borgere og virksomheder efter denne dato ret til at sende sikker epost til det offentlige Baggrund edag2 er en fortsættelse af edag. Den første edag gav myndighederne ret og pligt til at kommunikere digitalt, men undtog dokumenter med følsomme og fortrolige oplysninger, idet disse ikke måtte sendes over det åbne Internet, med mindre de var krypteret. Det var et ufravigeligt krav til offentlige myndigheder for så vidt angår personoplysninger. Endvidere var kommunikation med borgere og virksomheder ikke omfattet af den første edag. Såvel edag som edag2 var aftalt mellem Regeringen, KL, Amtsrådsforeningen, Københavns Kommune og Frederiksberg Kommune efter anbefaling fra Den Digitale Taskforce. De involverede parter havde aftalt datoen for edag2 og det nærmere omfang af rettigheder og pligter. edag2-initiativet var endvidere forankret i regeringens moderniseringsprogram og i strategien for Digital Forvaltning Formålet Formålet med edag2 var at skabe en mere effektiv offentlig sektor gennem optimal udnyttelse af digitale værktøjer. edag2 ville medføre, at en stor del af det offentliges brevpost kunne omlægges til fuldt digitale arbejdsgange, og dermed spare ressourcer til posthåndtering, scanning, kopiering og porto samt give en hurtigere sagsbehandlingstid edag2 og digital signatur Videnskabsministeriet udarbejdede i forbindelse med edag2 aftalen i samarbejde med Den Digitale Taskforce, KL og Amtsrådsforeningen en række minimumskrav til sikker epost løsninger, som blev anbefalet til alle, der skulle implementere edag2. Minimumskravene blev udarbejdet med udgangspunkt i konsulentfirmaet Devoteam Fischer & Lorenzes vejledning om implementering af digital signatur i kommunerne og med deltagelse af bl.a. Kommunernes Revision (KR). Et væsentligt krav til myndighederne i forbindelse med edag2 var, at de kunne sende sikker epost til og modtage svar på samme vis fra borgere, virksomheder og andre myndigheder. Sikker epost har til formål at håndtere følgende tre sikkerhedselementer i forbindelse med digital kommunikation: Autenticitet, der giver modtageren af en meddelelse garanti for, at den kommer fra den person, som påstår at have sendt den Integritet, der giver sikkerhed for, at en modtaget meddelelse er identisk med den meddelelse, som afsenderen sendte Fortrolighed, der giver sikkerhed for, at uvedkommende ikke kan få kendskab til meddelelsens indhold 8 / 33

9 I praksis tilgodeses disse sikkerhedselementer ved, at afsenderen signerer eposten med sit eget digitale certifikat (dette sikrer autenticiteten og integriteten af eposten) og krypterer eposten med den offentlige del af modtagerens digitale certifikat (dette sikrer fortroligheden). For at kunne signere og kryptere en epost kræves altså en digital signatur hos både afsender og modtager. Der vil ikke altid være behov for både at signere og kryptere eposten, men for at leve op til edag2 skulle sikker epostløsningen kunne håndtere begge dele. edag2 baserede sikker epost på det offentliges standard for digital signatur, den såkaldte OCES standard, hvor OCES er en forkortelse for Offentlige Certifikater til Elektronisk Service. Udstedelse, indhold, håndtering og anvendelse af OCES certifikater er beskrevet i OCES certifikatpolitikkerne, som kan læses og downloades på En detaljeret beskrivelse af edag2 minimumskravene kan findes på Signering og kryptering i relation til ESDH-systemer Teknologien og infrastrukturen der knytter sig til certifikater, kan anvendes til at sikre autenticitet, integritet og fortrolighed i forbindelse med forsendelsen af meddelelsen. Når meddelelsen først er nået frem til modtageren og er lagret i et ESDH-system, er informationerne underkastet ESDH-systemets sikkerhedssystem og dermed sikret både mht. autenticitet, integritet og adgangsbeskyttelse. De tekniske elementer, der indgår i beviset for fremsendelsen det vil f.eks. sige: Certifikatet der er brugt til at signere med Signaturen der er tilknyttet eposten Spærrelisten der er brugt til at verificere, at afsenderens certifikat var validt på modtagelsestidspunktet er kun interessante på modtagelsestidspunktet herefter er deres validitet ikke af betydning. Derfor er det vedtagne udgangspunkt for dette standardiseringsarbejde, at når en forsendelse er modtaget eller afsendt fra en organisation og lagret i ESDH-systemet, er det kun informationer om sikkerhed og autenticitet, der er anvendt og indhentet ved forsendelsen, der lagres i ESDH-systemet - og ikke selve de tekniske elementer, der indgår i beviset Anvendelse af medarbejdersignatur avanceret Med anvendelse af medarbejdersignatur avanceret bliver det ikke længere nødvendigt, at løsninger kan håndtere krypteret epost, der sendes direkte til personlige postkasser i en organisation. Det forudsættes i standardiseringsarbejdet, at der kun anvendes medarbejdersignatur avanceret i de organisationer, der ønsker at implementere integrationen mellem sikker epostløsningen og ESDH-systemet Baggrund for medarbejdersignatur avanceret Modtagelse og afsendelse af sikker epost med kryptering har typisk været en udfordring for virksomheder, som har centrale løsninger til kontrol af epost for virus og spam. Samtidig har krypteret epost, sendt direkte til medarbejdere, også kunnet give problemer i forhold til tilgængelighed af data for andre medarbejdere. Problemet med krypteret epost til en given medarbejder har hidtil været løst ved, at afsenderen udenfor organisationen skulle sende epost adresseret til den enkelte medarbejder og Cc: til en central indholdsscanner (fælles postkasse) med efterfølgende manuel postdistribution internt. Disse løsninger har forskellige anvendelsesmæssige svagheder. For at undgå ovenstående svagheder er der etableret en ny form for medarbejdercertifikater kaldet for medarbejdersignatur avanceret Funktion Virksomheden har mulighed for at bestille medarbejdersignatur avanceret igennem virksomhedens LRA enhed (Lokal Registrerings Autoritet er den autoritet i en virksomhed, der administrerer virksomhedens interne certifikater). For at kunne udstede medarbejdersignatur avanceret skal der i forvejen være adgang til 9 / 33

10 et virksomhedscertifikat. Når virksomhedens LRA opretter en medarbejder med medarbejdersignatur avanceret, vil der genereres to certifikater med hver sit nøglepar. Det ene er et certifikat, der kan anvendes til at logge sig på systemer og generere digital signatur på epost, men det kan ikke anvendes til kryptering. Dette certifikat placeres lokalt sammen med den tilhørende private nøgle hos den enkelte medarbejder på dennes PC som en standard software signatur eller i en HW-token (USB eller smartcard). Det andet certifikat udstedes, så det udelukkende kan anvendes til kryptering og ikke til signering. Dette certifikat placeres centralt i organisationen sammen med den tilhørende private nøgle uden for den enkelte medarbejders kontrol. Da disse "kolde" krypteringscertifikater (og især de tilhørende private nøgler) således ikke kommer til medarbejdernes kendskab, anvendes samme nøgle til alle medarbejdere. Krypteringscertifikaterne placeres i et offentligt tilgængelig directory. Når en person udenfor virksomheden vil sende direkte til en medarbejder, fremsøges medarbejderens krypteringscertifikat som vanligt, eposten krypteres direkte til medarbejderen, og eposten afsendes. Når den krypterede epost modtages af virksomhedens centrale epostapplikation (som har adgang til den private RSA nøgle til dekryptering), dekrypteres eposten, inden den sendes ukrypteret videre internt i virksomheden. Når en medarbejder ønsker at sende til en person udenfor virksomheden, kan signering påsættes lokalt, og kryptering kan foretages centralt. Spærring og fornyelse håndteres parallelt med signeringscertifikater i stil med, hvordan det håndteres i øvrige to-nøglepar løsninger Noark FESD-standardisering har normalt Noark 4 standarden som udgangspunkt På området vedrørende digital signatur, har Noark et andet udgangspunkt end denne standard. Det har derfor ikke været muligt at anvende Noark som grundlag for denne standard. Noark opererer ikke med en opdeling mellem et ESDH-system og en sikker epostløsning, og de grænseflader, der er i en sådan løsning. Noark arbejder i stedet med en model, hvor ESDH-systemet lagrer signaturer i ESDH-systemets database. I Noarks datamodel er der defineret en tabel DIGISIGN digitale signaturer. Denne tabel bliver ikke inkluderet i FESD-datamodellen, men erstattes af de datamodelsudvidelser, der defineres som følge af denne standard Afgrænsninger S/MIME Denne standard vedrører kun håndtering af S/MIM Registrering af afsender- og modtageroplysninger. Standarden forholder sig ikke til selve dokumentregistreringen i ESDH-systemet. Der tilvejebringes en række informationer, som kan benyttes i forbindelse med registreringen, men myndigheden vil fortsat skulle sikre en forsvarlig registrering af dokumenter, herunder at på- og/eller tilføre de almindelige afsender- /modtageroplysninger. 2.4 Sikkerhed I forbindelse med udarbejdelsen af denne standard har der været stor fokus på at finde det rigtige niveau for sikkerheden i de løsninger, der bygger på standarden. Sikkerheden har specielt været koncentreret om 3 områder: 1. Bevisværdi hvis en myndighed har implementeret standarden, skal det sikre bevisværdien i forbindelse med myndighedens epost kommunikation. 10 / 33

11 2. Eksterne parter: Som følge af pkt. 1 skal det kunne godtgøres, at ingen uden for myndigheden har en teoretisk mulighed for at registrere epost i ESDH-systemet med falske autenticitets informationer. 3. Oplysninger, der er fortrolige, skal være beskyttet også mod, at en medarbejder uforvarende kommer til at videregive dem Bevisværdi ESDH-systemet har traditionelt set ikke nogen rolle i en epost/brevudveksling, idet ESDH-systemets primære rolle har bestået i at være lager for indholdet af den kommunikation - og dernæst oplysningerne omkring kommunikationen. Når det gælder udveksling af dokumenter mellem offentlige myndigheder ved hjælp af ikke elektronisk post, indeholder ESDH-systemet typisk brevet eller rettere en indskannet kopi af brevet. Hvis der opstår tvist om, hvorvidt en myndighed har modtaget et brev fra en modtager, vil myndigheden i ESDH-systemet kunne dokumentere modtagelsen ved at kunne producere en kopi af brevet (evt. med en håndskrevet underskift) og de hertil knyttede metadata, såsom modtagelsestidspunkt og identifikation af hvem, der har foretaget skanningen og registreringen af brevet. Bevisværdien opnås ved at underbygge denne dokumentation med de itsikkerhedsmæssige procedurer i organisationen og vil i en tvist kunne sandsynliggøre, hvilken kommunikation, der har fundet sted. Sikkerheden, når det gælder bevislighed af epost kommunikation, skal som minimum være på højde med den, der gælder for den øvrige brevudveksling. Dvs. at der skal registreres oplysninger i ESDH-systemet, der kan sandsynliggøre hvilken kommunikation, der har fundet sted, men bevisværdien vil altid tillige være baseret på myndighedens it-sikkerhedsmæssige procedurer og dokumentationen for, at disse bliver overholdt Eksterne parter Det må ikke kunne lade sig gøre, at en part uden for organisationen kan fremsende epost, der bliver registreret i ESDH-systemet, som om de var troværdige uden at være det. Løsningen bygger på, at oplysningerne fra certifikaterne bliver ekstraheret og registreret som metadata i ESDH-systemet. Standarden skal sikre, at en ekstern part, der kender myndighedens opsætning og kender de interne dataformater for udveksling i løsningen, ikke kan levere data, der bliver registreret med en falsk autenticitet i ESDH-systemet Beskyttelse af fortrolige oplysninger Håndtering af smime-epost involverer kryptering og dekryptering af informationer der under fremsendelsen er beskyttet mod, at udenforstående kan se dem. De grænseflader, der er mellem sikker epostløsningen, må ikke kompromittere denne sikkerhed. 11 / 33

12 3 DEL B 3.1 Infrastruktur i organisationen ESDH-systemer kan have funktionalitet indbygget til at håndtere sikker epost, men det er ikke ESDHsystemets opgave at håndtere al epost, der sendes til eller fra organisationen. Forretningslogikken vedrørende styring af certifikater, opslag i spærrelister mv. er ikke en naturlig del af ESDH-systemet, men en del af organisations mere basale infrastruktur og skal derfor ikke være en del af organisationens ESDH-løsning. Infrastruktur - overblik Internet S/MIME Gateway Mail Server CA ESDH System Sagsarkiv Pers. mailbox Org. mailbox Mail Client Mail Client Figur 1: Overblik over infrastruktur Figur 1 viser forudsætningerne for infrastrukturen i organisationen. Det forudsættes, at der er en sikker epostløsning, der implementerer en S/MIME-Gateway. S/MIME Gateway en har ansvaret for at modtage og afsende S/MIME mails, således at den fysiske kryptering og signering fjernes fra mails, inden de kommer ind i organisationen det er illustreret med skaldespanden øverst. De løsninger, der findes på markedet i dag, er meget forskellige, hvad angår deres integration til organisationens øvrige epost servere. Nogle gateway s er selvstændige servere, der har en klar grænseflade til en epost server, mens andre er en udbygning af epost serverens funktionalitet. Standarden antager ikke noget om, hvordan grænsefladen mellem epost serveren og gatewayen er, men antager blot, at det samlede epostsystems funktionalitet er udvidet med S/MIME håndtering. Indgående epost kan enten være direkte til sagsbehandlere eller til virksomhedens generelle epostkasse. Arbejdet med epost sker via epostklienter, og der vil typisk være en hel del epost, der ikke skal registreres i ESDH-systemet. Standarden tager derfor udgangspunkt i, at der i organisationen findes en sikker epostløsning, og at der er et tillidsforhold mellem sikker epostløsningen og ESDH-systemet, således at: 12 / 33

13 Epost, der er verificeret af sikker epostløsningen, ikke behøver at blive genverificeret af ESDHsystemet ESDH-systemet kan bestille sikker epostløsningen til at signere udgående epost ved at anvende f.eks. virksomheds-certifikater 3.2 Brugsscenarier De brugsscenarier, standarden fokuserer på, er dem, der udspringer af sikker epost kommunikation mellem en medarbejder i en organisation og en for organisationen ekstern part. Den eksterne part kan i princippet være medarbejder i en anden organisation, men fokus er ikke på epost udveksling mellem to organisationer. Standarden håndterer således ikke scenarier med epost krypteret i en End-to-End S/MIME løsning, hvor modtageren selv har dekrypteringsnøglen, og hvor epost således ikke dekrypteres af S/MIME gateway en. Epost kommunikationen vil typisk være initieret af den eksterne part f.eks. i en situation, hvor en borger henvender sig til en myndighed for at ansøge om en tilladelse, et tilskud eller lignende men kommunikationen kan også være initialiseret af en medarbejder i organisationen, som f.eks. ved en nabohøring. I de næste afsnit beskrives, hvordan ind- og udgående epost kommunikation skal håndteres generelt i del C beskrives den konkrete informationsarkitektur og krav til henholdsvis ESDH og sikker epostløsning Modtagelse af epost i organisationen Case Den eksterne part har enten kendskab til epostadressen (og certifikat) på organisationens generelle epostkasse eller har kendskab til en konkret medarbejders epostadresse (og certifikat), således at parten kan danne en epost, der er krypteret og/eller signeret og fremsende den til epostadressen. I organisationen modtages eposten enten direkte af en medarbejder eller i den centrale epostkasse og viderefordeles til en medarbejder, der skal behandle eposten. Indholdet af eposten registreres herefter i ESDHsystemet sammen med oplysninger om kommunikationen. Medarbejderen kan så initiere en ny eller fortsætte en igangværende sagsbehandling på baggrund af indholdet. 13 / 33

14 Løsningsscenarie Modtagelse af epost Internet Internet S/MIME S/MIME Gateway Gateway Mail Mail Server Server CA CA ESDH ESDH System System Sagsarkiv Pers. mailbox Org. mailbox Mail Mail Client Client Mail Mail Client Client ESDH SAF STAGING Figur 2: Modtagelse af epost Figur 2 viser, hvordan en epost bliver modtaget i organisationen. Første led er S/MIME Gatewayen (1) (sikker epostløsningen), der opfattes som en udvidelse af epost serverens funktionalitet. Gateway en behandler indgående epost, der er S/MIME encoded dvs. epost, der er krypteret, signeret eller begge dele. Gateway en behandler S/MIM s ved at verificere, at de er korrekte. Dvs. at en vedhæftet signatur er relateret til indholdet af eposten, og at certifikater, der er anvendt, er valide, og der indhentes evt. ekstra oplysninger om indehaveren. Gateway en danner et indgående signaturbevis, der indeholder oplysninger om signatur, certifikat og certifikatholderen samt nogle forsendelsesoplysninger. Det indgående signaturbevis er nærmere beskrevet i Del C. Gateway en fjerner det certifikat, der er påført eposten ved modtagelsen, og dekrypterer eposten, såfremt den er krypteret med virksomhedscertifikatets nøgle. Hvis eposten er krypteret med en anden nøgle, kan gateway en ikke behandle eposten, og opfatter dette som en fejlsituation (hvis virksomheden anvender medarbejdersignatur avanceret, vil det være virksomhedscertifikatets offentlige krypteringsnøgle, der ligger i de enkelte medarbejdercertifikater, og dermed vil det være muligt for gateway en at dekryptere en mail, der er krypteret til en specifik medarbejder). Gateway en danner endvidere en ny unik id i form af en UUID, der tilføjes epostens mailheader. Gateway en videresender to kopier af eposten: 1. Direkte til modtageren (2). Hvad enten det er en personlig epostkasse (2-1) eller en virksomhedsepostkasse (2-2), fremsendes en kopi af eposten direkte. Denne kopi af mailen skal behandles af brugeren i den mailklient, som brugeren anvender. Gatewayen kan derfor ikke stille specielle krav til mailklienten 14 / 33

15 2. Til ESDH-systemets postkasse (3) fremsendes en kopi af eposten, der har vedhæftet det dannede signaturbevis. De to eposter knyttes til hinanden ved hjælp af nogle ekstra metadata, der tilføjes til MIME-headeren, der indeholder den unikke ID, gateway en har tildelt. Modtagelse af eposten (4) sker i modtagerens indbakke hvad enten modtageren er en medarbejder eller en virksomhedspostkasse. Den version af eposten, der ses i mailklienten, er ikke tilknyttet et signaturbevis, og brugeren kan altså frit besvare eller videresende denne epost uden at skulle fjerne et tilknyttet signaturbevis. Dermed er risikoen for, at brugeren uforvarende kommer til at videresende et signaturbevis med afsenderens CPR-nummer, minimeret. ESDH-systemets postkasse (ESDH Saf staging på figur 2) er en særlig postkasse (3), der er oprettet til integrationen. Denne postkasse skal opsættes, så kun MailGateway en og ESDH-systemet har adgang til den. Denne sikkerhedsopsætning er central for sikkerheden i løsningen, idet den sikrer, at der ikke kan lagres forvanskede data i ESDH-systemet. Hvordan denne opsætning skal foretages, afhænger af sikker epostløsningen og ESDH-systemet. ESDH-systemets funktionalitet omfatter en integration med postklienten, der giver mulighed for at arkivere epost i ESDH-systemet. Når epost gemmes i ESDH-systemet (5), undersøger logikken, om der eksisterer en kopi af eposten i saf staging postkassen. Hvis der findes en sådan kopi, er det denne (og ikke eposten i brugerens indbakke), der arkiveres i ESDH-systemet. Når eposten gemmes i ESDH-systemet, er det i form af en journalpost med tilknyttede dokumenter. Journalposten tilknyttes endvidere et signaturbevis, der er en tabel i ESDH-systemets datamodel (en udvidelse til FESD-datamodellen). Denne funktionalitet kan være implementeret på forskellig vis i de forskellige ESDH-systemer og epostklienter Afsendelse af epost Case Medarbejderen har i forbindelse med en sagsbehandling behov for kommunikation med en ekstern part. Medarbejderen kender eller får kendskab til partens epost-adresse, certifikat og seneste kommunikation med organisationen for at afgøre, hvordan parten skal kontaktes. Medarbejderen danner en epost og anvender organisationens certifikat til at sikre kommunikation og autenticitet. Efter afsendelse registreres i ESDHsystemet, at eposten er afsendt, ligesom der registreres informationer om, hvordan epost afsendelsen er sket. 15 / 33

16 Løsningsscenarie Afsendelse af e-post Internet S/MIME Gateway Mail Server CA ESDH System Sagsarkiv Pers. mailbox Org. mailbox Mail Client Mail Client ESDH SAF STAGING COPY Certifikatvalg Krypteringsvalg Kvittering mailbox Identifikation Figur 3: Afsendelse af epost Afsendelsen af epost foregår fra epostklienten (1). Epostklienten beriges med noget afsendelsesfunktionalitet, som gør det muligt for brugeren at vælge, om eposten skal signeres med et virksomhedscertifikat og/ eller krypteres (2). I organisationer med flere virksomhedscertifikater, kan det endvidere være hensigtsmæssigt, at medarbejderen kan vælge hvilket virksomhedscertifikat, der skal avendes til signeringen. Denne afsendelsesfunktionalitet leveres i dag normalt af samme leverandør, som leverer sikker epostløsningen (typisk i form af en Send sikkert -knap i epostklienten), men kunne også leveres med ESDH-systemet eller af en tredje parts leverandør. Standarden beskæftiger sig ikke med, hvordan eller af hvem funktionaliteten er udviklet, men beskriver udelukkende grænsefladen mellem epostklienten og sikker epostløsningen. Grænsefladen, som konkretiseres i DEL C, indbefatter, at den epost, der videresendes fra epost klienten til sikker epostløsningen (3), forsynes med op til fire ekstra oplysninger (header oplysninger eller evt. udvidelse af subjectfeltet): 1. Certifikat der skal anvendes til signering. 2. Kryptering skal kryptering foretages? 3. Epostadresse på ESDH-systemets Saf staging -epostkasse. 4. En frivillig identifikatorstreng, der identificerer eposten overfor ESDH-systemet. Hvis medarbejderen vælger at signere eposten direkte i epostklienten med medarbejderdelen af medarbejdersignatur avanceret, udelades oplysningen vedrørende certifikat. Gatewayen agerer på udgående epost, der har tilknyttet de ekstra oplysninger, således at : Epost, der har certifikat-oplysningen, bliver signeret med det pågældende certifikat, og at afsenderadressen på eposten ændres fra medarbejderens til virksomhedens. Epost, der har krypterings-oplysningen (true), bliver krypteret med modtagerens certifikat. 16 / 33

17 Epost der har ESDH-epostkasse-oplysningen behandles ved, at der o o o Dannes en udgående følgeseddel Dannes en kopi af eposten Fremsendes en kopi med følgesedlen tilknyttet til ESDH-systemets Saf staging - epostkasse (4). Epost der har en identifikatorstrengs-oplysning får identifikatorstrengen indsat i den udgående følgeseddel, såfremt der også er tilknyttet en ESDH-epostkasse-oplysning. Når medarbejderen har afsendt eposten, vil der med en tidsforsinkelse blive sendt en kopi af eposten til ESDH-systemets saf staging epostkasse, såfremt Gateway en kan verificere modtageren og foretage en korrekt afsendelse af eposten. Medarbejderen kan nu arkivere eposten i ESDH-systemet fra epost klienten vha. ESDH-systemets epostintegration (5). Medarbejderen kan genfinde eposten i folderen med afsendte epost og vælge at gemme den i ESDH-systemet. ESDH-systemets epostintegration genkender epost, der har påført ESDH-epostkasseoplysningen og tillader, at disse lagres i ESDH-systemet, når der er modtaget en kopi af eposten i ESDHepostkassen og som ved indgående post er det kopien fra ESDH-epostkassen, der gemmes i ESDHsystemets arkiv. 17 / 33

18 4 DEL C 4.1 Logisk model Epost Message cd Message Message 1 SignedBy Signature ProvesSignatureOf 0..1 SignatureProv e Mail CMSForm Figur 4 En Message er et generelt begreb for meddelelser, der kan sendes til et ESDH-system. Denne standard omfatter kun epost, men på et senere tidspunkt kan standarden revideres, så andre typer af meddelelser også understøttes. På klassediagrammet er vist en CMSForm som eksempel på en udvidelse. En Message kan være signeret med en digital signatur, og en løsning kan evt. have verificeret signaturen og erstattet signaturen med (eller blot tilføjet) et signaturbevis. Signaturbeviset indeholder oplysninger i XMLformat, der beskriver, hvordan eposten er signeret. 18 / 33

19 class Message Mail IncommingMail IncommingProcessedMail IncommingStagedMail OutgoingMail OutgoingProcessedMail OutgoingStagedMail + stagingid: UUID + stagingid: UUID + encrypt: boolean + esdharchive: mailaddress + esdhid: string + signature: mailaddress Signature SignatureProveIn «column» + personcivilregistrationidentifier: Integer(10) [0..1] {bag} + signaturevalidindicator: Boolean {bag} + verificationdatetime: DateTime {bag} Signature Prov eout «column» + bccaddresses: Char(255) + ccaddresses: Char(255) + elementidentifikatorstreng: Char(255) + fromaddress: Char(255) {bag} + replytoaddress: Char(255) {bag} + returnpath: Char(255) {bag} + senderaddress: Char(255) {bag} + signeddatetime: datetime {bag} + smtpmailfrom: Char(255) {bag} + smtprcptto: Char(255) {bag} + toaddress: Char(255) {bag} SignatureProv e «column» + certificatecommonname: Char(50) {bag} + certificatefingerprint: Char(255) [0..1] {bag} + certificateorganizationname: Char(50) [0..1] {bag} + certificateorganizationunitname: Char(50) [0..1] + certificateserialnumber: Char(60) {bag} + certificatissuername: Char(50) {bag} + CVRnumberIdentifier: Integer(8) [0..1] + dataencryptionlevel: Char(255) {bag} + encryptedindicator: boolean {bag} + signatureproveidentificator: UUID {sequence} + transportkeyencryptionlevel: Char(255) {bag} Figur 5 19 / 33

20 4.1.2 Signaturbevis Generelt for ind- og udgående signaturbevis Klassen indeholder attributter, som skal være til stede i både ind- og udgående signaturbeviser. Attribut Dan Attribut Eng Type Kardinalitet Beskrivelse krypteret encryptedindicator Boolean [1] Tekst der angiver, om en modtagen epost meddelelse har været krypteret eller ej. transportnøglekrypteringsniveau transportkeyencryptionlevel Char(255) [1] Indeholder information om den modtagne eller afsendte meddelelses transportnøglekrypteringsniveau. Anvendes til at angive hvilken krypteringsalgoritme og hvilken nøglelængde, der er anvendt. F.eks. RSA 1024 bit. datakrypteringsniveau dataencryptionlevel Char(255) [1] Indeholder information om den modtagne eller afsendte meddelelses datakrypteringsniveau. Anvendes til at angive hvilken krypteringsalgoritme og hvilken nøglelængde, der er anvendt. F.eks. 3DES 168 bit. certifikatudsteder certificateissuername Char(50) [1] Indeholder information om hvem der er udsteder af den digitale signatur. Anvendes til at angive udstederen (certificeringscentret) af den digitale signatur. Tekst, der angiver udstederen af et givent certifikat, og som direkte kan tages fra certifikatfeltet Udsteder eller Issuer. F.eks.: TDC OCES CA, TDC, DK 20 / 33

21 Attribut Dan Attribut Eng Type Kardinalitet Beskrivelse certifikatserienummer certificateserialnumber Char(60) [1] Indeholder information om certifikatets serienummer. Anvendes til at angive serienummeret i certifikatet. Entydigt felt i certifikatet, som indeholder forskellige oplysninger, alt afhængig hvilken certifikattype, der bruges. For personcertifikater Kvalifikator PID: konkateneret med løbenummer. Se DS Personspecifikke identifikationsnumre (PID). For medarbejdercertifikater CVR:cvrnummer-RID:medarbejderId. For virksomhedscertifikater Kvalifikator CVR:konkateneret med cvrnummer og evt. en af følgende kvalifikatorer:uid:, SE:, P: konkateneret med et ID, se DS 844, pkt. 6.1 Eksempler: serialnumber= PID: ,serialNumber=CVR: RID:medarbejderId serialnumber=cvr: uid:skatteforvaltningen 21 / 33

22 Attribut Dan Attribut Eng Type Kardinalitet Beskrivelse certifikatanvendernavn certificatecommonname Char(50) [1] Anvendes til at angive CommonName-feltet i certifikatet. Entydigt felt i certifikatet, som indeholder forskellige oplysninger, alt afhængig hvilken certifikattype, der anvendes. Personens fulde navn eller pseudonym. Medarbejderens fulde navn eller registrerede pseudonym, evt. inkl. Titel. Certifikatindehaverens navn plus evt anden tekststreng adskilt af - Eksempler: commonname= Test Testesen commonname= Projektleder Jens Madsen, commonname=virksomhed A/S-tekststreng 22 / 33

23 Attribut Dan Attribut Eng Type Kardinalitet Beskrivelse certifikatorganisationnavn certificateorganizationname Char(50) [0..1] Anvendes til at angive Organisationsfeltet i certifikatet. Entydigt felt i certifikatet, som indeholder forskellige oplysninger alt afhængig hvilken certifikattype, der anvendes. "Ingen organisatorisk tilknytning". Virksomhedens fulde navn, evt. inkl. CVR-nummer. certifikatorganisationenhednavn certificateorganizationunit- Name Char(50) [0..1] Navn på den organisatoriske enhed. cvrnr CVRnumberidentifier Integer(8) [0..1] Indeholder CVR-nr. (Kun relevant ved medarbejder- og virksomhedscertifikater). Indeholder CVR-nr. Anvendes til at angive CVR-nummeret i certifikatet (kun relevant ved medarbejder- og virksomhedscertifikater). Xxxxxxxx - f.eks / 33

24 Attribut Dan Attribut Eng Type Kardinalitet Beskrivelse certifikatfingeraftryk certificatefingerprint Char(255) [0..1] Anvendes til at angive certifikatets fingerprint, som er en digest (en hashfunktion) af certifikatet i X.509 binært format. Den kan udregnes ved hjælp af forskellige algoritmer, f.eks. SHA1 (Internet Explorer) eller MD5 for andre browsere Xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx:xx F.eks i SHA1: 78:e9:dd:06:50:62:4d:b9:cb:36:b5:07:67:f2:09:b8:43:be:15:b3 De konkrete krav for indholdet af nogle af felterne er uddybet i certifikatpolitikkerne på 24 / 33

25 Specifikt for indgående signaturbevis Klassen indeholder attributter, som skal være til stede ved indgående signaturbeviser. Attribut Dan Attribut Eng Type Kardinalitet Beskrivelse signaturgyldig signaturevalidindicator Boolean [1] Indeholder information om en signeret meddelelses digitale signatur er gyldig eller ej. Tekst der angiver, om en digital signatur på en modtaget sikker epost er gyldig eller ej. verificeringsdatotidspunkt verificationdatetime DateTime [1] Indeholder information om tidspunktet for verificering af den digitale signatur. Dato der angiver, hvornår den digitale signatur er blevet valideret. F.eks. Mon, 6 Oct :07: (CEST), cprnr personcivilregistrationidentifier Integer(10) [0..1] Anvendes til at angive CPR-nr. Entydigt nummer. 25 / 33

26 Specifikt for udgående signaturbevis Klassen indeholder attributter, som skal være til stede ved udgående signaturbeviser. Attribut Dan Attribut Eng Type Kardinalitet Beskrivelse signeringsdatotidspunkt signeddatetime DateTime [1] Indeholder information om, hvornår den afsendte meddelelse er blevet signeret. Anvendes til at angive tidspunktet for signeringen af den afsendte epost meddelelse. F.eks. Mon, 6 Oct :07: (CEST). smtpepostfra smtpmailfrom Char(255) [1] Indeholder informationer, som SMTP-serveren har behov for at vide. Anvendes til at angive til SMTP-serveren, at der starter en ny transaktion- MAIL FROM er det første skridt i en MAIL kommando. MAIL FROM:<reverse-path> [SP <mail-parameters> ] <CRLF> f.eks. MAIL De konkrete krav til formatet kan findes i RFC / 33

27 Attribut Dan Attribut Eng Type Kardinalitet Beskrivelse smtprcpttil smtprcptto Char(255) [1] Indeholder informationer, som SMTP-serveren har behov for at vide. Anvendes til at angive en forward-path (recipient RCPT TO er det andet skridt i en MAIL kommando RCPT TO:<forward-path> [ SP <rcpt-parameters> ] <CRLF> f.eks.: RCPT De konkrete krav til formatet kan findes i RFC fraadresse fromaddress Char(255) [1] Indeholder information om, hvem epost meddelelsen kommer fra. Anvendes til at angive Fra -headeren i en epost meddelelse. Fra -headeren er specificeret i RFC tiladresse toaddress Char(255) [1] Se ovenfor afsenderadresse senderaddress Char(255) [1] Se ovenfor ccadresser ccaddresses Char(255) [1] Se ovenfor bccadresser bccaddresses Char(255) [1] Se ovenfor retursti returnpath Char(255) [1] Se ovenfor svartiladresse replytoaddress Char(255) [1] Se ovenfor elementidentifikatorstreng itemidentificatorstring Char(255) [1] Indeholder den ID-streng, som er vedhæftet udgående mail (svarer til X- ESDH-ID i den udgående mail). Kan anvendes af ESDH-systemet til at påhæfte ekstra ID-oplysninger ved en forregistrering af mailen, som kan genfindes i kvitteringsmailens tilknyttede signaturbevis. Ingen krav til syntaks af strengen. Kan defineres af det enkelte ESDHsystem. esdhid String [1] 27 / 33

28 4.1.3 Epost headere for udgående epost Ved afsendelse af epost anvendes følgende mimeheadere til at markere og kommunikere med S/MIMEgateway en: X-Sign: Signering [certifikatnavn] (bruges kun til virksomhedscertifikat) X-Encrypt: Kryptering Boolean X-Archive: ESDH Arkiv [epostkasse] X-ESDH-ID: ID, der videreføres til ESDH-systemet. Da ikke alle epostklienter tillader programmatisk adgang til mimeheadere, bør sikker epostløsningerne tilbyde en metode til at encode oplysningerne ind i subjectfelterne. 28 / 33

29 4.2 Udvidelse af FESD-datamodel class Datamodel Rec ord «column» *PK RecordIdentificator: UUID «PK» + PK_Record(UUID) +PK_Record 1 +FK_SignatureProv_SignatureProv 0..1 SignatureProv eofrecord «column» *FK RecordIdenti fier: UUID *FK SignatureProveIdentificator: UUID (SignatureProveIdentificator = signatureproveidentificator) «FK» «FK» + FK_SignatureProv_SignatureProv(UUID) + FK_SignatureProveOfReco_Record(UUID) +FK_SignatureProveOfReco_Record 0..1 «FK» (RecordIdentifier = RecordIdentificator) SignatureProve «column» *PK signatureproveidentificator: UUID * encryptedindicator: boolean * transportkeyencryptionlevel: CHAR(255) * dataencryptionlevel: CHAR(255) * certificatissuername: CHAR(50) * certificateserialnumber: CHAR(60) * certificatecommonname: CHAR(50) * certificateorganizationname: CHAR(50) CVRnumberIdentifier: string * certificatefingerprint: CHAR(255) +PK_SignatureProve 1 «PK» + PK_SignatureProve(UUID) Signature Prov eout «column» * signeddatetime: datetime * smtpmailfrom: CHAR(255) * smtprcptto: CHAR(255) * fromaddress: CHAR(255) * toaddress: CHAR(255) * senderaddress: CHAR(255) ccaddresses: CHAR(255) bccaddresses: CHAR(255) * returnpath: CHAR(255) * replytoaddress: CHAR(255) itemidentificatorstring: CHAR(255) SignatureProv ein «column» * signaturevalidindicator: boolean * verificationdatetime: datetime * personcivilregistrati onidentifier: string Figur 6 Registrering af sikkerheden via forsendelser foretages i 2 nye tabeller, der navngives: SignatureproveIn SignatureproveOut Tabellerne indeholder oplysningerne fra de ind- og udgående signaturbeviser med retningsangivelse. 29 / 33

30 Derudover udvides datamodellen med en relationstabel: signatureproveofrecord mellem record og Signatureprove-tabellen, således at journalposter, der repræsenterer en sikker , kan tilknyttes et signaturbevis. Udvidelsen giver således mulighed for, at der på et senere tidspunkt kan tilknyttes signaturbeviser til andre entiteter i datamodellen (f.eks. dokumenter, der repræsenterer formularer fra et CMS-system). 30 / 33

31 5 Anvendte typer i FESD-modellerne FESD-modellerne er udarbejdet i UML med det formål at beskrive den logiske informationsarkitektur i en FESD-løsning. UML-modellen er opbygget af et antal klasser, der igen er opbygget af relationer til andre klasser og primitive typer, så man kan opfatte UML-modellen som opbygget af byggesten, hvoraf den mindste er de primitive datatyper. I UML-modellen beskriver de primitive datatyper det logiske domæne, som datatypen kan antage, men ikke hvordan den fysiske repræsentation af data skal være. I skemaerne ses for hver primitiv datatype, der anvendes i FESD-UML-modellen, den tilsvarende datatype for hhv. SQL og XSD. integer Benyttes til angivelse af heltal. Der kan benyttes en angivelse af max længde hvis intet er angivet, vil domænet være i intervallet mellem og Anvendte længder i den nuværende model: 2, 3, 4, 6, 8, 10. Benyttes alene til naturlige tal (positive heltal). Benyttes også til at danne identifikator med udfaldsrum UML Type Beskrivelse SQL datatype XSD datatype Integer Heltal i rummet mellem og , begge tal inklusive. Den maksimale længde angives i modellen NonNegativeInteger Naturlige tal Heltal i rummet mellem 0 og , begge tal inklusive NUMBER(Maksimal længde) NUMBER(Maksimal længde) xsd:int xsd:int boolean Er en grundtype i UML. UML Type Beskrivelse SQL datatype XSD datatype Boolean Udfaldsrummet er binært true / BOOLEAN xsd:boolean false (eller rigtigt / forkert). 31 / 33

32 Identifikationstyper UML Type Beskrivelse SQL datatype XSD datatype URI Enhver mulig lovlig URI. Der kan evt. anvendes en maxlængde. STRING xsd:anyuri HttpURI Lovlig http(s)-adresse STRING xsd:anyuri MailToURI Smtp-adresse på en mailmodtager. STRING Evt. restrictions der afgrænser til http. xsd:anyuri UUID Identifikator på objekt UUID xsd:anyuri UserIdentifier SystemIdentifier BinaryObject Det er en identifikation af bruger Det er en identifikation af systemer Et binary large object - også kaldet blob - er en samling af binære data, der opbevares som en separat entitet i et database management system. Blobs er typisk billeder, lyd og andre medieobjekter, selvom binær eksekverbar kode til tider også opbevares som en blob. Database support for blob er ikke universal. Binary Large Object (BLOB) Evt. restrictions der afgrænser til mailadresser. Evt. restrictions der afgrænser til UUID. char Benyttes til karakterstrenge af varierende længde, men med en defineret maksimal længde. Anvendte længder: 1, 2, 3, 4, 15, 16, 20, 34, 40, 50, 60, 70, 110, 120, 255. Benyttes også nogle steder til at angive en boolsk værdi. UML Type Beskrivelse SQL datatype XSD datatype Char Den minimale og maksimale længde er angivet i modellen. VARCHAR(maksimal længde) xsd:string Med restriction på den maximale længde ShortText Anvendes til felter der indeholder en kort beskrivende tekst VARCHAR(70) xsd:string Med restriction på den maximale længde Text Anvendes til en beskrivende tekst med en fast længde. VARCHAR(255) xsd:string Med restriction på den maximale længde 32 / 33

FESD Sikker epostløsning

FESD Sikker epostløsning FESD Sikker epostløsning Standard IT- og Telestyrelsen København den 23. august 2006. FESD-standardisering Sikker epostløsning. Grænsesnit Version 1.0 Kolofon: FESD-standardisering. Sikker epostløsning.

Læs mere

Digital Signatur OCES en fælles offentlig certifikat-standard

Digital Signatur OCES en fælles offentlig certifikat-standard Digital Signatur OCES en fælles offentlig certifikat-standard IT- og Telestyrelsen December 2002 Resumé Ministeriet for Videnskab, Teknologi og Udvikling har udarbejdet en ny fælles offentlig standard

Læs mere

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME

DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME DKAL Snitflader Afsendelse og modtagelse af meddelelser via S/MIME 1 Indholdsfortegnelse B.1. INTRODUKTION... 3 B.1.1. HENVISNINGER... 3 B.1.2. INTEGRATION MED EKSISTERENDE SIKKER E-POSTLØSNING... 3 B.1.3.

Læs mere

FESD Brugeradministration

FESD Brugeradministration FESD Brugeradministration Standard IT- og Telestyrelsen København den 10. december 2008 FESD standardisering Brugeradministration. Datamodel Version 1.1 Kolofon: FESD standardisering. Brugeradministration.

Læs mere

FESD Arkivstruktur. Standard. FESD-standardisering Arkivstruktur. Datamodel Version 1.1. IT- og Telestyrelsen København den 10. december 2008.

FESD Arkivstruktur. Standard. FESD-standardisering Arkivstruktur. Datamodel Version 1.1. IT- og Telestyrelsen København den 10. december 2008. FESD Arkivstruktur Standard IT- og Telestyrelsen København den 10. december 2008. FESD-standardisering Arkivstruktur. Datamodel Version 1.1 Kolofon: FESD-standardisering. Arkivstruktur. Datamodel. Version

Læs mere

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3

Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 Digital post Snitflader Bilag B - Afsendelse og modtagelse af meddelelser via S/MIME Version 6.3 1 Indholdsfortegnelse B.1. INTRODUKTION... 4 B.1.1. HENVISNINGER... 4 B.1.2. INTEGRATION MED EKSISTERENDE

Læs mere

Digital Signatur Infrastrukturen til digital signatur

Digital Signatur Infrastrukturen til digital signatur Digital Signatur Infrastrukturen til digital signatur IT- og Telestyrelsen December 2002 Resumé: I fremtiden vil borgere og myndigheder ofte have brug for at kunne kommunikere nemt og sikkert med hinanden

Læs mere

Høring. Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007

Høring. Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007 Høring Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22. august 2007 IT- og Telestyrelsen København den 12. juli 2007 FESD-standardisering Grænseflade

Læs mere

Digital Signatur Sikker brug af digital signatur

Digital Signatur Sikker brug af digital signatur Digital Signatur IT- og Telestyrelsen December 2002 Resumé Myndigheder, der ønsker at indføre digital signatur, må ikke overse de vigtige interne sikkerhedsspørgsmål, som teknologien rejser. Det er vigtigt,

Læs mere

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø

FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø FESD-standardiseringsgruppen Att: Palle Aagaard IT- og Telestyrelsen IT-strategisk kontor Holsteinsgade 63 2100 København Ø Høringssvar vedr. FESD GIS-integrationsmodel version 2.0 Geodata Danmark har

Læs mere

Notat. Omstilling til edag - handlingsplan. Projektets formål og succeskriterier. edag arbejdsgruppen. IT-Kontoret. edag i Aalborg Kommune

Notat. Omstilling til edag - handlingsplan. Projektets formål og succeskriterier. edag arbejdsgruppen. IT-Kontoret. edag i Aalborg Kommune Notat Til: edag arbejdsgruppen Kopi til: Fra: IT- Dato: 28.04.2003 Vedr.: edag i Aalborg Kommune Mandag d. 1. september 2003 er fastsat som edag for alle offentlige myndigheder. edag er aftalt mellem regeringen,

Læs mere

Specifikationsdokument for LDAP API

Specifikationsdokument for LDAP API Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Specifikationsdokument for LDAP API DanID A/S 5. juni 2014 Side 1-15

Læs mere

Vejledning om avanceret afhentning. i Digital Post på Virk.dk.

Vejledning om avanceret afhentning. i Digital Post på Virk.dk. Vejledning om avanceret afhentning og sortering i Digital Post på Virk.dk. Denne vejledning beskriver, hvordan virksomheder, foreninger m.v. med et CVR-nummer kan modtage Digital Post, herunder hvordan

Læs mere

Finanstilsynets indberetningssystem. Vejledning til indsendelse af xml-filer via sikker e- mail (signeret og krypteret e-mail)

Finanstilsynets indberetningssystem. Vejledning til indsendelse af xml-filer via sikker e- mail (signeret og krypteret e-mail) Finanstilsynets indberetningssystem Vejledning til indsendelse af xml-filer via sikker e- mail (signeret og krypteret e-mail) Finanstilsynet - 8. udgave oktober 2009 Indholdsfortegnelse 1 INTRODUKTION...

Læs mere

Timengo. Digitalisering med en Microsoft platformen Kenneth Wohlers, Timengo. Timengo

Timengo. Digitalisering med en Microsoft platformen Kenneth Wohlers, Timengo. Timengo Digitalisering med en Microsoft platformen Kenneth Wohlers, Agenda Sikker post Nye muligheder Vores løsning - VMG Scenarier Teknisk overblik Hvad er Sikker post Teknologi Certifikater Standarder Formål

Læs mere

Udvalget for Videnskab og Teknologi 2009-10 UVT alm. del Svar på Spørgsmål 33 Offentligt

Udvalget for Videnskab og Teknologi 2009-10 UVT alm. del Svar på Spørgsmål 33 Offentligt Udvalget for Videnskab og Teknologi 2009-10 UVT alm. del på Spørgsmål 33 Offentligt Ministeren for videnskab, teknologi og udvikling Udvalget for Videnskab og Teknologi Folketinget Christiansborg 1240

Læs mere

PBS CA. Certifikat Politik (CP) Virksomhed og medarbejdercertifikat. Chipkort OID: 1.2.208.163.1.1.2

PBS CA. Certifikat Politik (CP) Virksomhed og medarbejdercertifikat. Chipkort OID: 1.2.208.163.1.1.2 PBS CA Certifikat Politik (CP) Virksomhed og medarbejdercertifikat Chipkort OID: 1.2.208.163.1.1.2 Version 1.1 24. maj 2005 1. Formål 3 1.1. Version 3 1.2. Ændringshåndtering 3 1.3. Kontakt 4 1.4. Rettigheder

Læs mere

Elektronisk indberetning til Finanstilsynet. Vejledning i Sikker e-mail

Elektronisk indberetning til Finanstilsynet. Vejledning i Sikker e-mail Elektronisk indberetning til Finanstilsynet Vejledning i Sikker e-mail Finanstilsynet - 7. udgave marts 2009 Indholdsfortegnelse 1 INTRODUKTION... 1 1.1 Support... 1 2 INFORMATION OM SIKKER E-MAIL... 2

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL UUID UBL 2.0 UUID G32 Version 1.1 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL UUID Version 1.1 Side 1 Kolofon Kontakt: IT- & Telestyrelsen E-mail:

Læs mere

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt

Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Udvalget for Videnskab og Teknologi (2. samling) UVT alm. del - Svar på Spørgsmål 19 Offentligt Ministeren for videnskab, teknologi og udvikling Udvalget for Videnskab og Teknologi Folketinget Christiansborg

Læs mere

Vejledning i at oprette afsendersystemer i Digital Post. Februar 2016

Vejledning i at oprette afsendersystemer i Digital Post. Februar 2016 Vejledning i at oprette afsendersystemer i Digital Post Februar 2016 Hvem skal anvende vejledningen? Vejledningen er relevant for dig, hvis du skal oprette afsendersystemer i Digital Post eller oprette

Læs mere

Høring i forbindelse med revision af certifikatpolitik for OCESpersoncertifikater (Offentlige Certifikater til Elektronisk Service) 27.

Høring i forbindelse med revision af certifikatpolitik for OCESpersoncertifikater (Offentlige Certifikater til Elektronisk Service) 27. Høringsparter vedr. certifikatpolitikker Se vedlagte liste Høring i forbindelse med revision af certifikatpolitik for OCESpersoncertifikater (Offentlige Certifikater til Elektronisk Service) 27. februar

Læs mere

Certifikatpolitik for NemLog-in

Certifikatpolitik for NemLog-in Side 1 af 9 7. november 2012 Certifikatpolitik for NemLog-in Version 1.2 Dette dokument beskriver certifikatpolitikken for NemLog-in løsningen. Politikken definerer hvilke typer certifikater, der må anvendes

Læs mere

Digital Signatur Juridiske aspekter. IT- og Telestyrelsen December 2002

Digital Signatur Juridiske aspekter. IT- og Telestyrelsen December 2002 Digital Signatur IT- og Telestyrelsen December 2002 Resumé Borgernes retsstilling forringes ikke ved, at en aftale indgås elektronisk og signeres digitalt aftaler indgået elektronisk har samme gyldighed

Læs mere

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat.

0.9 19-09-2012 DAVAR Omdøbt til SagDokumentFormat. Attention er skilt ud i et selvstændigt format, AttentionFormat. Specifikation 19. september 2012 DAVAR J.nr. 2012-6211-281 Sagdokumentformat Versionshistorik Version Dato Initialer Noter 0.7 15-06-2012 DAVAR Høringsversion. Indsat MeddelelseAttention. 0.9 19-09-2012

Læs mere

Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005

Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005 Skanningsmodul Standard IT- og Telestyrelsen København den 8. september 2005 FESD standardisering FESD-modul. Skanningsmodul Version 1.0 Kolofon: FESD moduler. Skanningsmodul. FESD standardisering. Skanningsmodul

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Udvidelse UBL 2.0 Extension G33 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Udvidelse Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

Version: 1.0 Udarbejdet: Okt. 2013 Udarbejdet af: Erhvervsstyrelsen og Digitaliseringsstyrelsen

Version: 1.0 Udarbejdet: Okt. 2013 Udarbejdet af: Erhvervsstyrelsen og Digitaliseringsstyrelsen Anbefalinger om brug af Digital Post for store virksomheder, administratorer/advokater (fx ejendomsadministratorer) og virksomheder med mange p- enheder Version: 1.0 Udarbejdet: Okt. 2013 Udarbejdet af:

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel Indhold > Indledning 3 Standarder 5 OIOUBL 5 OIO RASP 6 OIO SMI 7 Biblioteker 8 Web applikationer 9 Fakturablanket 9 NemHandel Registrering 9 NemHandel.dk 10 Web services

Læs mere

DIGITAL SIGNATUR l OUTLOOK 2010

DIGITAL SIGNATUR l OUTLOOK 2010 DIGITAL SIGNATUR l OUTLOOK 2010 For at kunne bruge signeret og krypteret e-mail i Outlook skal der være et digitalt certifikat installeret på den gældende computer. Certifikatet kan enten være et privat

Læs mere

Guide til integration med NemLog-in / Signering

Guide til integration med NemLog-in / Signering Guide til integration med NemLog-in / Signering Side 1 af 6 14. november 2013 TG Denne guide indeholder en kort beskrivelse af, hvorledes man som itsystemudbyder (myndighed eller it-leverandør) kan integrere

Læs mere

Hvad er KRYPTERING? Metoder Der findes to forskellige krypteringsmetoder: Symmetrisk og asymmetrisk (offentlig-nøgle) kryptering.

Hvad er KRYPTERING? Metoder Der findes to forskellige krypteringsmetoder: Symmetrisk og asymmetrisk (offentlig-nøgle) kryptering. Hvad er KRYPTERING? Kryptering er en matematisk teknik. Hvis et dokument er blevet krypteret, vil dokumentet fremstå som en uforståelig blanding af bogstaver og tegn og uvedkommende kan således ikke læses

Læs mere

Introduktion til Digital Post. Februar 2016

Introduktion til Digital Post. Februar 2016 Introduktion til Digital Post Februar 2016 Hvem skal læse dokumentet? Vejledningen er relevant for dig, hvis du har brug for en introduktion til Administrationsportalen i Digital Post og hvad der skal

Læs mere

Kommunikationssikkerhed til brugere bibliotek.dk projekt 2006-23

Kommunikationssikkerhed til brugere bibliotek.dk projekt 2006-23 Kommunikationssikkerhed til brugere bibliotek.dk projekt 2006-23 Formål Formålet med dette notat er at beskrive forskellige løsninger for kommunikationssikkerhed til brugerne af bibliotek.dk, med henblik

Læs mere

Høring. FESD-standardisering FESD Datafølgeseddel. Protokol Version 0.8

Høring. FESD-standardisering FESD Datafølgeseddel. Protokol Version 0.8 Høring Dette udkast til forslag til FESD-standard er i offentlig høring i perioden fra 12. juli 2007 til 22 august 2007. IT- og Telestyrelsen København 12. juli 2007 FESD-standardisering FESD Datafølgeseddel.

Læs mere

DataHub Forbrugeradgangsløsning Spørgsmål og svar

DataHub Forbrugeradgangsløsning Spørgsmål og svar 9. Januar 2013 MEH/MHC DataHub Forbrugeradgangsløsning Spørgsmål og svar Dok 75938-12_v2, Sag 10/3365 1/7 1. Generelt 1.1 I hvilket omfang yder Energinet.dk support til elleverandørerne? Forretningskonceptet

Læs mere

FESD standardisering Udveksling Version 1.0

FESD standardisering Udveksling Version 1.0 FESD standardisering Udveksling Version 1.0 Kolofon: FESD standardisering. Udveksling Version 1.0 FESD udvekslingspakke Udarbejdet af IT- og Telestyrelsen, IT-strategisk kontor, FESD standardiseringsgruppen

Læs mere

Typografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem

Typografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem Typografidefinition: Typografi1: Skrifttype: 10 pkt, (intet) DKAL Snitflader REST Afhentningssystem 1 Indholdsfortegnelse A3.1 INTRODUKTION 3 A3.1.1 HENVISNINGER 3 A3.1.2 LÆSEVEJLEDNING 4 A3.1.2.1 SÅDAN

Læs mere

Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4

Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4 Digital post Integration for virksomheder Via sikker e-mail og REST Version 6.4 1 Indholdsfortegnelse G.1 INTRODUKTION 4 G.1.1 OVERBLIK OVER HVORDAN DIGITAL POST KAN TILGÅS 4 G.1.2 FLOW SOM EN DIGITAL

Læs mere

1.1 Formål Webservicen gør det muligt for eksterne parter, at fremsøge informationer om elevers fravær.

1.1 Formål Webservicen gør det muligt for eksterne parter, at fremsøge informationer om elevers fravær. EfterUddannelse.dk FraværService - systemdokumentation BRUGERDOKUMENTATION: WEB-SERVICE Af: Logica Indhold 1. Indledning... 1 1.1 Formål... 1 1.2 Webservice version... 1 1.3 Historik... 1 2. Absence Webservice...

Læs mere

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09

LUDUS WEB. Installations- og konfigurations-vejledning. Den 7. april 2009. J.nr.: 4004 V0624 09 LUDUS WEB Installations- og konfigurations-vejledning Den 7. april 2009 J.nr.: 4004 V0624 09 CSC Scandihealth A/S, P.O. Pedersens Vej 2, DK-8200 Århus N Tlf. +45 3614 4000, fax +45 3614 7324, www.scandihealth.dk,

Læs mere

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365

NemID DataHub adgang. morten@signaturgruppen.dk & jakob@signaturgruppen.dk. Doc. 25538-12, sag 10/3365 NemID DataHub adgang morten@signaturgruppen.dk & jakob@signaturgruppen.dk Agenda Funktionaliteten og brugeroplevelsen Arkitekturen og komponenterne bag NemID og digital signatur Datahub token Pause Udvikling

Læs mere

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Datatyper UBL 2.0 Datatypes G29 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen E-mail:

Læs mere

!!" # $ +!* #(, !"! +0 1(

!! # $ +!* #(, !! +0 1( " # $%&'() * $ +* #(, (- #("(&"(. /(" " #"'& +0 1( #"" "'2(34#&& #"'2* 4(&1* #"&('* 1"'"* $5&'((" * $* 6&'(* #(, "'"67 '81% )1828& 9& : 9&'"'('1&8& "1 '5'8&&"2" '' ' &2"3;1 &2&(: 1 (&8" '"'"67 '8": 8'

Læs mere

OIOUBL Guideline. OIOUBL Guideline

OIOUBL Guideline. OIOUBL Guideline OIOUBL Guideline OIOUBL Guideline OIOUBL Dokument Reference UBL 2.0 Document Reference G21 Version 1.3 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 Kolofon Kontakt: Digitaliseringsstyrelsen

Læs mere

Fra 1. april 2009 skal lægerne fremsende alle henvisninger til psykologer og fysioterapeuter elektronisk.

Fra 1. april 2009 skal lægerne fremsende alle henvisninger til psykologer og fysioterapeuter elektronisk. Guide: Henvisninghotellet ( REFHOST ) Version mar 2009 Fra 1. april 2009 skal lægerne fremsende alle henvisninger til psykologer og fysioterapeuter elektronisk. Denne guide er primært baseret på oplysninger

Læs mere

AuthorizationCodeService

AuthorizationCodeService AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark, version 1.1 W 1 AuthorizationCodeService Sammenhængende Digital Sundhed i Danmark version 1.1 Kåre Kjelstrøm Formål... 3 Introduktion...

Læs mere

DKAL Snitflader Masseforsendelse

DKAL Snitflader Masseforsendelse DKAL Snitflader Masseforsendelse 1 C.1 Indholdsfortegnelse C.1 INDHOLDSFORTEGNELSE... 2 C.2 LÆSEVEJLEDNING... 3 C.3 TILMELDINGSLISTE... 4 C.3.1 RECORD-STRUKTUR... 4 C.3.2 OIOXML-STRUKTUR... 5 C.4 MATERIALE-INDLÆSNING...6

Læs mere

Leverancebeskrivelse - Bilag 1

Leverancebeskrivelse - Bilag 1 Leverancebeskrivelse - Bilag 1 Miniudbud iht. rammeaftale 02.18 om Borgerskab og Service Juli 2008 Dato: 17-07-2008 Kontor: Udviklingsenhed J.nr.: I4148 Sagsbeh.: CHS Fil-navn: Leverancebeskrivelse bilag

Læs mere

Finanstilsynets indberetningssystem. FAQ Ofte stillede spørgsmål

Finanstilsynets indberetningssystem. FAQ Ofte stillede spørgsmål Finanstilsynets indberetningssystem FAQ Ofte stillede spørgsmål Finanstilsynet - 1. udgave oktober 2009 Indholdsfortegnelse 1 HVAD ER FINANSTILSYNETS INDBERETNINGSSYSTEM?... 2 2 HVORDAN FÅR JEG DANNET

Læs mere

Underbilag 2O Beskedkuvert Version 2.0

Underbilag 2O Beskedkuvert Version 2.0 Underbilag 2O Beskedkuvert Version 2.0 Indhold Indledning... 34 2 Beskedkuvertens struktur... 34 3 Indhold af Beskedkuverten... 34 3. Overordnet indhold... 45 3.2 Detaljeret indhold af Beskedkuverten...

Læs mere

e-boks mobilløsninger, tovejskommunikation og øvrige produktnyheder

e-boks mobilløsninger, tovejskommunikation og øvrige produktnyheder 1 e-boks mobilløsninger, tovejskommunikation og øvrige produktnyheder Erik Abildgaard Knudsen Product And Development Director E-mail: eak@e-boks.dk Mobil: 29487722 Hovedsponsor for Caroline Wozniacki

Læs mere

Anbefaling til unik Id-nøgle

Anbefaling til unik Id-nøgle Anbefaling til unik Id-nøgle 1 / 15 Kolofon: OIO Referencemodel for tværgående brugerstyring Denne anbefaling kan frit anvendes af alle. Citeres fra anbefalingen i andre publikationer til offentligheden

Læs mere

En teknisk introduktion til NemHandel

En teknisk introduktion til NemHandel En teknisk introduktion til NemHandel 02. december 2014 Indhold INDHOLD... 1 INDLEDNING... 2 STANDARDER... 4 OIOUBL e-handelsstandard... 4 OIORASP - transportprotokol... 5 BETINGELSER FOR ANVENDELSE AF

Læs mere

Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen

Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen Nets Denmark A/S Lautrupbjerg 10 P.O. 500 DK 2750 Ballerup T +45 44 68 44 68 F +45 44 86 09 30 www.nets.eu Brugervejledning - til internetbaseret datakommunikation med Nets ved hjælp af HTTP/S-løsningen

Læs mere

Symantec - Data Loss Prevention

Symantec - Data Loss Prevention Symantec beskyttelse af data/dokumenter Beskrivelsen af Symantecs bud på tekniske løsninger. I beskrivelsen indgår tre følgende løsninger fra Symantec: - Data Loss Prevention - Disk eller ekstern device

Læs mere

DKAL Snitflader REST Register

DKAL Snitflader REST Register DKAL Snitflader REST Register 1 Indholdsfortegnelse A2.1 INTRODUKTION 3 A2.1.1 HENVISNINGER 3 A2.1.2 LÆSEVEJLEDNING 4 A2.1.2.1 SÅDAN LÆSES EN REST GRAF 4 A2.1.2.2 SÅDAN LÆSES EN RESSOURCE OG EN TYPE 4

Læs mere

WHITEPAPER DokumentBroker

WHITEPAPER DokumentBroker WHITEPAPER DokumentBroker Copyright 2013 DokumentBrokeren er en selvstændig arkitekturkomponent, som uafhængigt af forretningsapplikation og kontorpakke, genererer dokumenter af forskellige typer og formater,

Læs mere

FESD Ledelsesinformation

FESD Ledelsesinformation FESD Ledelsesinformation Version 2.1 Standard IT- og Telestyrelsen København den 18. december 2008. FESD-standardisering Ledelsesinformation. Modul. Version 2.1 Kolofon: FESD-standardisering. Ledelsesinformation.

Læs mere

DanID Certification Practice Statement v. 1.1. DanID. Certification Practice Statement (CPS) V. 1.1

DanID Certification Practice Statement v. 1.1. DanID. Certification Practice Statement (CPS) V. 1.1 DanID Certification Practice Statement (CPS) V. 1.1 februar 2009 1 1 Introduktion 1.1 Oversigt DanID A/S (CVR-nr. 30 80 84 60) er et 100% datterselskab ejet af PBS A/S (CVR-nr. 20 01 61 75). Årsregnskaber

Læs mere

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase

Indholdsfortegnelse. Systembeskrivelse kapitel 8 Administrationsdatabase Indholdsfortegnelse 5. Administrationsdatabase... 2 5.1 Metadata... 2 5.2 Administrationsdata... 3 5.2.1 Indstillingsmuligheder... 3 5.2.2 Webside... 4 5.2.3 Klikafgift (Udgået)... 4 5.2.4 Modtageboks...

Læs mere

Att: Mads Ellehammer:

Att: Mads Ellehammer: KL Att: Mads Ellehammer: 27. august 2008 FESD-standardiseringsgruppen har nu færdigbehandlet de indkomne svar til høringen, som løb fra den 22. marts 2008 til 23. maj 2008, og ønsker med dette brev at

Læs mere

Vision om digitale signaturer i Danmark

Vision om digitale signaturer i Danmark Vision om digitale signaturer i Danmark Yih-Jeou Wang kontorchef, IT-sikkerhedskontoret IT- og Telestyrelsen, Danmark Ministerrådet for informationsteknologi (MR-IT) Konferencen Demokratiets fremtid i

Læs mere

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1.

OIO standardservice til Journalnotat. Generel servicevejledning. KMD Sag Version 1.0 01-09-2013. KMD A/S Side 1 af 15. September 2013 Version 1. OIO standardservice til Journalnotat Generel servicevejledning KMD Sag Version 1.0 01-09-2013 KMD A/S Side 1 af 15 Generel servicevejledning til OIO Journalnotat Ekstern standardservice Opdateret 01.09.2013

Læs mere

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5

Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OIOUBL Guideline OIOUBL Kontakt UBL 2.0 Contact G34 Version 1.2 Udgivelsen er beskyttet af Creative Commons license, Navngivning 2.5 OUOUBL Kontakt Version 1.2 Side 1 Kolofon Kontakt: IT- & Telestyrelsen

Læs mere

Høringssvar vedr. Serviceinterface for Person

Høringssvar vedr. Serviceinterface for Person Høringssvar vedr. Serviceinterface for Person 1. Indledning... 3 1.1 Arkitekturmæssige overvejelser... 3 2. Konkrete ændringsforslag... 5 2.1 Variable attributnavne... 5 2.2 Registeroplysninger fra akkreditiv...

Læs mere

Instrukser for brug af it

Instrukser for brug af it it IT-Afdelingen sikkerhed Instrukser i brug af IT Instrukser for brug af it Må Skal ikke Kan Januar 2010 Version 1.0 Indhold Indhold Forord.............................. 3...................... 3 Resumé

Læs mere

Tilslutning til ecomone Basis (OIO Faktura)

Tilslutning til ecomone Basis (OIO Faktura) Tilslutning til ecomone Basis (OIO Faktura) 1. november 2009, Version 1.1 1. POST DANMARKS ECOMONE BASIS (OIO FAKTURA)... 3 1.1 BEGREBER... 3 2 KANALER... 3 3 MODEL FOR DATAUDVEKSLING... 4 4 KOMMUNIKATION...

Læs mere

Termer og begreber i NemID

Termer og begreber i NemID Nets DanID A/S Lautrupbjerg 10 DK 2750 Ballerup T +45 87 42 45 00 F +45 70 20 66 29 info@danid.dk www.nets-danid.dk CVR-nr. 30808460 Termer og begreber i NemID DanID A/S 26. maj 2014 Side 1-11 Indholdsfortegnelse

Læs mere

HÅNDBOG FOR GULDBORGSUND KOMMUNE ACADRE

HÅNDBOG FOR GULDBORGSUND KOMMUNE ACADRE HÅNDBOG FOR GULDBORGSUND KOMMUNE ACADRE Indledning 3 Brug af Acadre 4 Formål 4 Overordnede mål: 4 Konkrete mål: 4 Udviklingsmål (fremtidigt mål) 5 Hvem har adgang til hvad? 5 Adgang og misbrug 5 Postmodtagelse

Læs mere

Mdoc - dit fremtidige ESDH system

Mdoc - dit fremtidige ESDH system Mdoc - dit fremtidige ESDH system Dokumenthåndteringssystemet Mdoc samler alle organisationens dokumenter i ét system. Mdoc håndtere alle typer af dokumenter, e-mails, kontrakter, referater m.v. Samtidig

Læs mere

Brugervejledning. Generering af nøgler til SFTP-løsningen vedrørende. datakommunikation med Nets. Nets A/S - versionsdato 28.

Brugervejledning. Generering af nøgler til SFTP-løsningen vedrørende. datakommunikation med Nets. Nets A/S - versionsdato 28. Nets A/S Lautrupbjerg 10 P.O. 500 DK-2750 Ballerup T +45 44 68 44 68 F +45 44 86 09 30 www.nets.eu CVR-nr. 20016175 Brugervejledning Generering af nøgler til SFTP-løsningen vedrørende datakommunikation

Læs mere

It-sikkerhedstekst ST8

It-sikkerhedstekst ST8 It-sikkerhedstekst ST8 Logning til brug ved efterforskning af autoriserede brugeres anvendelser af data Denne tekst må kopieres i sin helhed med kildeangivelse. Dokumentnavn: ST8 Version 1 Maj 2015 Logning

Læs mere

Signatur- og systembevis Teknisk vejledning i sikring af digitale signaturers bevisværdi Version 1.01

Signatur- og systembevis Teknisk vejledning i sikring af digitale signaturers bevisværdi Version 1.01 Signatur- og systembevis Teknisk vejledning i sikring af digitale signaturers bevisværdi Version 1.01 Publikationen kan også hentes på IT- & Telestyrelsens Hjemmeside: http://www.itst.dk ISBN (internet):

Læs mere

Brugerstyring i Digital Post

Brugerstyring i Digital Post Brugerstyring i Digital Post Denne vejledning beskriver roller og rettigheder i Digital Post Administrationsportalen. Den berører også kort sammenhængen med de roller og rettigheder, der er knyttet til

Læs mere

STS Designdokument. STS Designdokument

STS Designdokument. STS Designdokument STS Designdokument i STS Designdokument STS Designdokument ii REVISION HISTORY NUMBER DATE DESCRIPTION NAME 0.3 2013-01 N STS Designdokument iii Indhold 1 Introduktion 1 2 Arkitekturoverblik 1 2.1 Eksterne

Læs mere

Instrukser for brug af it

Instrukser for brug af it it sikkerhed Instrukser for brug af it Må Skal ikke Kan Januar 2010 Version 1.0 Indhold Forord................................................... 3 Resumé.................................................

Læs mere

NemKonto. XML skemaer for. ukomplette og komplette betalinger. til NKS

NemKonto. XML skemaer for. ukomplette og komplette betalinger. til NKS NemKonto KMD Selma Lagerlöfs Vej 300 9100 Aalborg www.nemkonto.dk NemKonto XML skemaer for ukomplette og komplette betalinger til NKS Version 2.0 19-05-2006 Økonomistyrelsen er ansvarlig for NemKonto,

Læs mere

XML webservice for pensionsordninger. Version 1.0 Draft A

XML webservice for pensionsordninger. Version 1.0 Draft A XML webservice for pensionsordninger Version 1.0 Draft A Dokumentoplysninger Titel: Projekt: Webservice for pensionsordninger EDI kontorets branchekoordinerede dataudveksling Forfatter: Bidragsydere til

Læs mere

NemHandelsRegistret (NHR)

NemHandelsRegistret (NHR) NemHandelsRegistret (NHR) Hjælpeguide til oprettelse i NemHandelsRegistret og registrering af profiler. Januar 2015 Version 1.1 Introduktion Hvis en virksomhed eller en offentlig myndighed ønsker at kunne

Læs mere

Digital post Snitflader Bilag A2 - REST Register Version 6.3

Digital post Snitflader Bilag A2 - REST Register Version 6.3 Digital post Snitflader Bilag A2 - REST Register Version 6.3 1 Indholdsfortegnelse A2.1 INTRODUKTION 4 A2.1.1 HENVISNINGER 4 A2.2 OVERSIGT OVER FUNKTIONSOMRÅDE 5 A2.2.1 OPRET / HENT OPLYSNINGER OM SLUTBRUGER

Læs mere

UDSNIT 8. februar 2008

UDSNIT 8. februar 2008 UDSNIT 8. februar 2008 Dette udsnit indeholder indeholder en introduktion til hvad begrebet brugerstyring dækker over Kolofon: OIO Referencemodel for tværgående brugerstyring Dette baggrundsdokument kan

Læs mere

Forløbsbeskrivelse for Digital Forvaltning (44405)

Forløbsbeskrivelse for Digital Forvaltning (44405) Forløbsbeskrivelse for Digital Forvaltning (44405) Modul Tema Indhold og form Materialer Dag 1 1 / 1 Introduktion Velkomst. Præsentation af kursus, deltagere og lærer Program for kurset 1 / 2 Rundt om

Læs mere

Arbejdsgange og retningslinier vedr. brug af KMD-SAG-EDH

Arbejdsgange og retningslinier vedr. brug af KMD-SAG-EDH FAABORG-MIDTFYN KOMMUNE Arbejdsgange og retningslinier vedr. brug af KMD-SAG-EDH KMD-sag-edh Side 1 af 10 MÅL MED ELEKTRONISK DOKUMENTHÅNDTERING 4 AFGRÆNSNING 4 SIKKERHED 4 DOKUMENTER 5 Dokumentdefinition

Læs mere

Vejledning i opsætning af NemHandelsprogrammet

Vejledning i opsætning af NemHandelsprogrammet Vejledning i opsætning af NemHandelsprogrammet Kort om NemHandelsprogrammet Hvis du har et økonomisystem, som kan skabe NemHandelsfakturaer, kan du kombinere økonomisystemet med det gratis NemHandelsprogram,

Læs mere

Effektiv sagsbehandling og hurtig borgerservice

Effektiv sagsbehandling og hurtig borgerservice Effektiv sagsbehandling og hurtig borgerservice 360 Kommuneløsning Med udvidet borgerselvbetjening og tværgående digitale arbejdsgange er kommunen efterhånden blevet borgernes primære kontaktpunkt til

Læs mere

LUDUS Web Installations- og konfigurationsvejledning

LUDUS Web Installations- og konfigurationsvejledning LUDUS Web Installations- og konfigurationsvejledning Indhold LUDUS Web Installations- og konfigurationsvejledning... 1 1. Forudsætninger... 2 2. Installation... 3 3. Konfiguration... 9 3.1 LUDUS Databasekonfiguration...

Læs mere

BESTILLING AF NEMID. For at bestille ny NemID vælger du www.nets-danid.dk. Vælg Bestil NemID medarbejdersignatur.

BESTILLING AF NEMID. For at bestille ny NemID vælger du www.nets-danid.dk. Vælg Bestil NemID medarbejdersignatur. BESTILLING AF NEMID For at bestille ny NemID vælger du www.nets-danid.dk Vælg Bestil NemID medarbejdersignatur. CVR nummeret trækker automatisk adressen fra CVR registeret, så den skal IKKE ændres. Bekræft

Læs mere

Vejledning til prækvalifikation. Rev.: 2015-05-27 / LW. Side 1

Vejledning til prækvalifikation. Rev.: 2015-05-27 / LW. Side 1 Vejledning til prækvalifikation Rev.: 2015-05-27 / LW Side 1 Indhold Indhold... 2 Indledning... 3 Log på... 4 Opret din bruger... 4 Personlige informationer... 4 Gem login... 5 Glemt password... 5 Brugerfladen

Læs mere

1 INTRODUKTION TIL DKAL SNITFLADER 3

1 INTRODUKTION TIL DKAL SNITFLADER 3 DKAL Snitflader 1 Indholdsfortegnelse 1 INTRODUKTION TIL DKAL SNITFLADER 3 1.1 ANVENDELSE AF OIOXML 3 2 SNITFLADEOVERSIGT 3 2.1 REST 5 2.1.1 HTTP RETURKODER OG FEJLKODER 6 2.1.2 WEBSERVICE 6 2.2 AFSENDELSE

Læs mere

Undgå driftsafbrydelser på grund af udløbet virksomheds- eller funktionssignatur

Undgå driftsafbrydelser på grund af udløbet virksomheds- eller funktionssignatur Side 1 af 5 Vejledning 2. august 2013 NITRI Undgå driftsafbrydelser på grund af udløbet virksomheds- eller funktionssignatur Indholdsfortegnelse Formål...2 Virksomhedssignatur...2 Funktionssignatur...3

Læs mere

e-tinglysning Digital signering

e-tinglysning Digital signering e-tinglysning Digital signering Søren Gjesse Business Systems Architect e-mail: sgjesse@csc.com Bjarne Hansen Business Systems Architect e-mail: bhansen4@csc.com Indledning Digital Signering i e-tinglysning

Læs mere

Digital Signatur Forudsætninger og fordele

Digital Signatur Forudsætninger og fordele Digital Signatur IT- og Telestyrelsen December 2002 Resumé Udbredelsen af en fælles standard for digital signatur styrker offentlige myndigheders muligheder for at udvikle nye og mere avancerede nettjenester,

Læs mere

Snitfladebeskrivelse HentYdelseInformation BYS P11-4 KMD Børneydelse Version 1.0.0, 2012.05.22

Snitfladebeskrivelse HentYdelseInformation BYS P11-4 KMD Børneydelse Version 1.0.0, 2012.05.22 Snitfladebeskrivelse HentYdelseInformation BYS P11-4 KMD Børneydelse Version 1.0.0, 2012.05.22 Indholdsfortegnelse Indholdsfortegnelse Ændringer i forhold til forrige version... 2 1 Brug af snitfladebeskrivelsen...

Læs mere

Call Recorder Apresa Brugermanual

Call Recorder Apresa Brugermanual Call Recorder Apresa Brugermanual Version. 1.100.11 Vidicode Pleje og vedligeholdelse: CR Apresa må ikke blive våd. Hvis den bliver våd, tør den omgående af med en blød, ren klud. Væsker kan indeholde

Læs mere

Automatisk og obligatorisk tilslutning. Hvis du blev tilmeldt Digital Post inden 1. november 2014. Mulighed for fritagelse

Automatisk og obligatorisk tilslutning. Hvis du blev tilmeldt Digital Post inden 1. november 2014. Mulighed for fritagelse Automatisk og obligatorisk tilslutning 1. november 2014 blev det lovpligtig at være tilsluttet Digital Post fra det offentlige. Denne dato skete der derfor en automatisk og obligatorisk tilslutning for

Læs mere

Dataudvekslingsaftale vedrørende tilslutning til NemRefusions Virksomhedsservice

Dataudvekslingsaftale vedrørende tilslutning til NemRefusions Virksomhedsservice Dataudvekslingsaftale vedrørende tilslutning til NemRefusions Virksomhedsservice Dato: Ref.: Mellem og KOMBIT A/S Formål Formålet med denne aftale er at fastlægge de tekniske krav til kommunikationen mellem

Læs mere

Digitale boligstøtteansøgninger. En administrativ fordel med voksende effekt for både borgere og administration

Digitale boligstøtteansøgninger. En administrativ fordel med voksende effekt for både borgere og administration Digitale boligstøtteansøgninger En administrativ fordel med voksende effekt for både borgere og administration JUNI 2003 1 Titel: Digitale boligstøtteansøgninger En administrativ fordel med voksende effekt

Læs mere

4. Sikkerhed i EDIFACT

4. Sikkerhed i EDIFACT 05.05.2000 4. Sikkerhed i EDIFACT 1. Indledning... 2 2. Kravene til sikkerhed... 2 3. Standardisering... 2 4. TeleSeC... 3 4.1 Formål... 3 4.2 TeleSeC-egenskaber... 3 4.3 TeleSeC-opbygning... 4 4.4 Certifikater...

Læs mere

Indberetning til eindkomst via SFTP. Folder: J:\Kunder\eIndkomst Projektdokumentation\SFTP\Vejledninger\EC SFTP_eIndkomst 2008-01-22.

Indberetning til eindkomst via SFTP. Folder: J:\Kunder\eIndkomst Projektdokumentation\SFTP\Vejledninger\EC SFTP_eIndkomst 2008-01-22. Indberetning til eindkomst via SFTP Forfatter: IBM Emne: Indberetning til eindkomst via SFTP Side 1 af 9 Dokumenthistorik Revisionshistorik Dato for denne revision: 22.01.2007 Dato for næste revision:

Læs mere