OIO-it-arkitekturkomitémøde, 13. december 2007 Pkt. 1. Dagsorden ...

Cover 

Dagsordenspunkt 1, OIO-it-arkitekturkomitéen, 13. december 2007 

Orientering/Beslutning 

OIO-it-arkitekturkomitémøde, 13. december 2007 

Pkt. 1. Dagsorden 

Sagstype: Orientering/Beslutning 

Dagsorden 

Velkomst godkendelse af dagsorden og referat (O/B) 

1. Velkomst godkendelse af dagsorden og referat fra mødet d. 11. oktober 

2007 (O/B) 

2. Meddelelser (O) 

3. Godkendelse af dansk SAML 2.0 føderationsprofil (B) 

4. Status på tiltag for konvergens af standarder indenfor føderationsområdet 

(O) 

5. Godkendelse af OIO RASP og OIO UDDI (B) 

6. Standardiseringsorganisationers åbenhed (D) 

7. Oversigt over standarder og beslutning om prioritering af tekniske 

standarder (O/B) 

8. Vejledning om åbne dokumentformater (O) 

9. Arkitekturkrav (D) 

10. Eventuelt (O) 

Punkter mærket B, D, E, O er til henholdsvis: 

(B) Beslutning 

(D) Drøftelse 

(E) Efterretning 

(O) Orientering 

5. december 2007 

IT- og Telestyrelsen 

Sagsbehandler 

Kasper Færgemann 

Telefon 3337 9215 

Telefax 3337 9299 

E-post kaf@itst.dk

Cover 

Dagsordenspunkt 1, referat fra mødet den 11. oktober 2007, OIO-itarkitekturkomitéen, 

13. december 2007 

Orientering/Beslutning 


Pkt. 1. Referat fra mødet den 11. oktober 

Sagstype: Orientering/Beslutning 

Deltagere: 

Michael Busk-Jepsen, IT- og Telestyrelsen 

Michael Bang Kjeldgaard, IT- og Telestyrelsen 

Jeannette Nielsen, IT- og Telestyrelsen 

Kasper Færgemann, IT- og Telestyrelsen 

Søren Klostergaard Pedersen, IT- og Telestyrelsen 

David Graff Nielsen, Erhvervs- og Selskabsstyrelsen 

Helle Martinussen, Miljøministeriet 

Torben Sløk-Andersen, Vejdirektoratet 

Anders Bo Nielsen, Rigsarkivet 

Jan Danielsen, Københavns Kommune 

Peter Madsen, Indenrigs- og Sundhedsministeriet 

Afbud: 

Vagn Lauersen 

Michael Hald, KL 

Stefan Lars Jensen, Region Hovedstaden 

Kristian Hjort-Madsen, Den Digitale Taskforce 

Henrik Karsbøl, Rektorkollegiet 

Referat 

1. Velkomst Godkendelse af dagsorden og referat fra møde d. 

30.08.07 (O/B) 

Velkomst ved Michael Busk-Jepsen, IT- og Telestyrelsen. Bordrunde og 

velkomst. Referat fra mødet d. 30. august blev godkendt uden bemærkninger. 

Dagsordenen til dagens møde blev ligeledes godkendt. 

2. Meddelelser (O) 

Orientering ved Michael Busk-Jepsen. 

Brugerstyring 



Sagsbehandler 

Kasper Færgemann 

Telefon 3337 9215 

Telefax 3337 9299 

E-post kaf@itst.dk

Styregruppen omkring brugerstyring er blevet enige om en single-sign-on til 

portaler.Den nye borgerportal går i luften i løbet af 2008. Det er meningen, at alle 

skal være i stand til at logge på. 

Åbne standarder 

Regeringen og de kommunale parter har truffet beslutninger om åbne standarder. 

Det betyder, at B 103 skal gælde for hele den offentlige sektor. Den danske 

beslutning om anvendelsen af obligatoriske åbne standarder på tværs i det 

offentlige får bred udenlandsk interesse. 

E-business 

Videnskabsministeriet og Rådet for Teknologi og Innovation har etableret et nyt 

center for e-Business, http://www.ibiz-center.dk. Centret etableres i et 

samarbejde mellem Teknologisk Institut og Delta. 

Videnskabsministeren åbnede d. 8. oktober en ny konference om Nem e- 

Business, hvor et nyt initiativ, NemHandel, blev lanceret. Initiativet skal gøre det 

muligt at sende forretningsdokumenter hurtigt og sikkert via internettet. 

OIO EA kurser 

IT- og Telestyrelsen afholder kursus i anvendelsen af OIO EA. Der afholdes både 

kurser for offentlige myndigheder og kurser målrettet for OIO leverandører. 

Kurserne afholdes i Århus, Odense og København. Læs mere på: 

http://ea.oio.dk/arrangement 

3. Vurderingskriterier for standarder (B) 

Oplæg til beslutning ved Søren Klostergaard Pedersen, IT- og Telestyrelsen. 

Hele oplægget kan findes på: 

http://www.itst.dk/arkitektur-og-standarder/fora/arkitekturfora/oio-itarkitekturkomiteen/moder/mode-i-it-arkitekturkomiteen-den-11-10.07 

Det fremlagte beslutningsforslag er stort set identisk med høringsversionen 

af anvendelsesrapporten. Den eneste ændring er, at tilgængelighed er 

indarbejdet som et krav på opfordring fra Dansk Blindesamfund i 

høringsperioden. 

I forlængelse af oplægget blev det diskuteret, hvorvidt antallet af 

vurderingskriterier var passende. 

Bl.a. blev det foreslået, at man grafisk opererer med simple farvekoder: rød, 

gul og grøn. Man fastholder dog stadig en registrering på de foreslåede 

niveauer, men for at lette overblikket vises standarderne i en eventuel 

oversigt kun i forhold til tre farvekoder. 

OIO kataloget vil i fremtiden revurdere standarder ud fra de foreslåede 

vurderingskriterier. 


Side 2

Beslutningsforslaget for vurderingskriterier for standarder blev herefter 

godkendt. 

4. Køreplan for arbejdet med OIO-kataloget (O) 

Orientering ved Søren Klostergaard Pedersen. Hele oplægget kan hentes 

her: 


I arbejdet med OIO kataloget foregår der i øjeblikket en undersøgelse af, 

hvor mange standarder, der skal have ændret status. Omfanget ser ud til at 

være omkring 15 standarder, mens forventning var omkring 60. 

Gennemgangen af standarder med henblik på revidering af status forventes 

afsluttet ultimo oktober. Indtil videre følger arbejdet planen. 

5. Pilotforsøg om åbne dokumentformater kort om vejledning (D) 

Præsentation ved Tim Hansen, Devoteam, projektansat i IT- og Telestyrelsen i 

forbindelse med pilotforsøget om åbne dokumentformater. 

Oplægget kan hentes her: 


Status på projektet er, at alle pilottest er i gang, laboratorietesten er i gang, 

og parathedsvurderingen forventes udsendt inden længe. Fokus vil i den 

kommende tid gå på at få høstet resultaterne af disse undersøgelser og få 

omsat dem i vejledningsindsatsen. 

En af de ting man bl.a. kan læse i vejledningen er, at Edag 1 og edag2 

beslutningen står stadig ved magt, f.eks. i forbindelse med pdf. Det obligatoriske 

krav er, at I skal kunne modtage i formaterne og håndtere formaterne. Internt i 

jeres myndigheder, er det i forlængelse heraf relevant at overveje, hvilket 

ambitionsniveau I har. 

På projektets hjemmeside, http://dokumentformater.oio.dk, er der lavet en 

konverteroversigt, som det vil være relevant, at I som myndighed kigger på. 

Hvorvidt I har behov for en kvalitetssikringsprocedure er op til de enkelte 

myndigheder. 

Man kunne evt. forestille sig, at flere myndigheder deltog i et samarbejde for at 

få defineret behovene. Det besværlige er, at ingen konverter passer på alle, da 

implementeringen foregår meget forskelligt i hver enkelt myndighed. 

I pilotforsøg er det forsøgt at lave en repræsentativ opdeling, så både det 

statslige, kommunale og det regionale område dækkes. I pilotforsøget er metoden 

defineret, så nye konvertere relativt let kan sættes ind i systemet og prøvekøres. 

6. Høringer, oversigt over standarder (O) 


Side 3

Orientering ved Kasper Færgemann, IT- og Telestyrelsen. 

Der blev i forbindelse med fremlæggelse af oversigten over standarder stillet 

spørgsmål til, hvornår BPMN, en ny standard for forretningsprocesser, som 

afventer WS-BPEL, forventes. KL anvender allerede p.t. BPMN-standarden. 

Fra IT- og Telestyrelsens side blev det meldt ud, at man gennem en intern høring 

vil undersøge status og tidshorisont for BPMN-standarden frem til næste 

komitémøde. 

Det blev desuden bemærket, at WiMax måske hører hjemme i en anden sølje i 

IT- og Telestyrelsen. 

7. IT-arkitekturkonferencen 2008 (D) 

Oplæg til drøftelse ved Michael Bang Kjeldgaard, IT- og Telestyrelsen. Et 

programudkast blev omdelt til deltagerne på mødet. 

Overskriften for IT-arkitekturkonferencen 2008 er Efter reformerne med fokus 

på: 

Governance 

Modernisering 

EA 

Åbne standarder 

PÅ baggrund af forskellige inputs gennemløber programmet en række revisioner. 

En af de overordnede tendenser er dog mindre teori og mere praksis med oplæg 

fra dem der har praktiske erfaringer. 

Sessionerne vil blive forlænget med et kvarter til en time, så der minimum er et 

kvarter til spørgsmål og diskussion. Derudover vil der blive afholdt flere seancer 

i den store sal. Farvekoderne i programmet henviser til formidlingsformen, dvs. 

om der er tale om et plenumoplæg, en session eller en minitutorial. 

Hvad angår forskellen på governance og styring, så henviser governance til den 

overordnede dagsorden, mens styringssporet kigger mere på styringen af det 

enkelte projekt. 

Umiddelbart ligner mange af overskrifterne på programmet, overskrifterne fra 

sidste år, men der vil altid være mulighed for at finde andre spor, da flere spor 

kører simultant. 

Det blev foreslået, at starttidspunktet rykkes til kl. 10, da det ellers kan blive 

meget svært at nå konferencens start for deltagere fra København. 

Lean i det offentlige blev desuden foreslået som sessionsemne. 

8. Arkitekturkrav (O) 

Orientering ved Leif Andersen, IT- og Telestyrelsen. Læs hele oplægget her: 



Side 4

Projektet om arkitekturkrav tager udgangspunkt i digitaliseringsstrategiens 

initiativ 32 er og gennemføres af IT-arkitekturkontoret i IT- og 

Telestyrelsen. Komitéen forventes at spille en central rolle i gennemførelsen 

af projektet, herunder fastlæggelse af koncept og konkrete anbefalinger til 

den fremtidige portefølje af krav samt ramme for porteføljestyring og 

måling af fremdrift. 

Et arkitekturkrav er, et princip om anvendelse af en arkitekturkomponent 

(et princip eller et løsningsmønster) (herunder metoder, platforme, teknikker 

og standarder). 

Projektet vil prioritere at identificere krav/principper med stor 

samfundsmæssig værdi. Projektet skal kunne måle, at arkitekturkravene 

giver værdi i anskaffelsesprocessen. Der er et potentiale i, at det man 

kalder model på forretningsniveau også samtidig skal forholde sig til form. 

Fremdriften som skal måles, er en fremdrift i overholdelse af 

arkitekturkrav/principper, ikke nødvendigvis en måling af fremdrift i 

forhold til økonomi. Som udgangspunkt vil der i mange tilfælde allerede 

være lavet en business case, som undersøger, hvor meget værdi en given 

service giver, f.eks. elektronisk faktura. 

I drøftelsen blev bl.a. bemærket, at det kunne være interessant at medtage 

specifikke versionskrav til softwaren. I et konkret projekt, ekalender, var det 

faktisk en nødvendighed at have en nyere version af Outlook for at kunne få 

adgang til ekalender. Dette forhold kunne sagtens være gældende med 

meget andet software i andre projekter. 

9. Komitéens fremtidige rolle og arbejdsopgaver (D/B) 

Oplæg til beslutning ved Michael Bang Kjeldgaard. 

Komitéens fremtidige rolle og arbejdsopgaver har flere gange været drøftet i 

komitéen. IT- og Telestyrelsen foreslår nu, at OIO it-arkitekturkomitéen og 

OIO Datastandardiseringskomitéen slås sammen. Sagen drøftes nu parallelt 

i de to komitéer og lægges derefter til beslutning i KIU. 

Planen er, at mest muligt af sagsbehandlingen lægges ud i domænekomitéerne, 

eller specifikke arbejdsgrupper. 

Både hvad angår data- og tekniske standarder, er kompetencen i komitéerne ikke 

på nuværende tidspunkt stærk nok. Fokus er at få styrket governance. 

Beslutningsforslag blev godkendt af komitéen. 

10. En indgang til åbne standarder (O) 

Orientering ved Cecile Christensen, IT- og Telestyrelsen. 

IT- og Telestyrelsen har påbegyndt en gennemgribende videreudvikling og 


Side 5

samling af eksisterende og planlagte arkitektur- og 

standardiseringsplatforme. 

Med udgangspunkt i InfoStrukturBasen, OIO-kataloget og et annonceret 

Fællesoffentligt Servicekatalog, er det målet at lave én indgang til åbne 

standarder, offentlig arkitektur og standardisering. Det ambitiøse 

udviklingsprojekt er et samarbejde mellem Datastandardiseringskontoret, 

IT-arkitekturkontoret og Center for 

Serviceorienteret Infrastruktur. 

De forskelligee dele af ISB en skal kunne fungere hver for sig. Målet er at 

udbyde en fleksibel løsning med delleverandører, hvor det hele er samlet i én 

løsning. Udviklingen bliver lettere, når vi selv har rettighederne til de enkelte 

delelementer. 

Den nye ISB har haft udgangspunkt i den gamle ISB som en samling for 

datastandarder, men ISB2 vil være bredere orienteret end den gamle ISB. 

11. Evt. (O) 

Der var ingen bemærkninger under eventuelt. 

(B) Beslutning 

(D) Drøftelse 

(E) Efterretning 

(O) Orientering 


Side 6

Cover 


Beslutning 


Pkt. 3, Godkendelse af dansk SAML 2.0 føderationsprofil (B) 

Sagstype: Beslutning 

Resumé 

Center for Serviceorienteret Infrastruktur har haft dansk SAML 2.0 

føderationsprofil i offentlige høring i eftersommeren 2007. Profilen foreskriver 

reglerne for tværgående SSO, som blandt andet Borgerportalen v2.0 er afhængig 

af. Der indkom 16 høringssvar, som generelt støttede det hørte profil-udkast. 

Svarene har givet anledninger til mindre præciseringer, herunder ændring af 

profilens navn til: OIO Web SSO Profile V2.0. 

Der er dog ikke foretaget væsentlige indholdsmæssige ændringer i forhold til det 

hørte udkast. 

Sagsfremstilling 

Version 2.0 af den danske SAML 2.0 profil samt et bilag med eksempler har 

været i høring på høringsportalen fra 20. august til 21. september 2007. 

Til advisering af høringen er anvendt udsendelseslisten knyttet til OIO 

Standarder samt en række særlige interessenter udvalgt af Styrelsen. 

Der indkom i alt 16 svar på høringen fra flg. organisationer: KMD, Novell 

Danmark, Region Hovedstaden, Region Syddanmark, Datatilsynet, 

Statsbiblioteket/DKAAI, Trafikstyrelsen, Banedanmark, Computer Associates, 

Erhvervs- og Byggestyrelsen, Økonomi- og Erhvervsministeriet, 

Forsvarsministeriet, IBM, Integrationsministeriet, Justitsministeriet / 

Departementet og Oracle. 

Derudover har en række internationale eksperter fra bl.a. HP og Liberty bidraget 

med kommentarer separat fra den formelle høringsproces. 

Blandt ovennævnte svarere havde flg. organisationer egentlige kommentarer til 

profilens indhold: KMD, Novell Danmark, Region Hovedstaden, Region 

Syddanmark, Datatilsynet, Statsbiblioteket/DKAAI og IBM. Disse har alle været 

inviteret til møder i Styrelsen med henblik på dybere drøftelser og forklaringer. 

De øvrige svarere har enten oplyst, at de ingen kommentarer havde til profilen, 

tilkendegivet tilfredshed med profilen, at deres kommentarer allerede var givet 

som en del af det forudgående forløb, eller oplyst om understøttelse i produkter. 

Generelt har mange udtrykt tilfredshed med valget af den åbne SAML 2.0 



Sagsbehandler 

Søren Peter Nielsen 

Telefon 2567 0783 

Telefax 3337 9299 

E-post spn@itst.dk

standard fra OASIS som fundament for den fællesoffentlige brugerstyring, 

ligesom der udtrykkes støtte til Styrelsens arbejde med at etablere en lokal dansk 

profil af denne. Derudover kan det nævnes, at en række leverandører udtrykker, 

at deres produkter vil kunne understøtte praktiske implementationer af profilen. 

En anden generel tilbagemelding fra høringssvarerne har været, at man ser behov 

for yderligere profiler i den nærmeste fremtid, eksempelvis i forbindelse med 

identitetsbaserede web services. Styrelsen er enig i mange af disse overvejelser 

og vil adressere disse behov og ønsker via arbejdet i Center for Serviceorienteret 

Infrastruktur og i samspil med faserne i det fællesoffentlige 

brugerstyringsprojekt. 

Indstilling 

Det indstilles, at komitéen godkender OIO Web SSO Profile V2.0 

Bilag 

Høringsnotat vedrørende godkendelse af dansk SAML 2.0 

føderationsprofil 

Dokument som opsummerer profilkravene - OIO Web SSO Profile V2.0 - 

Requirements Summary 

Følgende dokumenter kan hentes på: 

http://www.itst.dk/arkitektur-og-standarder/fora/arkitekturfora/oio-itarkitekturkomiteen/moder/mode-i-it-arkitekturkomiteen-den-13-12-07 

OIO Web SSO Profile V2.0 - version til godkendelse i OIO-itarkitekturkomitéen 

OIO Web SSO Profile V2.0 - version med angivelse af ændringer siden 

høringsversionen 

OIO Web SSO Profile - Examples V1.3 - dokument med eksempler fra 

anvendelse af profilen 


Side 2

Baggrundsnotat 

Dagsordenspunkt 3 , OIO-it-arkitekturkomitéen, 13. december 2007 

Behandles som: Beslutning 


Pkt. 3, Høringsnotat vedrørende godkendelse af dansk SAML 2.0 

føderationsprofil (B) 

Den danske profil vedrørende Web Single Sign-on (SSO) benævnes i det 

følgende DK-SAML 2.0. Profilen samt et bilag med eksempler har været i høring 

på høringsportalen fra 20. august til 21. september 2007. 

Til advisering af høringen er anvendt udsendelseslisten knyttet til OIO 

Standarder samt en række særlige interessenter udvalgt af Styrelsen. 

Der indkom i alt 16 svar på høringen fra flg. organisationer: KMD, Novell 

Danmark, Region Hovedstaden, Region Syddanmark, Datatilsynet 1 , 

Statsbiblioteket/DKAAI, Trafikstyrelsen, Banedanmark, Computer Associates, 

Erhvervs- og Byggestyrelsen, Økonomi- og Erhvervsministeriet, 

Forsvarsministeriet, IBM, Integrationsministeriet, Justitsministeriet / 

Departementet og Oracle. 

Derudover har en række internationale eksperter fra bl.a. HP og Liberty bidraget 

med kommentarer separat fra den formelle høringsproces. 

Blandt ovennævnte svarere havde flg. organisationer egentlige kommentarer til 

profilens indhold: KMD, Novell Danmark, Region Hovedstaden, Region 

Syddanmark, Datatilsynet, Statsbiblioteket/DKAAI og IBM. Disse har alle været 

inviteret til møder i Styrelsen med henblik på dybere drøftelser og forklaringer. 

De øvrige svarere har enten oplyst, at de ingen kommentarer havde til profilen, 

tilkendegivet tilfredshed med profilen, at deres kommentarer allerede var givet 

som en del af det forudgående forløb, eller oplyst om understøttelse i produkter. 

Generelt har mange udtrykt tilfredshed med valget af den åbne SAML 2.0 

standard fra OASIS som fundament for den fællesoffentlige brugerstyring, 

ligesom der udtrykkes støtte til Styrelsens arbejde med at etablere en lokal dansk 

profil af denne. Derudover kan det nævnes, at en række leverandører udtrykker, 

at deres produkter vil kunne understøtte praktiske implementationer af profilen. 

En anden generel tilbagemelding fra høringssvarerne har været, at man ser behov 

for yderligere profiler i den nærmeste fremtid, eksempelvis i forbindelse med 

identitetsbaserede web services. Styrelsen er enig i mange af disse overvejelser 

1 Datatilsynets svar kom senere end de øvrige svar på høringsportalen, da datatilsynet ved 

en fejl ikke blev adviseret ved høringens start.. 

26. november 2007 


Sagsbehandler 


Telefon 2567 0783 

Telefax 3337 9299 


og vil adressere disse behov og ønsker i senere faser af det fællesoffentlige 

brugerstyringsprojekt. 

Nedenfor gennemgås høringssvarene punkt for punkt sammen med Styrelsens 

svar. Høringssvarene er redaktionelt opdelt i enkeltpunkter, dersom den indsendte 

tekst ikke måtte være det. Endvidere er nedenfor kun medtaget svar, der går på 

profilens indhold, og således ikke leverandørers oplysninger om mulig 

produktunderstøttelse, støttetilkendegivelser mv. 

Som konsekvens af høringssvarene er der planlagt en opdatering af profilen i en 

revideret udgave. I den reviderede udgave redegøres for ændringerne i forhold til 

høringsversionen. 

Kommentarer fra Novell 

Kommentar 1 

SAML2 is better for B2B services, where everything is administrator driven, 

Liberty is better in B2C or B2B services, where the user is given more control of 

their identity. The latter becomes important as the evolution of DK SAML will 

begin to encompass the option to allow more granular user governed 

authorizations (DK: fuldmagt), in such a way that individual citizens can grant 

access to specific private information and change rights to specific groups or 

individuals within the governmental sector such as Healthcare, Social Services 

and so on and so forth (see section 11.4 in the hearing document). The evolution 

of this functionality is driven by the Identity Governance Framework initiative 

driven by Liberty. The hearing document states that it will be considered as it 

matures into standardization, but the base platform is already well established 

and we recommend that current COTS implementations of this functionality ( as 

in Novell Access Manager 3) are deployed to test and evaluate possible near term 

and long term implementations. 

Styrelsens svar 

Som en generel arkitekturmæssig betragtning er det korrekt, at Liberty har flere 

faciliteter i sit rammeværk. Vigtigt er dog også udbud af kommercielle produkter 

og services, som understøtter de valgte standarder. Det vil blive vurderet, hvilke 

af dele af Liberty rammeværket så vel som andre standarder, det kan være 

relevant at inddrage i kommende brugerstyringsprofiler. 

Kommentar 2 

Taking not only necessary core user attributes to complete authentication 

assertions into consideration, the potential of Federated Provisioning should be 

considered and the basic attribute requirements for user object creation in the 

most predominant directories/name systems in the governmental sector. 


"Federated Provisioning" er udenfor scope af SAML profilen, men er som 

sådan relevant for brugerstyringsprojektet, som vil behandle emnet i senere 

faser af projektet. 

2 


Side 2

Kommentarer fra KMD 

Kommentar 3 

Ifølge dokumentets forside er profilen udgivet af Center for 

Serviceorienteret Infrastruktur (CSI), som også har udsendt andre profiler og 

standarder. De øvrige profiler navngives med prefix OIO hvorimod denne 

prefikses med DK. Det står ikke helt klart hvorfor denne profil sættes i en 

DK kontekst i mod-sætning til de andres OIO kontekst. Udover den enkle 

forskel i navngivning, er der en stor forskel i OIO og DK 

profildokumenternes disposition. OIO-profilerne er rene specifikationer med 

tydelig angivelse af hvilke OIO-præciseringer der er lavet i forhold til 

bagved liggende internationale standarder, suppleret med anvendelses-, 

implemente-rings- og argumentationsdokumenter. Det foreliggende DK- 

SAML dokument indeholder lidt af det hele udover selve specifikationen. 

Desuden er der nogle unødige historiske henvisninger til tidligere udgaver 

af DK-SAML. En fælles konsekvent redaktionel stil for alle CSI profiler bør 

overvejes, og KMD vil anbefale at stilen fra OIO-profilerne anvendes 

generelt til alle CSI profil specifikationer. 


Styrelsen har valgt at følge den redaktionelle stil fra de internationale 

OASIS SAML-standarder, som profilen knytter sig til, fremfor stilen i OIO 

dokumenterne. Dette gælder såvel navngivning, layout og indhold, hvor 

profilen eksempelvis indeholder de bagvedliggende use cases og scenarier, 

som det kendes fra OASIS dokumenterne. Dette valg er skønnet at 

fremhæve de forståelsesmæssige aspekter af dokumentet. 

Styrelsen har dog besluttet at udarbejde et separat dokument med et resumé 

med de normative krav i punktform. 

Kommentar 4 

Da profilen klart relaterer sig til tidligere CSI udgivelser som har fire 

forskellige scenarier, vil det være hensigtsmæssigt at få redegjort for 

hvordan profilen tænkes anvendt i forhold til netop de fire scenarier, specielt 

hvis profilen har preference for nogle af scenarierne. Denne beskrivelse er 

ikke en del af specifikationen, men et tilhørende anvendelsesdokument. 


Her er det uklart, om der tænkes på de fire scenarier i dokumentet 

"Anbefaling om fælles arkitektur for tværgående autentitetssikring". I givet 

fald kan man sige, at profilen beskriver nye scenarier og flows der afspejler, 

at arkitekturen er blevet ændret (bl.a. er autentitetssikringsportalen ikke 

med). Endvidere beskriver profilen i afsnit 1.2 baggrunden for ændringerne 

og i appendix A findes en detaljeret oversigt over profilændringer. 

3 


Side 3

Styrelsen vil i forbindelse med godkendelse af profilen opdatere det nævnte 

arkitektur-dokument med information om at dette dokument ikke længere er 

gældende. 

Kommentar 5 

Den valgte profil forudsætter, at der etableres et common domain, til at 

hånd-terer udvekslingen af SAML tokens i cookies. KMD finder det 

betænkeligt, at man udelukker andre udvekslingsmekanismer, der ikke har 

denne begrænsning. Hermed bliver anvendelsen af hele den digitale 

infrastruktur afhængig af, at dette common domæne er tilgængeligt. 

Ydermere udelukkes supplerende autentifikationstjenester i at deltage i en 

mere bred Single Signon med risiko for at der skabes en lukket anvendelse, 

hvor det vanskeliggøres at etablere samarbejdenede 

autentifikationstjenester. Det bør være et styrende princip at der tilstræbes 

mest mulig åbenhed med frie muligheder for deltagelse og udbydelse af 

services. Hvis der vælges afgrænsninger bør det ske i 

implementeringsmodellen og ikke i profil specifikationen. 


Baggrunden for valget er, at common domain metoden er pt. den eneste 

standardiserede metode til "IdP discovery", som er en vigtig mekanisme i 

føderationer. Der findes således både en OASIS profil og bred 

produktunderstøttelse for denne. Det skal endvidere understreges, at cookies 

ikke bliver brugt til transport af data. 

Det er uklart, hvad der menes med, at domænet skal være tilgængeligt?! 

Domænet vil bestå af en række (logiske) servere hos Service- og Identity 

Providere, men det giver så vidt det kan vurderes ikke anledning til nye 

problemstillinger i forhold til tilgængelighed. Brug af common domains 

udelukker endvidere ikke, at der kan opereres med flere uafhængige Identity 

Providers - tværtimod giver det en løsere kobling mellem Service og 

Identity Providere. 

Kommentar 6 

Det er hensigtsmæssigt, at det sæt af attributter der sættes til mandatory, i sig selv 

er tilstrækkeligt til formålet. Der er i profilen optional attributter med 

informationer som allerede er til stede i mandatory delen. Håndteringen af mange 

optionelle felter, der tilfører redundant information, kan gøre en implementering 

unødigt omkostningskrævende og giver mulighed for inkonsistent information. 

Vi finder at det kunne være en fordel for præcisionen i kommende 

implementeringer, at der var færre optional attributter. 


At attributinformation kan optræde på flere måder skyldes ønsket om at efterleve 

forskellige typer anbefalinger, herunder fællesoffentlige anbefalinger om 

kerneattributter samt anbefalinger i "SAML Deployment Profile Draft for X.509 

Subjects". Disse giver et vist overlap. Styrelsen vurderer det som usandsynligt at 

4 


Side 4

optionelle attributter vil skabe interoperabilitetsproblemer, da Service og Identity 

Providere i praksis altid vil skulle indgå en rækker aftaler - herunder aftale en 

attributkontrakt. 

Styrelsen vil dog tydeliggøre i profilen, hvorledes valg mellem forskellige 

attributprofiler kan ske, samt hvad der er obligatorisk og valgfrit. 

Kommentarer fra Erhvervs- og Selsskabsstyrelsen 

Kommentar 7 

Profilen har ingen direkte virkning på erhvervslivet, men vil indirekte kunne 

være medvirkende til, at der i fremtiden skabes administrative lettelser for 

erhvervslivet, da profilen skal udgøre det tekniske grundlag for en kommende 

fællesoffentlig brugerstyringsløsning. 


Det lyder positivt og hensigten er netop at forenkle sammenkoblingen af IT 

systemer. 

Kommentarer fra Region Hovedstaden 

Kommentar 8 

Hvorfor understøttes kun portaler og browsere? Det ser ud til at mekanismen er 

den samme for WS-integration. 


Webapplikationer og browsere er målet for den første fase af det fællesoffentlige 

brugerstyringsprojekt, der bl.a. skal understøtte behovene i borger.dk og virk.dk. 

På dette område er standarder og leverandørunderstøttelse længst fremme. I 

senere faser af brugerstyringsprojektet analyseres bl.a. identitetsbaserede web 

services, hvor behovet for standarder og profiler også er erkendt. 

Konceptuelt er mekanismen nogenlunde den samme, men ikke konkret. Det er af 

stor vigtighed, at der til vedtagne profiler findes åbne standarder såvel som bred 

kommerciel understøttelse. Dette arbejdes der stadig på at få på plads, og 

Styrelsen deltager aktivt i dette arbejde. 

Kommentar 9 

Regionens ønske en sømløs brugeroplevelse i tilgangen til interne og eksterne 

services og web sider i vores portal. Hvis kun portaler og browsere understøttes 

af DK-SAML, kan vi så opnå SSO, når der i samme portal anvendes en blanding 

af framed løsninger og WS integrationer? Det er ikke acceptabelt, hvis 

klinikkeren skal logge på med sin digitale signatur to eller flere gang for at 

anvende løsninger i samme portal (en logon til DK-SAML og en/flere til WS). 

Styrelsens Svar 

Situationen vil afhænge af, hvorledes sikkerheden i det konkrete tilfælde 

håndteres i web service integrationen. Det er netop målet med det kommende 

arbejde for identitetsbaserede web services (se forrige svar), at en sådan sømløs 

overgang er mulig. 

5 


Side 5

Kommentar 10 

Hvis klinikeren anvender flere portaler, kan de så dele adgangen (det ser ud til, at 

det handler om fælles anvendelse af en cookie)? 


En bruger vil kunne anvende vilkårligt mange web applikationer (herunder 

portaler) med single-sign on. 

Kommentar 11 

Tankerne om forenkling er gode og understøtter hvidbogens tanker om 

interoperabilitet, men er det ikke et problem, at vi løsriver os fra Oasis SAML 

med disse tiltag? 


Da SAML er ganske fleksibel er der behov for en dansk profil for at sikre 

interoperabilitet, konsistens og hensynet til forhold i den danske offentlige sektor, 

herunder OCES initiativet. 

Der sker ikke en "løsrivning", men blot præciseringer i forhold til OASISstandarderne, 

som stadig overholdes. 

Kommentar 12 

Vi kan ikke "blot" satse på at købe produkt der understøtter SAML, men skal 

specifikt sikre os, at det understøtter DK-SAML. 


Det er tilstræbt, at DK-SAML i så høj grad som muligt kan understøttes med 

standardprodukter, der er tilgængelige på markedet. Arbejdsgruppen bag profilen 

har været i dialog med flere leverandører for at sikre dette. 

Bortset fra enkelte ekstra krav som er specifikt dokumenteret opfylder 

standardprodukter, som overholder OASIS conformance krav også de danske 

krav - så gevinsten ved at basere sig på markedsudbredte standarder er bibeholdt. 

Kommentar 13 

Hvilken opgave omkring løbende vedligehold og compliance påtager vi og resten 

af DK os hermed? 


Som tidligere nævnt indeholder den danske profil blot præciseringer og 

afgrænsninger. I forhold til SAML 2.0, som er stabil, forventes ikke noget 

specielt behov for vedligehold. Compliance er i meget høj grad dækket af Liberty 

Interoperabilitetstest, som Danmark får "gratis". Det er således primært, hvis vi 

ønsker at drage nytte af videreudvikling på området - fx. med profiler, som 

effektiviserer den initielle opkobling mellem IdP og SP, at Danmark skal 

anvendes væsentlige ressourcer. 

6 


Side 6

Kommentar 14 

Har andre (fx USA eller New Zealand) gjort sig erfaringer der understøtter, at 

dette er den rigtige vej, og kan vi få tyngde i vores valg ved at bygge profilen i 

fællesskab med dem? 


Den danske SAML profil bygger i høj grad på erfaringerne fra især USA men 

også New Zealand. Der er dog mindre nationale forskelle, der gør at hvert land 

har brug for deres egen profil (f.eks. OCES PKI infrastrukturen og lokale 

attributter som CPR, CVR, PID i Danmark). 

Danmark samarbejder også i Liberty e-Government Special Interest Group på at 

analysere muligheden for at definere en fælles eGov profil/ramme 

Kommentar 15 

Nogle krav er meget hårde - fx s.30: "All other statements are disallowed". Uden 

at have undersøgt det specifikke indhold af felterne, ville det være attraktivt at 

opbløde dette krav, hvis det er muligt - fx ved at modtager af data skal se bort fra 

disse data, eller ved at de "skrælles bort" under forsendelsen. Er dette muligt, kan 

vi potentielt opnå et bredere udvalg af applikationsleverandører. 


De hårde krav er stillet for at sikre interoperabilitet på områder, der har vist sig 

problematiske. Den konkrete sætning udelukker, at man anvender SAML 

assertions til at bære autorisationsbeslutninger, da denne del er på vej ud af 

SAML og erstattes med XACML standarden. Kravet er i øvrigt i 

overensstemmelse med SAML's egen Web SSO profil og vil derfor ikke betyde 

indskrænkninger i antallet af potentielle leverandører. 

Kommentar 16 

Hvordan skal klinikeren vide hvilken IdP han skal vælge? Det giver ikke mening 

at bede en kliniker om at tage stilling til dette, og i akutte situationer, vil det være 

en alvorlig stressfaktor. Kan vi finde en anden (teknisk) løsning - fx ved at der i 

servicekaldet angiver ønsket IdP? 


Formuleringen i DK-SAML giver Service Provideren et valg mellem at anvende 

en default Identity Provider eller spørge brugeren. Dette betyder, at en 

sundhedsfaglig applikation kan vælge ikke at spørge klinikeren men i stedet 

anvende en foretrukken Identity Provider i sundhedsvæsnet. 

Kommentar 17 

Klinikeren vil skifte pc flere gange på en arbejdsdag. Dette ønsker vi at 

understøtte ved at samle applikationerne i en portal, og her fastholde kontekst fra 

session til session. Af nødvendighed er det ok at logge på igen, men er der nogle 

problemer ved fornyet logon - fx at IdP ikke vil autentificere samme bruger, når 

vedkommende allerede har en igangværende session? 

7 


Side 7


Der er ikke noget til hinder for dette i DK-SAML eller de omgivende OASIS 

standarder, da disse ikke foreskriver, hvorledes IdP'en specifikt skal håndtere 

sessioner med brugeren. 

Kommentar 18 

Hvor ligger rettighedsstyringen? Er denne opgave isoleret til det arbejde 

Økonomiministeriet har i gang, og er det tænkt sammen med dette arbejde? Uden 

sammenhæng mellem de to projekter er anvendelsesområdet meget begrænset. 


Rettighedsstyring er en del af det fællesoffentlige brugerstyringsprojekt og vil 

blive behandlet i en senere fase. Det er udenfor scope af DK-SAML, som indgår i 

den første fase af projektet. 

Kommentar 19 

AttributeQuery - er det overvejet hvilke data man vil overfører her, og hvem + 

hvordan vedligehold af disse data sker? Man kunne få den tanke at "snige" en 

form for rettighedsstyring ind via attributter. Dette vil hurtigt udvikle sig til en 

meget problematisk model, og det må anbefales ikke at gå denne vej. Vi kunne 

hurtigt ønske en masse domaine specifikke attributer. Det skal overvejes, om 

dette er en hensigtsmæssig løsning på den opgaven man adressere, eller 

attributter er en "løsnings-rodekasse". 


Det er tanken, at en fællesoffentlig Identity Provider kun skal udstille attributter 

som reelt er fællesoffentlige (eksempelvis Produktionsnummer attributten for 

virksomheder). På sigt vil domænespecifikke registerdata kunne udbydes som 

attributservices, der er uafhængige af en Identity Provider. 

Det er brugerstyringssekretariatet under Økonomistyrelsen, som vil står for 

governance af hvilke attributter, der skal udstilles fællesoffentligt. 

Kommentar 20 

Metadata - "All entities supporting the DK-SAML profiles must support the 

SAML Meta Data Specification" - hvad kræver dette af os som service anvender 

og som service udstiller? 


Dette betyder reelt, at man som Service Provider skal stille krav om 

understøttelse af meta data, når man erhverver en SAML løsning. Dette er 

standardfunktionalitet i en lang række produkter. 

Kommentar 21 

Logon er sat til at time ud efter 15 minutter. Er disse 15 minutter defineret efter 

vurdering af brugerbehovet? Hvis en klinikker sidder og bearbejder nationalt 

udstillede data sammen med vores interne data, kan han være løbende aktiv, men 

uden at ramme nationale services så hyppigt. Det vil være et stort 

8 


Side 8

irritationsmoment, hvis han skal logge på op til 4 gang pr. time. Brugerbehovet 

bør undersøges. 


De omtalte 15 min er en redaktion fejl - det burde have stået tydeligere i profilen, 

at det var et eksempel. Time-out politik vil blive fastlagt af de føderationer, der 

anvender profilen. 

Bemærk at en bruger vil have en session med både Identity Provider og hver 

Service Provider. Dette betyder, at så længe han er aktiv hos en Service Provider 

(og ikke timer ud her), da vil han ikke have behov for at logge på igen før han 

skifter til en ny Service Provider. 

Kommentar 22 

Afs. 13.2 Authentication level in requests. Problemet ser ikke ud til at være løst. 

Hvordan understøttes det, at en service kræver logon på sikkerheds niveau 4, hvis 

IdPen ikke får denne oplysning og frit kan vælge autentifications niveau? 


Problemet løses ved at der tilknyttes en logisk IdP til hvert niveau af 

autentifikation. Dermed vælger Service Provideren niveau ved at vælge logisk 

IdP. 

Styrelsen er enig i, at det ville være en fordel, hvis niveau et kunne angives i 

forespørgslen, men dette er ikke medtaget, da det ville give problemer i forhold 

til standardprodukter. Styrelsen arbejder på at få dette ind som et krav i 

internationale interoperabilitetstest, hvorved produktunderstøttelse vil følge med 

og kravet kunne indføres i profilen. 

Kommentar 23 

Flere steder får man den overvejelse, om man bør være logget på nationalt fra 

starten af sessionen. Dette er en uønsket løsning set fra regionen, da 

systemadgangen er særdeles kritisk. En løsning der adresserede behovet for at 

være logget på lokalt og nationalt parallelt kunne være at etablere en "bro" 

mellem den lokale identitet og den nationale identitet. 


Det er ikke hensigten, at brugeren skal være tvunget til at logge på en 

fællesoffentlig Identity Provider for at tilgå løsninger i hans egen hjemorganisation. 

Brobygning mellem lokale og nationale identiteter håndteres i 

senere faser af det det fællesoffentlige brugerstyringsprojekt. 

Kommentarer fra Region Syddanmark 

Kommentar 24 

Region Syddanmark opfordrer It- og Telestyrelsen til at arbejde på en national 

SAML 2.0 profil for web-services (eller flere nationale profiler, der tillader 

etablering af tillidsforhold, "trusts" mellem de forskellige sikkerhedsdomæner / 

9 


Side 9

føderationer). Regionen opfordrer endvidere Styrelsen til at lade et sådant 

arbejde tage afsæt i erfaringerne fra sundhedsområdet. 


Dette behandles i de kommende faser af det fællesoffentlige 

brugerstyringsprojekt, og vi takker for mulighed for at inddrage 

sundhedsområdets erfaringer, hvilket vi absolut vil gøre sammen med andre 

relevante erfaringer. 

Kommentar 25 

Endelig vil Region Syddanmark opfordre It- og telestyrelsen til at arbejde for, at 

viden om det anvendelsesscenarium for SAML 2.0 indenfor sundhedssektoren 

(med minimering af antallet af signon's og antallet af eksterne opslag) bibringes 

relevante internationale fora, idet problemstillingerne indenfor it-understøttelsen 

af sundhedsområdet må antages at være parallelle med problemstillinger i andre 

lande. 


Det vil Styrelsen gerne for så vidt som vi fagligt er i stand til at dække emnet. 

Der er dog områder, hvor vores faglige viden kommer til kort, fx har Liberty 

Alliance en Healthcare special interest group, hvor et engagement fra regionerne 

vil være velkomment. 

Kommentarer fra Statsbiblioteket 

Kommentar 26 

I introduktionen lægges ud med at skrive at profilen(DK-SAML2.0) skal bruges 

til føderationer indenfor den danske offentlige sektor. Afgrænsningen synes ikke 

at være defineret præcist nok, specielt når man tager de begrænsende valg der 

foretages i betragtning. DK-SAML2.0 efterlader det indtryk, at dokumentet er 

skrevet med en bestemt føderation for øje - eller til en gruppe af meget homogene 

føderationer. 


Profilen er ikke skrevet med en bestemt føderation for øje men henvender sig til 

føderationer formeret af danske myndigheder. Dette udelukker dog ikke hverken 

private eller internationale medlemmer af en sådan føderation. Profilens sigte er 

at sikre interoperabilitet og ikke at begrænse føderationers 

udfoldelsesmuligheder. Dersom en føderation indenfor målgruppen har 

væsentlige argumenter for at fravælge profilen, kan dette gøres. Det skal dog 

samtidig bemærkes, at profilen tillader stor fleksibilitet mht. imødekommelse af 

sektor-specifikke behov f.eks. gennem nye attributprofiler. 

Profilen opdateres så ovennævnte forhold er tydeligere. 

Kommentar 27 

Fokus for DK-SAML2.0 er primært føderationer bestående af offentlige 

myndigheder, deres ansatte og borgerne. Der er kun lidt fokus på føderationer 

indholdende private tjenesteudbydere eller føderationer, som går på tværs af 

10 


Side 10

landegrænser. Dette gør det formentlig svært at leve op til profilen i alle hjørner 

af de føderationer, som vil opstå i offentligt regi. Derfor bør scope't enten 

defineres mere præcist eller også bør visse begrænsninger fjernes. 


Se svar til kommentar 26. 

Kommentar 28 

Det primære DK-AAI scenarium er ikke omfattet af de beskrevne scenarier. I 

DK-AAI er brugerne for det meste anonyme i forhold til SP'en. I nogle tilfælde er 

der behov for en persistent relation (pseudonym), men ikke nødvendigvis kontilinking. 

I andre tilfælde er det nok at IdP'en siger god for brugeren og at 

vedkommende eksempelvis er studerende. I dette tilfælde er der ikke behov for 

persistering af relationen, men der skal tilgengæld overføres en række 

rollelignende attributter. 


Det er ikke umiddelbart til at afgøre om DK-AAI har særlige behov, der ikke kan 

tilgodeses af DK-SAML, men hvis det er tilfælde kan det være relevant at 

supplere DK_SAML meden anden SAML profil. 

Kommentar 29 

Følgende tekst er taget fra: http://www.oasisopen.org/committees/download.php/11785/sstc-saml-exec-overview-2.0-draft- 

06.pdf 'Generally, a profile of SAML defines constraints and/or extensions in 

support of the usage of SAML for a particular application - the goal being to 

enhance interoperability by removing some of the flexibility inevitable in a 

general-use standard. For instance, the Web Browser SSO Profile specifies how 

SAML authentication assertions are communicated between an identity provider 

and service provider to enable single sign-on for a browser user.' Vi mener ikke, 

at man bør generalisere alle kommende, danske føderationer til 'a particular 

application', som det eksempelvis gøres ved alene at tillade HTTP-POST 

(ekskluderer SAML-artefact). 


Hensigten med at anlægge begrænsninger i en profil er at sikre en højere grad af 

interoperabilitet, hvilket er en af de primære bevæggrunde for DK-SAML. Ved at 

vælge HTTP Post binding fremfor HTTP Artifact binding foretages ingen 

indskrænkning af de "forretningsmæssige" muligheder, idet der blot er tale om to 

alternative måder at kommunikere på, der er funktionelt ækvivalente (der 

overføres en assertion fra A til B). 

Yderligere kan det nævnes at ITST faktisk ser DK-SAML 2.0 som beskrivende 

den "application", som hedder "Web SSO". 

Kommentar 30 

Ifølge dokumentet 'Conformance Requirements for the OASIS Security Assertion 

Markup Language (SAML) V2.03' lever en given profil ikke op til SAML2standarden 

hvis ikke http-artefact understøttes. 

11 


Side 11


Denne kommentar beror på en mistolkning af SAML conformance dokumentet. 

Dette dokument beskriver hvilke SAML funktioner et produkt skal understøtte 

for at være i conformance med en række 'operational modes'. Dette har intet at 

gøre med SAML profiler. 

Kommentar 31 

SAML-artefact'er anbefales til overførsel af større datamængder, og giver derfor 

god mening at bruge, hvis der tale om måleresultater, patientjournaler, 

mediefiler, grid-jobs osv. som ofte udgør større datamængder. Argumentet om at 

man i USA har haft problemer med brugen af SAML-artefact er ikke fra 

énsbetydende med, at det samme skulle være tilfældet for alle kommende 

føderationer i Danmark (afsnit 4.5.4). Manglen på diskussion af baggrunden for 

dette vigtige fravalg springer i øjnene - især når man tager DK-SAML2.0's 

generelle karakter i betragtning. 


SAML Artifacts fungerer som referencer til SAML Assertioner. Det forekommer 

som misbrug af SAML at indlejre mediefiler, patientjournaler, måleresultater og 

lignende i en SAML assertion, så argumentet er svært at forstå. Derimod 

forekommer det relevant at skele til erfaringerne fra en af de største 

implementationer (USA's egov), der netop peger på HTTP Redirect som den mest 

hensigtsmæssige binding. 

Kommentar 32 

Vi spørger os selv om, hvorfor man ønsker at tvinge udbredelsen af OCES 

signatur via dette initiativ? De direkte og afledte krav til brugerne, IdP'erne og 

SP'erne vedrørende brug af OCES-certifikater volder problemer i forhold til 

profilens generelle anvendelse. Her tænkes særligt på eksisterende PKI'er, som 

fungerer til alles tilfredshed. Også det faktum at relativt store beløb allerede er 

investeret i certifikater og abbonementsordninger vil konflikte med de mange 

krav om brug af OCES-certifikater. Billedet kompliceres yderligere i et 

internationalt miljø som det akademiske, hvor interføderering, dvs. 

sammenkobling af eksisternde føderationer, allerede er igangsat. Endelig er der 

mange IdP'er som ikke bruger OCES i dag, da mobilitetsproblematikken med 

OCES endnu ikke er løst for de fleste brugere, ikke mindst i 

uddannelsessektoren. Og så skal det nævnes, at DK-AAI-brugeren ofte er 

anonym i forhold til SP'eren hvorfor overførelse af CPR-nummer eller PID derfor 

være uaktuelt. 


Styrelsen har valgt at tage kravet om OCES understøttelse ud af profilen hvad 

angår signering og kryptering mellem Service og Identity Providere. Det er 

således ladt op til de føderationer, som anvender profilen, at definere passende 

trust mekanismer. Det anbefales dog stadig at anvende OCES med mindre der er 

væsentlige årsager, som en allerede etableret PKI-infrastruktur, der gør 

alternativer relevante. 

12 


Side 12

Derimod er OCES attributprofilen bibeholdt, idet denne af 

interoperabilitetshensyn specificerer, hvilke attributter, der skal udveksles, når 

brugeren er autentificeret via en OCES digital signatur. 

Kommentar 33 

I afsnit 4.4.2 står der at en IdP gerne må supportere forskellige 

autentifikationsmekanismer, men "level of authentifikation" må ikke angives i 

forespørgslen. Der skal i stedet anvendes forskellige logiske IdP'er - hvilket ikke 

giver mening, da auth-niveaer dermed alligevel skal konfigureres. Vi forstår ikke 

hvorfor ikke auth-level ikke tillades i authn-request. Det bør efter vores mening 

være op til den enkelte føderation at definere. At enkelte stykker software har 

svært ved at håndtere forskellige 'levels of assurance', LOA, bør ikke gå ud over 

alle. DK-AAI har påvist, at systemopsætningen på IdP-siden kan være ganske 

begrænsende for udbredelsen af føderationen. At bede hver enkelt IdP om at 

opsætte og administrere flere logiske IdP'er svarende til multible auth-niveauer 

tror vi vil være direkte hæmmende - ikke mindst når man tager SAML2understøttelsen 

for auth-levels i betragtning. Men også fravalg af fx "level of 

authentification" eller tilvalget af "Identity Discovery profile" volder problemer i 

forhold til føderationer med partnere som ikke er en dansk myndighed. 


Det er særdeles vigtigt, at DK-SAML let kan implementeres i den offentlige 

sektor ved brug af standardprodukter. I forbindelse med arbejdet med profilen 

pågik en dialog med en række store leverandører, og det blev klart, at meget få 

(om nogen overhovedet) af standardprodukterne vil kunne understøtte udvidelser 

af meddelelsen med denne information. Dette ville betyde dyr 

og langsommelig customisering hos hver eneste serviceudbyder, hvilket ville 

kunne bringe udbredelsen i fare. I stedet er valgt en mere pragmatisk løsning, 

hvor en IdP kan konfigurere et antal logiske IdP'er med hver deres 

autentifikationsniveau. Dermed kan en SP vælge niveau indirekte ved at vælge 

logisk IdP. Det faktisk autentifikationsniveau er bibeholdt i den assertion, der 

udstedes, som en custom attribut (dette er nemlig bredt understøttet i produkter). 

Som nævnt i svar til kommentar 22 arbejder Styrelsen fremadrettet på at få 

produktstøtte for, at AuthnRequest kan indeholde AuthNLevel. 

Kommentar 34 

Argumentationen i afsnit 6 for at anvende HTTP Redirect binding til singlelogout 

er problematisk. Hvis man vil fastholde front-channel, skal argumentet 

være, at man har mulighed for at prompte brugeren for, om han virkelig vil logge 

ud. Brugerens identitet kan også videregives via SOAP binding. 


Argumentationen er taget fra OASIS' egen profil for Single Logout (se OASIS 

profildokumentet version 2.0 linje 1148-1154 og 1211-1217), så den holder nu 

nok vand! Det er en almindelig udbredt teknik at holde en session via cookies, 

der kun kan læses, hvis brugeren henvises via en front-channel binding. 

13 


Side 13

Endvidere er HTTP-Redirect favoriseret af SAML conformance krav, idet denne 

kræves for alle typer "operational modes". 

Profilen bliver opdateret, så den ekstra fordel med, at IdP en kan prompte 

brugeren, medtages. 

Kommentar 35 

Common domain og dermed brugen af "Identity Discovery profile", beskrevet i 

afsnit 4.2, giver fint mening hvis en SP'er kun er medlem af få forskellige 

føderationer. I DK-AAI vil der være kommercielle (udenlandske) SP'ere, som 

udbyder deres tjeneste til mange føderationer. Det bliver svært at kræve at disse 

skal håndtere mange "commen domains", idet de allerede i dag anvender andre 

"discovery" mekanismer, som passer ind i deres forretning for fødereret adgang 

til deres tjenester. 


Det lader til, at DK-AAI har særlige behov, der ikke kan tilgodeses af DK- 

SAML, hvorfor det vil være fornuftigt at anvende en anden SAML profil. Det er 

ikke meningen, at DK-SAML skal tilgodese særlige forhold i udenlandske 

føderationer, men derimod vælge den mest hensigtsmæssige løsning til den 

danske offentlige sektor. Multi-federations er out-of-scope for DK-SAML 2.0. 

Kommentar 36 

DK-SAML2.0 sætter et meget højt sikkerhedsniveau. I Afsnit 4.3.3, 10.8, 10.9 og 

11.5 beskrives det, at data på "message level" både skal signeres og krypteres. Da 

DK-AAI-brugeren ofte er annonym i forhold til SP'erne, bør et lavere 

sikkerhedsniveau i forhold til kryptering kunne anvendes - det skal i øvrigt siges, 

at alle attributoverførsler sker via sikre, krypterede forbindelser. 


DK-SAML sigter efter et sikkerhedsniveau, hvor personfølsomme oplysninger 

kan udveksles på en betryggende måde, herunder overholde Datatilsynets 

retningslinjer om brug af stærk kryptering. Dette er et fundamentalt krav i den 

offentlige sektor. Bemærk dog, at der er valgfrihed i hvor stærkt en Identity 

Provider autentificerer en bruger, og at det aktuelle niveau skal afspejles i de 

adgange, brugeren efterfølgende kan opnå. At DK-AAI på flere punkter så har 

andre behov kunne indikere, at det vil være fornuftigt at anvende en anden 

SAML profil. 

Endvidere kan det tilføjes, at kravene sigter mod hvad der interoperabilitetstestes 

på, så der vil være produkter, som kan understøtte kravene i praksis. 

Kommentar 37 

Navngivningen af unikke, sektorspecifikke atributter bør bindes til DNSnavngivningen 

af føderationen (se afsnit 7.4, bullet 2). 


Korrekt. Dette præciseres i profilen. 

14 


Side 14

Kommentarer fra Datatilsynet 

Datatilsynet har afgivet høringssvar alene til afsnit 11.4 med overskriften 

Privacy in a Danish Context . Datatilsynet beskriver i sit svar en række 

punkter, hvor profilens ikke stemmer overens med definitioner og indhold i 

persondataloven. De enkelte punkter er ikke medtaget i nedenstående, da 

Styrelsen har valgt at tage afsnittet ud af profilen og i stedet henvise direkte 

til persondataloven. 

Kommentar 38 

Sammenfattende må konstateres, at omtalen af persondatalovens regler ikke er 

retvisende. Eventuelt kan der i profilen blot henvises til Datatilsynet for nærmere 

information om persondatalovens regler. Såfremt udkastets afsnit 11. 4 med 

overskriften Privacy in a Danish Context opretholdes, skal Datatilsynet 

anbefale, at afsnittet omarbejdes, så det bringes i overensstemmelse med 

persondataloven. 


Dette forhold beklages. Det er besluttet, at afsnittet tages ud af profilen som 

foreslået, og at der i stedet henvises til persondataloven. 

Kommentarer fra IBM 

Kommentar 39 

Denne profil foretager nogle kraftige fravalg, samtidig med at den fokuserer 

meget på de krav der rejses fra offentlige portaler - specielt borger.dk. Den 

fremstår derfor som en pragmatisk, taktisk standard og det kunne måske være 

en fordel at markere det ved f.eks. 

Slet ikke at anvende ordet "SAML" i profilens navn, men noget i retning 

af "Profil for offentlig fælles web login 1.0" 

At ændre profilens navn til "DK-SAML 2.0 Web Browser SSO Profile" 

Fremhæve denne fokusering i det indledende "prpose" afsnit. 

Angive en mulig roadmap for kommende versioner eller profiler under 

"DK-SAML" - f.eks. "DK-SAML Web Services SSO Profile", DK-SAML 

WSRPProfile". 


Profilen skal ikke ses som en taktisk standard men snarere første trin i en serie af 

profiler, der udvikles i det fællesoffentlige brugerstyringsprojekt. Det indledende 

afsnit i profilen gøres tydeligere i beskrivelsen af formål og målgruppe for 

profilen. Se iøvrigt svar til kommentar 8 for yderligere detaljer. 

Med hensyn til navn på profilen er styrelsen enig i at profilens scope kan 

signaleres tydeligere, og ændrer derfor navnet til OIO Web SSO Profile V2.0 

Kortformsreferencen til profilen DK-SAML 2.0 bibeholdes dog også da dette 

navn er vel-etableret. 

15 


Side 15

Kommentar 40 

Med kravet om anvendelse af OCES certifikater afgræner standarden sig til at 

være en national standard, som udelukker herboende personer som ikke har 

eller kan få et OCES certifikat og udenlandske brugere samt udenlandske 

service providers, der skal udvekslke OCES virksomhedscertifikater med ID 

provideren. 

Det giver også problemer i forhold til internationale leverandører af 

sikkerhedsprodukter, som typisk holder sig til internationale standarder (en 

af grundene til at vi har dem). IBM's deltagelse i borger.dk proof-of-concept 

viste i casen med Rødovre Kommune, at dette godt kan lade sig gøre, men der 

skal foretages ekstra konfigurering m.v. for at implementere den nødvendige 

nationale tilpasning. 


Det er vigtigt at pointere at DK-SAML 2.0 profilen består af en række subprofiler, 

som ikke alle skal anvendes på én gang. Hvilke profiler der er relevante 

afhænger af hvilken rolle organisationen spiller og hvilke scenarier, der skal 

understøttes. OCES Attribut Profil skal kun anvendes hvis login-metoden er 

Digital Signatur. Der er således blot tale om at internationale standardprodukter 

skal kunne understøtte forskellige mekanismer til autenticitetssikring. 

Det er besluttet at tage kravet om OCES certifikater ud af profilen som trustmekanisme 

mellem Identity- og Service Providere. Se iøvrigt svar til kommentar 

32. 

I relation til produktunderstøttelse baserer såvel DK-SAML som OCES sig på 

internationale standarder, hvilket sikrer basis for interoperabilitet og anvendelse 

af standardprodukter. Der vil naturligvis være behov for konfigurering af 

standardprodukter til håndtering af lokale danske forhold som f.eks. CPR og 

CVR attributter, men det bør ikke udgøre nogen væsentlig hindring. 

Kommentar 41 

I det beskrevne scenarie fungerer portalen som en ren gennemstilling via et 

link eller en iframe til en service provider(SP). Portalen er imidlertid selv 

en SP, som har brug for autentificering af brugere, så de kan tilgå de 

portalrelaterede resourcer, som portalen er ansvarlig for - f.eks. 

portalsider, portlets på portalsider osv. Portalen kan sikkert også selv have 

brug for Attribute Services. 

Afgrænsningen til borger.dk med fravalg af f.eks. WRSP virker lidt som en 

taktisk, "tilfældig","pragmatisk" afgrænsning i forhold til at denne standard 

jo har et bredere sigte. Vedr. WSRP er IBM's support for denne standard i 

IBM's portalprodukter meget omfattende. WSRP vil sandsynligvis få stor 

betydning for distribuerede portaler med den kommende version 2, hvor der 

åbnes på for inter-portlet kommunikation, 


Det er korrekt at portalen selv funger som en Service Provider mod Identity 

Provideren, hvilket profilen også beskriver. 

16 


Side 16

I relation til WSRP og Web Services er dette et bevidst fravalg og således 

udenfor scope af profilen. Se svar til kommentar 8 og 39 for detaljer. 

Kommentar 42 

Afgrænsning til point-to-point interaktion via https. Da udgangspunktet i 

arkitekturen er en point-to-point interaktion via https bliver det aktørernes 

(IDP, SP) opgave eksplicit at tage hånd om sessioner (cookie baseret), ID 

provider addresser, og Attribute server addresser, hvor de sidste to via 

deres implementering som web service kald jo kunne routes igennem en broker, 

hvis der altså indgik denne mulighed i arkitekturen. På samme måde skal 

aktørerne også selv bidrage til transaktionsstyring ved, som det 

foreslås,anvendelse af Assertion ID som transaktionsidentifier og logning af 

disse til auditformål. Igen opgaver som en brokerbaseret arkitektur kan 

håndtere - i brokeren. 


Styrelsen har ikke set det hensigtsmæssigt eller relevant at indføre en brokerbaseret 

arkitektur til Web Browser SSO scenariet, som DK-SAML profilen 

dækker. I senere profiler til identitetsbaserede web services kan dette dog blive 

en mulighed, som skal overvejes. Se iøvrigt svar til kommentar 8, 39 og 41. 

Kommentar 43 

I afsnit 11.3.1 nævnes noget om at publicere meta data lokationer i DNS 

records som en option??? 


Publicering af meta datas lokation i DNS records er en af de mekanismer, der 

beskrives i OASIS SAML Meta Data specifikationen. Denne er dog ikke 

medtaget som et obligatorisk krav i DK-SAML profilen, da man meget vel kan 

tænke sig, at føderationer vil anvende andre mekanismer. 

Kommentar 44 

Uklarhed omkring anvendelse af OCES virksomhedscertifikat eller lignende? 

Flere steder nævnes det at der skal anvendes OCES virksomhedscertifikat eller 

lignende ("or equivalent"). 


Den lidt løse formulering omkring OCES certifikater flere steder skyldes, at 

Styrelsen op til høringen overvejede, hvorvidt en ny type OCES certifikater 

(Funktionscertifikater) skulle kunne anvendes som trust mekanisme (udover 

Virksomhedscertifikater). Imidlertid er det efterfølgende blevet besluttet, at tage 

eksplicitte krav om OCES som trust mekanisme ud af profilen, men i forhold til 

den fællesoffentlige brugerstyringsorganisation må der forventes indførelse af en 

politik, som stiller krav om brug af OCES certifikater til signering og kryptering 

af meddelelser. Se i øvrigt svar til kommentar 32. 

Kommentar 45 

Service Provider og IDP MUST forbindes via en SSL sikret linie med anvendelse 

af OCES Virksomhedscertifikat. Hvad menes der med "or equivalent" i afsnit 

17 


Side 17

7.1.3 side 31? Er alle service providers virksomheder, der har et 

virksomhedscertifikat? Hvad med undenlandkse service providers. 


Se svar til kommentar 32 og 44. Føderationer beslutter nu selv trust mekanismer, 

og kan i princippet godt inkludere udenlandske Service Providers. 

Kommentar 46 

Afsnit 10.9 I starten (side 46) skrives at SP-Attr Servie Provider skal 

anvende OCES eller lignende. Senere i afsnittet (side 47 tredje sidste 

afsnit) skal (MUST) der anvendes et OCES virksomhedscertifikat. 


Se svar til kommentar 32 og 44-46. 

Kommentar 47 

Afsnit 11.5.2 skrives det at OCES virksomhedscertifikatet "is generally 

mandatory", vil det sige overvejende, altså at undtagelser kan gøres. 


Se svar til kommentar 32 og 44-47. 

Kommentar 48 

Mapning af pseudonym og subject ID hosService Provider. Afsnit 9.2 Mapningen 

mellem Persistent pseudonyme Attribute er det vel kun SP der skal mappe til 

det interne subject ID. Derfor ikke "Both Identity provider... and the 

mapping ....." sidste afsnit side 42. 


Det er et krav, at Identity Provideren genererer forskellige pseudonymer til 

forskellige Service Providere (for samme bruger), så disse ikke kan korollere 

oplysninger om brugerens identitet. Det, der ligger i den beskrevne formulering, 

er således, at Identity Provider vil have behov for at mappe fra brugerens interne 

identitet til det pseudonym, der skal anvendes til den pågældende Service 

Provider. 

Kommentar 49 

Hvad er årsagen til at 'Transient pseudonym profile' ikke understøttes? 


Dette skyldes, at der ikke har været vurderet et stort behov for denne mekanisme 

indenfor profilens målgruppe og anvendelsesområde. Profilen er bevidst holdt 

fokuseret med henblik på at lette praktiske implementeringer og skabe mest 

mulig klarhed for anvenderne. Såfremt der skulle vise sig et vigtigt behov for 

denne mekanisme, vil Styrelsen overveje at inkludere denne i profilen. Det er 

igen også vigtigt at fastslå at profilen ikke forbyder anvendelse af yderligere dele 

af OASIS SAML 2.0 standarden. Der er således intet til hinder for at en 

føderation muliggør yderligere funktionalitet udover hvad der er beskrevet i DK- 

SAML 2.0. 

18 


Side 18

19 


Side 19

OIO Web SSO Profile 2.0 - 

Requirements Summary 

IT- & Telestyrelsen, Center for Serviceorienteret Infrastruktur 

December 2007 

>

Contents > 

1 Introduction 4 

1.1 Purpose 4 

2 Web SSO Profile 5 

2.1 Authentication Request 5 

2.2 Authentication 5 

2.3 Response 5 

2.4 Authentication Assertions 6 

2.5 Attribute Encoding Rules 6 

2.6 Core Attributes 7 

2.7 OCES Attribute Profile 8 

2.8 Persistent Pseudonym Profile 8 

2.9 Sector-Specific Attributes 8 

2.10 Meta Data Requirements 9 

2.11 Other Considerations 9 

3 Identity Provider Discovery 10 

4 Single Logout Profile 11 

5 Attribute Query Profile 12 

5.1 Attribute Query Message 12 

5.2 Response Message 12 

5.3 Processing Rules 13 

6 Security Requirements 14 

Appendix A: References 16

Document History 

Version Date Initials Changes 

1.0 31-10-2007 TG Document created

1 Introduction 

4 

1.1 Purpose 

This document contains a brief summary of the requirements stated in OIO Web SSO 

Profile V2.0 which also is referred to as DK-SAML 2.0 [DK-SAML]. The profile 

document [DK-SAML] is still normative and will take precedence in case of any 

conflicts or ambiguities. 

The requirements summary serves as a quick reference and further provides a 

checklist that can be given to vendors of SAML products. 

>

2 Web SSO Profile 

The OASIS Web SSO Profile described in [SAMLProf] must be followed where 

nothing else is described. 

2.1 Authentication Request 

The message MUST be signed by the Service provider with 

a private key bound to an X.509 certificate 

HTTP Redirect binding MUST be used with DEFLATE encoding. The 

signature on the MUST be located in the Signature query 

string defined in the DEFLATE encoding. 

The MUST not contain custom attributes (for example 

specifying the desired level of authentication). 

The HTTP exchange MUST take place over one-way SSL / TLS. 

The RelayState parameter MAY be used, but MUST not reveal any details of 

the request (must be opaque). 

The Identity Provider end-points MUST be determined using (previously 

exchanged) meta data. 

Depending on the used attribute profile, a NameIDPolicy element may be 

present in the request: 

o When the OCES attribute profile is used, the NameIDPolicy 

element SHOULD be avoided. The federation of accounts will not 

happen through account linking but through account mapping of 

the OCES attributes. 

o When the persistent pseudonym profile is used, the NameIDPolicy 

element must be present with the AllowCreate attribute set to 

true and the Format attribute set to 

urn:oasis:names:tc:SAML:2.0:nameid-format:persistent 

2.2 Authentication 

The user MUST be able to opt out of SSO at the Identity Provider such that he 

will never be SSO ed to Service Providers. 

The Identity Provider MUST honour the ForceAuth attribute and reauthenticate 

the user if it is set to true . 

2.3 Response 

Only Service Providers with prior agreements (and exchanged meta data) 

MUST be served by the Identity Provider. 

The SHOULD not be signed. 

A successful response MUST contain exactly one with exactly 

one element. Each assertion's element MUST 

contain the unique identifier of the issuing Identity Provider; the Format 

attribute MUST be omitted or have a value of 

urn:oasis:names:tc:SAML:2.0:nameid-format:entity. 

> 

5

6 

Any returned Assertions MUST follow the attribute profiles defined in DK- 

SAML. 

The Service Provider end-points MUST be determined using previously 

exchanged SAML meta data. 

The HTTP Post binding MUST be used for sending the response. 

The HTTP exchange MUST take place over one-way SSL / TLS 

2.4 Authentication Assertions 

Assertions MUST be signed by the Identity Provider. 

Assertions MUST be encrypted under the Service Provider s public key. No 

other elements are permitted to be encrypted (e.g. attribute encryption). 

An Assertion MUST NOT contain an . 

An Assertion MUST contain exactly one and one 

. 

Assertions MUST contain an attribute stating the level of authentication. 

The Issuer element is mandatory and MUST contain a string with the (unique) 

Issuer id. The Issuer id MUST be a Uniform Resource Locator containing the 

issuer s domain. 

The name qualifiers NameQualifier, SPNameQualifier, Format and 

SPProvidedID SHOULD not be used. 

An assertion MUST contain exactly one element holding the 

subject id. 

The subject element MUST contain at least one 

element containing a Method of 

urn:oasis:names:tc:SAML:2.0:cm:bearer. 

The bearer element described above MUST contain a 

element that has a Recipient attribute containing 

the Service Provider's assertion consumer service URL and a NotOnOrAfter 

attribute that limits the window during which the assertion can be delivered. It 

MUST NOT contain a NotBefore attribute. 

The assertion MUST contain an including the Service 

Provider's unique identifier as an . 

Advice elements MAY safely be ignored by implementations. 

Any authentication statements MUST further include a SessionIndex attribute 

to enable per-session logout requests by the Service Provider. 

2.5 Attribute Encoding Rules 

The following rules for attribute encoding MUST be followed by all attribute profiles: 

>

The XML attribute on the element MUST be: 

urn:oasis:names:tc:SAML:2.0:attrname-format:uri 

Attribute names MUST be a URI (as indicated by the name format above). 

The XML attribute MAY be used but implementations 

SHOULD not rely on it. 

Attributes with an Object Identifier SHOULD use this identifier as their name 

(e.g. urn:oid:2.3.4.5 ). 

Attributes without an Object Identifier which are defined by the National IT 

and Telecom Agency SHOULD have the following name prefix: 

dk:gov:saml:attribute . 

All attribute values MUST be simple text strings with type xs:string . 

Mandatory attributes which have no value MAY be set with blank values. 

Optional attributes SHOULD not have blank values. 

Service Provider MUST be able to handle empty mandatory attributes. 

Encrypted attributes SHOULD not be used. 

2.6 Core Attributes 

The following core attributes MUST be included in all attribute statements except for 

the persistent pseudonym profile: 

sn - Surname 

cn - Common name. 

uid - User id 

mail - email address 

AssuranceLevel States how strongly the user was authenticated. 

SpecVer States the applied version of the DK-SAML profile. 

For details, please consult [DK-SAML]. 

The following core attribute are optional: 

uniqueAccountKey - Unique key to match and synchronize user information 

across systems and organisations 

cvrNumberIdentifier - An employee s organization identifier 

DiscoveryEPR - Contains an end-point reference (EPR) to a Liberty 

Discovery Service 

A Service MAY ignore these attributes but MUST not halt the processing if they are 

present. 

> 

7

8 

2.7 OCES Attribute Profile 

If the OCES attribute profile is used, the following requirements apply: 

When authenticating subjects using an OCES certificate, the 

element SHOULD refer to the following authentication context class in an 

element: 

urn:oasis:names:tc:SAML:2.0:ac:classes:X509. 

The Subject should be encoded using the DN from the OCES cert as 

recommended by the SAML deployment profile for X.509 subjects. 

The Certificate Serial Number MUST be included as an attribute. 

The Organization Name MUST be included as an attribute for Employees and 

Companies. 

The Organization Unit MAY be included as an attribute. 

The Title MAY be included as an attribute. 

The Postal Address MAY be included as an attribute. 

The OCES Pseudonym MAY be included as an attribute. 

The User Certificate MAY be included as an attribute. 

The PID number MUST be included as an attribute for Persons. 

The CPR number MAY be included as an attribute for Persons. 

The CVR number MUST be included for Employees and Companies. 

The RID number MUST be included for Employees. 

The Uid core attribute MUST contain the Subject Serial number from the 

OCES certificate literally. 

2.8 Persistent Pseudonym Profile 

Service and Identity Provider MUST support exchanging a persistent 

pseudonym as part of an SSO exchange. 

The assertion MUST contain the following core attributes. 

o AssuranceLevel attribute 

o SpecVer attribute 

No other kernel attributes are permitted. 

The assertion Subject element MUST contain a persistent pseudonym 

identifier. The identifier MUST be truly opaque such that the user identity 

cannot be inferred from it. 

2.9 Sector-Specific Attributes 

Sector or IdP-specific attributes MUST be placed in responses to attribute 

queries and MUST not be present in authentication assertions. 

>

Attributes specific to a sector or an Identity Provider MUST use a name URI 

containing their DNS domain. 

Sector-specific attributes must follow the encoding rules described previously. 

2.10 Meta Data Requirements 

All entities MUST be able to export and import meta data files. 

All entities MUST include their X.509 certificates literally (i.e. not just 

references) in order to allow others to verify signatures from them and encrypt 

messages to them. 

All relevant services required by this profile MUST be described in meta data, 

including SingleLogonService, SingleLogoutService, AttributeService, 

AssertionConsumerService, ManageNameIDService, 

NameIDMappingService. 

All attributes supported by the Attribute Service SHOULD be described in the 

. 

No proprietary information MAY be included in the SAML meta data (e.g. in 

elements) including required / supported levels of 

authentication. This is to ensure that meta data can be exchanged without 

interoperability issues. 

The root of every metadata file MUST be . 

Signing and verification of meta data is not required by this profile. 

2.11 Other Considerations 

The Entity Identifier SHOULD be derived from the name of the domain name 

that the federation server is hosted in using the the template: 

https://saml.[domain name] 

> 

9

3 Identity Provider Discovery 

10 

Service- and Identity Providers MUST support and use the Identity Provider 

Discovery Profile found in [SAMLProf] with Common Domain Cookies 

(CDC). 

o The Identity Provider MUST write this cookie before transferring the 

user back to a Service Provider. 

o The Service Provider should read the cookie to obtain a list of 

potential Identity Providers. 

The common domain cookie MUST be transient (i.e. must not persist past the 

closing of the user s browser). 

If no common domain cookie exists or no supported Identity Providers are 

found in it, a Service Provider MAY select a default Identity Provider or 

prompt the user to select from a list of supported Identity Providers. 

>

4 Single Logout Profile 

Identity- and Service Provider MUST follow the Single Logout Profile 

described in [SAMLProf]. 

HTTP Redirect binding MUST be used for conveying the first message going 

from a Service Provider to an Identity Provider. 

Either HTTP Redirect or SOAP binding MUST be used for subsequent 

message exchanges. 

All Service Providers and Identity Provider MUST support the HTTP Redirect 

binding. 

Service Providers MAY support SOAP Binding. 

Identity Providers MUST support for SOAP Binding. 

When a Service Provider supports SOAP, SOAP SHOULD be used (except 

for the first message) as it offers numerous advantages including reliability. 

All request and response messages MUST be signed. 

Each Service Provider SHOULD provide a means for local logout to its own 

applications. 

All communication MUST go over (one way / server authenticated) SSL / 

TLS. 

> 

11

5 Attribute Query Profile 

12 

Attribute queries in DK-SAML must conform to the following: 

The OASIS profile Assertion Query/Request Profile described in 

[SAMLProf] MUST be followed. 

Attribute encodings SHOULD follow the rules specified previously. 

An Attribute Service SHOULD declare as part of its meta data which 

attributes it understands (as specified in [SAMLMeta]). 

SOAP Binding MUST be used. 

The communication between requester and responder MUST be strongly 

encrypted and integrity protected using at least one of the following 

mechanisms: 

o SSL / TLS transport security with server authentication. 

Before requesting private or personal data from an Attribute Service, the 

Service Provider MUST prompt the user for her consent or in other ways be 

able to prove having consent to request the data. 

5.1 Attribute Query Message 

The Consent attribute MUST be included. 

The element MUST be included. 

The element is mandatory and the query MUST be signed 

with a key bound to the requester s X.509 company certificate or equivalent. 

The Service Provider SHOULD identify the Subject by including the uid core 

attribute (with attribute value) in the request. 

The requester SHOULD include the UID core attribute in the request to 

identify the Subject. 

5.2 Response Message 

The element is mandatory. 

If the element is present in the query, the element 

MUST also be present in the response and match the request. 

Any assertion(s) in the response MUST comply with the requirements for 

authentication assertions stated previously (including mandatory signing and 

encryption) with the following exceptions: 

o The Assertion MUST not carry an element. 

o The element in the assertion is optional. 

o The assertion does not have to include the kernel attributes; instead 

the attribute requested in the query are returned. 

>

5.3 Processing Rules 

If the subject specified in the request is not recognized by the Attribute 

Service, it SHOULD return a second-level status code with the following URI 

reference: 

o urn:oasis:names:tc:SAML:2.0:status:UnknownPrincipal 

If attributes are requested which the Attribute Service does not recognize, the 

Attribute Service SHOULD use the following approach: 

o The top-level error code is set to Success if any of the requested 

attributes can be returned; otherwise it is set to 

urn:oasis:names:tc:SAML:2.0:status:Requester. 

o An assertion is returned with all known attributes (provided it is 

allowed by the attribute release policy). 

o A nested status code element is included specifying a status code 

being 

urn:oasis:names:tc:SAML:2.0:status:InvalidAttrNameO 

rValue 

o A sequence of elements are included, one per 

unknown attribute, specifying the name of the unknown attribute to 

the requester. 

If attributes are requested which the Attribute Service does not want to 

disclose to the requestor according to its attribute release policy, the Attribute 

Service SHOULD: 

o Return a second-level status code being: 

urn:oasis:names:tc:SAML:2.0:status:RequestDenied 

followed by a sequence elements describing the 

reason for not disclosing the attribute. 

If a known attribute is requested, but the Attribute Service does not know the 

attribute value for this particular subject, the Attribute Service SHOULD: 

o return an element in the response with the 

corresponding element empty and with the 

reserved attribute xsi:nil with a value of true or 1 (see 

[SAMLCore] p. 31). 

Attribute Services SHOULD use status code URIs defined in [SAMLCore] or 

optionally (if the need appears) specify additional status codes through the 

OIO standardization initiative. 

> 

13

6 Security Requirements 

14 

Note that requirements for signing and encrypting SAML messages or elements have 

already been listed. 

Certificates 

Only certificates present in meta data MAY be used for signing or encryption. 

For signing and encryption of messages, X.509 certificates MUST be used. It 

is left to federations using the profile to determine the allowed types of 

certificates (and hence trust mechanisms). 

A recipient MUST verify signed messages including performing a revocation 

check on the certificate via one of the following methods: 

o CDP Extensions can be used when the certificate includes a 

Certificate Revocation List Distribution Point extension. 

o OCSP can be used to perform an on-line certificate status check. 

o CRL a certificate revocation list can be downloaded from the CA 

periodically. 

Furthermore, the certificate MUST be trust-validated to ensure that it has been 

issued by a trusted CA and that the certificate path is well-formed. 

Transport level security 

The HTTP connection used for the POST and Redirect bindings MUST be 

secured with SSL 3.0 / TLS 1.0. The connection is not required to use client 

authentication since that would mean that the end-user would have to 

authenticate server traffic. Instead, messages transported via this channel will 

be digitally signed. 

Only SSL / TLS cipher suites providing strong encryption are allowed. 

The SSL / TLS (server) certificates SHOULD be trusted by commercially 

available browsers including Internet Explorer, Mozilla, Firefox, Safari and 

Opera. 

Encryption Algorithms 

Encryption algorithm MUST be AES with at least 128 bit keys. 

Signature algorithm MUST be SHA1withRSA or SHA256withRSA with 

minimum 1024 bit modulus. 

Longer AES or RSA keys are permitted. 

When using 1024 bit RSA modulus, federation participants SHOULD prepare 

to upgrade a longer modulus within 6-24 months. 

>

Other 

A Service Provider must enforce a one-time semantics for assertions to ensure 

that they cannot be re-played. 

An Identity Provider SHOULD check that all SSO requests bound to a 

particular session cookie originate from the same client IP address. 

The attribute MUST be checked by Service Providers. 

> 

15

Appendix A: References 

16 

[DK-SAML] OIO Web SSO Profile V2.0 , IT- og Telestyrelsen. 

[SAMLCore] Assertion and Protocols for the OASIS Security Assertion Markup Language 

2.0 , OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml-core- 

2.0-os.pdf 

[SAMLProf] Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 , 

OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml-profiles- 

2.0-os.pdf 

[SAMLBind] Profiles for the OASIS Security Assertion Markup Language (SAML) V2.0 , 

OASIS Standard. http://docs.oasis-open.org/security/saml/v2.0/saml-profiles- 

2.0-os.pdf 

[SAMLTechOver] Security Assertion Markup Language (SAML) V2.0 Technical Overview , 

OASIS, Working Draft 21 February 2007 . 

[SAMLMeta] Metadata for the OASIS Security Assertion Markup Language (SAML) V2.0 , 

OASIS Standard 15 March 2005. 

[SAMLConf] Conformance Requirements, OASIS Security Assertion Language (SAML) 

V2.0 , OASIS Standard 15. March 2005. 

http://docs.oasis-open.org/security/saml/v2.0/saml-conformance-2.0-os.pdf 

[SAMLDepl] SAML V2.0 Deployment Profiles for X.509 Subjects , OASIS Draft, 26 

March 2007. 

[ITTArch] Anbefaling om fælles arkitektur for tværgående autenticitetssikring . 

http://www.oio.dk/files/Horing.B.st.tvergaendeautencitetssikring.v3.pdf 

[ITTAuthLevel] Vejledning vedrørende niveauer af autenticitetssikring . 

http://www.oio.dk/files/Horing.B.st.niv.autentisitetssikring.v3.pdf 

[ITTAttrib] Anbefaling til kerneattributter for bruger . 

http://www.oio.dk/files/Horing.B.st.kerneatrtibutter.v3.pdf 

[ITTUID] 

Anbefaling til unik id-nøgle . 

http://www.oio.dk/files/Horing.B.st.id-nogle.v3.pdf 

[EgovTechApp] Technical Approach for the Authentication Service Component Version 1.0.0 

June 28, 2004 . 

http://www.cio.gov/eauthentication/documents/TechApproach.pdf 

[EgovSAMLProf] SAML Artifact Profile as an Adopted Scheme for E-Authentication . 

http://www.cio.gov/eauthentication/documents/SAMLprofile.pdf 

[EgovIntf] E-Authentication Interface Specifications for the SAML Artifact Profile 

http://www.cio.gov/eauthentication/documents/SAMLspec.pdf 

[NistElAuth] Electronic Authentication Guideline,NIST Special Publication 800-63 

Version 1.0.1 http://www.csrc.nist.gov/publications/nistpubs/800-63/SP800- 

63v6_3_3.pdf 

[OCESPers] Certifikatpolitik for OCES-personcertifikater , Version 3.0, IT- og 

Telestyrelsen 

[OCESMedarb] Certifikatpolitik for OCES-medarbejdercertifikater , Version 4.0, IT- og 

Telestyrelsen 

[GartBusCas] Business Case Fælles login service og rettighedsstyring. 24. april 2006, 

>

Gartner Consulting. 

[EAuth-V2] E-Authentication SAML 2.0 Working Architecture Document, February 2007, 

Version 1-0-0 

[EAuthIntf] E-Authentication Federation Architecture 2.0 Interface Specifications , 

Version 1.0.0, May 4, 2007. 

http://www.cio.gov/eauthentication/TechSuite.htm 

[EAuthTechApp] Technical Approach for the Authentication Service Component , Version 

2.0.0, May 4, 2007. 

[Sikkerhedsbekendtgørelsen] 

http://www.cio.gov/eauthentication/TechSuite.htm 

Sikkerhedsbekendtgørelsen , Datatilsynet, 2001. 

http://www.datatilsynet.dk/include/show.article.asp?art_id=495 

[Terms] Fælles Brugerstyringsløsning, Koncepter og Definitioner , The IT and 

Telecom Agency, Søren Peter Nielsen, Februar 2007. 

[AttrProf] SAML Attribute Service Profile for eGovernment , The IT and Telecom 

Agency, December 2006. 

[LibInterop] SAML 2.0 Interoperability Testing Procedures Version 2.0 , Liberty 

Alliance Project. 

[LibDiscov] Liberty ID-WSF Discovery Service Specification, Version: 2.0 . Liberty 

Alliance Project. 

> 

17

Cover 


Orientering 


Pkt. 4. Status på tiltag for konvergens af standarder indenfor 

føderationsområdet 

Sagstype: Orientering 

Resumé 

Komiteen vil få en mundtlig orientering om status på tiltag for konvergens af 

standarder indenfor føderationsområdet. 


Komiteen besluttede i starten af 2006 at fastholde SAML 2.0 som anbefalet 

føderationsstandard. Samtidig hermed besluttede komiteen også at der skulle 

arbejdes aktivt fra dansk side i dialog med EU, standardiseringsorganisationer, 

andre lande og leverandørerne på at fremme konvergens af standarderne indenfor 

føderationsområdet. På mødet vil der blive givet status på dette arbejde, herunder 

Målrettede aktiviteter fra dansk side og resultater heraf 

Udviklingen indenfor de traditionelle føderationsstandarder og 

specifikationer 

Nye specifikationer og standarder 

EU/Internationale initiativer 

Fremadrettede perspektiver 

Indstilling 

Det indstilles, at komitéen orienterer sig via indlægget på komiteens møde, og 

tilkendegiver såfremt der ønskes en drøftelse af emnet på et kommende 

komitemøde. 



Sagsbehandler 


Telefon 2567 0783 

Telefax 3337 9299 


Cover 


Beslutning 


Pkt. 5. Godkendelse af OIO RASP og OIO UDDI 


Resumé 

ITST har haft OIO RASP-profilerne og OIO UDDI profilen i offentlig høring på 

Høringsportalen. RASP står for Reliable Asynchronous Secure Profile og 

UDDI står for Universal Description, Discovery, and Integration . Samlet set 

understøtter profilerne sikker og pålidelig udveksling af forretningsdokumenter 

via internet (fx elektroniske tinglysningsdokumenter eller regninger) samt at en 

offentlig myndighed eller en privat virksomhed kan udstille de digitale services 

som understøttes, i et fælles service-katalog. 

Styrelsen har modtaget få, men kvalificerede, høringsbidrag. Profilerne er 

efterfølgende blevet justeret, og de parter, som har deltaget i høringen har haft 

lejlighed til at kvalitetssikre ændringerne. På dette grundlag indstilles, at 

komitéen godkender profilerne som OIO standarder med status Anbefalet i 

OIO-kataloget. 


OIO RASP-profilerne og OIO UDDI profilen blev udviklet med det formål at 

understøtte sikker og pålidelig transport af forretningsdokumenter i den offentlige 

og private sektor. 

Ved en profil forstås, at der er foretaget en præcisering (lokalisering) af en eller 

flere anerkendte standarder. Standarden eller standarderne er med andre ord 

profileret (afgrænset) i forhold til en dansk anvendelse. Profileringen sker med 

afsæt i veldefinerede forretningskrav, og profilen gør det lettere at implementere 

standarden, idet en profileret standard er væsentlig mere præcis i forhold til de 

valg, der kan foretages. OIO RASP-profilen er et eksempel på en sådan 

profilering af internationale standarder. 

Forretningskravene til udveksling af forretningsdokumenter var enkle. Det 

samlede sæt af standarder skulle understøtte sikker og pålidelig udveksling af 

forretningsdokumenter via internet. Standarden skulle kunne anvendes af såvel 

store som små offentlige myndigheder og private virksomheder og det skulle 

være muligt at udveksle forretningsdokumenter med parter, som man ikke 

tidligere havde udvekslet data med. Det var ydermere et krav, at en 

kvitteringsmekanisme skulle gøre det muligt for både afsender og modtager at 



Sagsbehandler 

Mikkel Hippe Brun 

Telefon 3337 9220 

Telefax 3337 9299 

E-post mhb@itst.dk

dokumentere, at en given udveksling havde fundet sted (uafviselighed). Disse 

forretningskrav blev formuleret i en åben proces i første halvdel af 2006, hvor 

repræsentanter fra den offentlige og private sektor blev inviteret til 2 

forretningsworkshops. 

Efterfølgende blev der afholdt en stribe tekniske workshops, hvor formålet var at 

identificere de standarder, som i fællesskab kunne understøtte de 

forretningsmæssige behov. Selv om standarderne i OIO RASP og OIO UDDI 

blev identificeret på et meget tidligt tidspunkt, blev profilerne ikke låst fast før til 

sidst. Det var styrelsens vurdering, at det var vigtigt at afprøve profilerne i 

praksis ved at implementere software-biblioteker på hhv. en .NET-platform og en 

Java-platform. Softwarebibliotekerne er lagt ud i open source på Softwarebørsen, 

og er sidenhen blevet anvendt i en række driftsmiljøer; bl.a. hos KMD, Region 

Syddanmark og flere private leverandører til det offentlige. Udviklingen af 

software til understøttelse af OIO RASP og OIO UDDI gav anledning til 

yderligere præciseringer i profilerne, og på denne baggrund sendte ITST profilen 

i offentlig høring. 

Profilernes indbyrdes relationer er illustreret i nedenstående figur: 

Den øverste røde kasse er en anvendelsesramme for OIO RASP og OIO UDDI. 

Mao. for at understøtte sikker og pålidelig udveksling af forretningsdokumenter 

(fx elektroniske regninger i forbindelse med NemHandel) skal der etableres en 

infrastruktur baseret på OIO RASP med underliggende profiler samt OIO UDDI. 

Det er dog muligt at anvende hver af profilerne selvstændigt i forbindelse med 

andre digitaliseringsprojekter. 

I relation til kriterierne for optagelse i OIO-kataloget er der foretaget følgende 

vurdering: 

Åbenhed: Alle de standarder, som indgår i OIO RASP og OIO UDDI stammer 

fra henholdsvis OASIS og W3C. Standarderne er udviklet i en åben proces, hvor 

det har været muligt for enhver at deltage i standardiseringsarbejdet enten 


Side 2

direkte eller i forbindelse med offentlige høringer. Standarderne vedligeholdes 

også fremadrettet af OASIS og W3C, og det vurderes derfor at standarderne lever 

op til kriterierne om åbenhed . 

Forretningsrelevans: OIO RASP og OIO UDDI er udviklet med afsæt i 

forretningskrav fra offentlige myndigheder og private virksomheder. 

Standarderne er en del af den leveranceplan, som er udtrykt i Visioner og 

milepæle for en national IT-infrastruktur , som er udgivet af ITST i 2007. ITST 

har fået særdeles positiv feedback fra alle kanter omkring initiativet, og OIO 

RASP og OIO UDDI er allerede under implementering i flere offentlige 

digitaliseringsprojekter. Det vurderes derfor, at OIO RASP og OIO UDDI lever 

op til kriterierne om at være relevante for forretningen . 

Markedsmæssige forhold: OIO RASP og OIO UDDI er på nuværende tidspunkt 

understøttet af en række leverandører. I forhold til OIO RASP er KMD i færd 

med at udvikle en såkaldt Teknisk Driftsmodel for RASP, som sikrer, at 

standarden kan anvendes bredt i KMD s fagsystemer fra sommeren 2008. 

Tilsvarende har CSC valgt at benytte OIO RASP til tinglysningsprojektet i regi af 

Domstolsstyrelsen. Hvad angår OIO UDDI, findes der en række produkter, som 

understøtter den internationale UDDI-standard. Alle produkter, som understøtter 

abonnementssnitfladen i UDDI 3.0 kan anvendes som fundament for OIO UDDI. 

ITST har ydermere støttet udviklingen af et open source UDDI, som understøtter 

OIO UDDI. Selvom profilerne og de anvendte standarder i sagens natur endnu 

ikke endnu har vundet stor udbredelse, vurderes det, at OIO RASP og OIO UDDI 

som helhed indenfor en kort tidshorisont fuldt ud lever op til kriterierne om 

markedsmæssige forhold . 

Indstilling 

Det indstilles, at komitéen godkender 

OIO RASP version 1.1 som en OIO-standard med status Anbefalet 

o OIO Reliable Messaging Profile 1.1 som en OIO-standard med 

status Anbefalet 

o OIO Basic Security Profile 1.1 som en OIO-standard med status 

Anbefalet 

o OIO Basic Profile 1.1 som en OIO-standard med status 

Anbefalet 

o OIO SMTP Transport Binding for SOAP som en OIO-standard 

med status Anbefalet 

OIO UDDI Profile 1.1 som en OIO-standard med status Anbefalet 

Bilag: 

1. Notat vedrørende høring af OIO RASP Profiler 

2. Notat vedrørende høring af OIO UDDI Profil 

Profiler: 

http://www.softwareborsen.dk/projekter/softwarecenter/serviceorienteretinfrastruktur/serviceorienteret-infrastruktur-ws-profiler 


Side 3

Cover 


Beslutning 


Pkt. 5. Godkendelse af OIO RASP og OIO UDDI 


Resumé 

ITST har haft OIO RASP-profilerne og OIO UDDI profilen i offentlig høring på 

Høringsportalen. RASP står for Reliable Asynchronous Secure Profile og 

UDDI står for Universal Description, Discovery, and Integration . Samlet set 

understøtter profilerne sikker og pålidelig udveksling af forretningsdokumenter 

via internet (fx elektroniske tinglysningsdokumenter eller regninger) samt at en 

offentlig myndighed eller en privat virksomhed kan udstille de digitale services 

som understøttes, i et fælles service-katalog. 

Styrelsen har modtaget få, men kvalificerede, høringsbidrag. Profilerne er 

efterfølgende blevet justeret, og de parter, som har deltaget i høringen har haft 

lejlighed til at kvalitetssikre ændringerne. På dette grundlag indstilles, at 

komitéen godkender profilerne som OIO standarder med status Anbefalet i 

OIO-kataloget. 


OIO RASP-profilerne og OIO UDDI profilen blev udviklet med det formål at 

understøtte sikker og pålidelig transport af forretningsdokumenter i den offentlige 

og private sektor. 

Ved en profil forstås, at der er foretaget en præcisering (lokalisering) af en eller 

flere anerkendte standarder. Standarden eller standarderne er med andre ord 

profileret (afgrænset) i forhold til en dansk anvendelse. Profileringen sker med 

afsæt i veldefinerede forretningskrav, og profilen gør det lettere at implementere 

standarden, idet en profileret standard er væsentlig mere præcis i forhold til de 

valg, der kan foretages. OIO RASP-profilen er et eksempel på en sådan 

profilering af internationale standarder. 

Forretningskravene til udveksling af forretningsdokumenter var enkle. Det 

samlede sæt af standarder skulle understøtte sikker og pålidelig udveksling af 

forretningsdokumenter via internet. Standarden skulle kunne anvendes af såvel 

store som små offentlige myndigheder og private virksomheder og det skulle 

være muligt at udveksle forretningsdokumenter med parter, som man ikke 

tidligere havde udvekslet data med. Det var ydermere et krav, at en 

kvitteringsmekanisme skulle gøre det muligt for både afsender og modtager at 



Sagsbehandler 


Telefon 3337 9220 

Telefax 3337 9299 


dokumentere, at en given udveksling havde fundet sted (uafviselighed). Disse 

forretningskrav blev formuleret i en åben proces i første halvdel af 2006, hvor 

repræsentanter fra den offentlige og private sektor blev inviteret til 2 

forretningsworkshops. 

Efterfølgende blev der afholdt en stribe tekniske workshops, hvor formålet var at 

identificere de standarder, som i fællesskab kunne understøtte de 

forretningsmæssige behov. Selv om standarderne i OIO RASP og OIO UDDI 

blev identificeret på et meget tidligt tidspunkt, blev profilerne ikke låst fast før til 

sidst. Det var styrelsens vurdering, at det var vigtigt at afprøve profilerne i 

praksis ved at implementere software-biblioteker på hhv. en .NET-platform og en 

Java-platform. Softwarebibliotekerne er lagt ud i open source på Softwarebørsen, 

og er sidenhen blevet anvendt i en række driftsmiljøer; bl.a. hos KMD, Region 

Syddanmark og flere private leverandører til det offentlige. Udviklingen af 

software til understøttelse af OIO RASP og OIO UDDI gav anledning til 

yderligere præciseringer i profilerne, og på denne baggrund sendte ITST profilen 

i offentlig høring. 

Profilernes indbyrdes relationer er illustreret i nedenstående figur: 

Den øverste røde kasse er en anvendelsesramme for OIO RASP og OIO UDDI. 

Mao. for at understøtte sikker og pålidelig udveksling af forretningsdokumenter 

(fx elektroniske regninger i forbindelse med NemHandel) skal der etableres en 

infrastruktur baseret på OIO RASP med underliggende profiler samt OIO UDDI. 

Det er dog muligt at anvende hver af profilerne selvstændigt i forbindelse med 

andre digitaliseringsprojekter. 

I relation til kriterierne for optagelse i OIO-kataloget er der foretaget følgende 

vurdering: 

Åbenhed: Alle de standarder, som indgår i OIO RASP og OIO UDDI stammer 

fra henholdsvis OASIS og W3C. Standarderne er udviklet i en åben proces, hvor 

det har været muligt for enhver at deltage i standardiseringsarbejdet enten 


Side 2

direkte eller i forbindelse med offentlige høringer. Standarderne vedligeholdes 

også fremadrettet af OASIS og W3C, og det vurderes derfor at standarderne lever 

op til kriterierne om åbenhed . 

Forretningsrelevans: OIO RASP og OIO UDDI er udviklet med afsæt i 

forretningskrav fra offentlige myndigheder og private virksomheder. 

Standarderne er en del af den leveranceplan, som er udtrykt i Visioner og 

milepæle for en national IT-infrastruktur , som er udgivet af ITST i 2007. ITST 

har fået særdeles positiv feedback fra alle kanter omkring initiativet, og OIO 

RASP og OIO UDDI er allerede under implementering i flere offentlige 

digitaliseringsprojekter. Det vurderes derfor, at OIO RASP og OIO UDDI lever 

op til kriterierne om at være relevante for forretningen . 

Markedsmæssige forhold: OIO RASP og OIO UDDI er på nuværende tidspunkt 

understøttet af en række leverandører. I forhold til OIO RASP er KMD i færd 

med at udvikle en såkaldt Teknisk Driftsmodel for RASP, som sikrer, at 

standarden kan anvendes bredt i KMD s fagsystemer fra sommeren 2008. 

Tilsvarende har CSC valgt at benytte OIO RASP til tinglysningsprojektet i regi af 

Domstolsstyrelsen. Hvad angår OIO UDDI, findes der en række produkter, som 

understøtter den internationale UDDI-standard. Alle produkter, som understøtter 

abonnementssnitfladen i UDDI 3.0 kan anvendes som fundament for OIO UDDI. 

ITST har ydermere støttet udviklingen af et open source UDDI, som understøtter 

OIO UDDI. Selvom profilerne og de anvendte standarder i sagens natur endnu 

ikke endnu har vundet stor udbredelse, vurderes det, at OIO RASP og OIO UDDI 

som helhed indenfor en kort tidshorisont fuldt ud lever op til kriterierne om 

markedsmæssige forhold . 

Indstilling 

Det indstilles, at komitéen godkender 

OIO RASP version 1.1 som en OIO-standard med status Anbefalet 

o OIO Reliable Messaging Profile 1.1 som en OIO-standard med 

status Anbefalet 

o OIO Basic Security Profile 1.1 som en OIO-standard med status 

Anbefalet 

o OIO Basic Profile 1.1 som en OIO-standard med status 

Anbefalet 

o OIO SMTP Transport Binding for SOAP som en OIO-standard 

med status Anbefalet 

OIO UDDI Profile 1.1 som en OIO-standard med status Anbefalet 

Bilag: 

1. Notat vedrørende høring af OIO RASP Profiler 

2. Notat vedrørende høring af OIO UDDI Profil 

Profiler: 

http://www.softwareborsen.dk/projekter/softwarecenter/serviceorienteretinfrastruktur/serviceorienteret-infrastruktur-ws-profiler 


Side 3

Notat 

Notat vedrørende høring af OIO RASP Profiler 

RASP profilerne har været i høring på høringsportalen fra 8. juni til 6. august 

2007. 

Profilerne består af flg. dokumenter: 

OIO Reliable Asynchronous Secure Profile 1.0 

OIO Basic Profile 1.0 

OIO Reliable Messaging Profile 1.0 

OIO SMTP/MIME Base64 Transport Binding for SOAP 1.2 

OIO Basic Security Profile 1.0 

Til advisering af høringen er anvendt udsendelseslisten knyttet til OIO Standarder 

samt enkelte særligt adresserede udvalgt af Styrelsen. 

Der indkom i alt 9 svar på høringen fra flg. organisationer: 

Beskæftigelsesministeriets IT enhed, KMD, Transport- og Energiministeriet, 

SKAT, Banedanmark IT, Erhvervs- og Selskabsstyrelsen, Forsvarskommandoen, 

Patent- og Varemærkestyrelsen, Statens Luftfartsvæsen. 

Af ovenstående havde kun KMD og Forsvarskommandoen bemærkninger til profilernes 

indhold, mens de øvrige har svaret, at de ingen kommentarer havde. 


svar. Som konsekvens af høringssvarene er der planlagt udgivelse af profildokumenterne 

i en ny og revideret version (1.1). 



Holsteinsgade 63 

2100 København Ø 

Telefon 3545 0000 

Telefax 3545 0010 

E-post itst@itst.dk 

Netsted www.itst.dk 

CVR-nr. 2676 9388 

Sagsnr. 07-019906 


Telefon 33379220 



Kommentarerne er fordelt på flg. dokumenter: 

1 - 19 samt 23 går på dokumentet OIO RASP Profile 1.0 

20 - 22 går på dokumentet OIO RASP Profile 1.0 

24 - 27 går på dokumentet OIO Basic Security Profile 1.0 

28 går på dokumentet OIO Reliable Messaging Profile 1.0 

Kommentar 1 

Da RASP er en profil baseret på andre profiler, ville det være rart med en struktur, 

der fortæller hvad der er baseret på hvad med links til, hvor man kan finde 

nyeste version hurtigt. Det er formodentlig det som Reference-afsnittet sidst i 

RASP profilen er beregnet til, men afsnittet er mangelfuldt. 


Referenceafsnittet opdateres, og der laves en ny tegning med lagene i stakken, så 

man kan se, hvad der bygger på hvad. 

Kommentar 2 

Der er redundans mellem de bagvedliggende profiler og selve RASP. RASP bør 

kun indeholde det som ligger ovenpå eller skærper de andre profiler - ikke gentage 

deres indhold. 


Redundans fjernes, således at det kun er ændringer eller skærpelser af de underliggende 

standarder og profiler, der medtages. 

Kommentar 3 

OIO UDDI 1.0 profil-beskrivelsen mangler helt / er ikke synlig. Der er ikke link 

til den fra RASP profilen eller fra den hjemmeside, hvor høringen er beskrevet. 


Det er besluttet at tage OIO UDDI profilen ud af RASP, så den fremstår som en 

uafhængig og selvstændig profil. På den måde kan man implementere RASPkonforme 

web services uden nødvendigvis at anvende OIO UDDI profilen. UD- 

DI dokumentet vil komme i en særskilt høring. 

Dette er en beklagelig redaktion fejl at links til UDDI-profilen ikke blev fjernet. 

Kommentar 4 

På høringssiden er der et link til OIO SMTP/MIME Base64 Transport Binding 

for SOAP 1.2, men den fremgår ikke rigtigt af RASP (kun i R1004 - og her henvises 

til version 1.0). Skal den tolkes som en standard under OIO Basic Profile 

1.0, eller hvordan hænger den sammen med RASP? Og bør der ikke være bokse i 

dette dokument, ligesom der er det i profilerne, til at angive hvor der sker en præcisering 

af internationale standarder? 


2


Kommentaren beror på en misforståelse af versionsnumre: 1.2 referer til versionen 

af SOAP standarden, mens den aktuelle version af OIO profilen er 1.0. Titlen 

på profilen ændres for at forhindre denne misforståelse i fremtiden. Årsagen til, 

at der ikke er "bokse" i dokumentet er, at der er tale om en ny profil, der ikke 

præciserer en eksisterende standard eller profil. 

Kommentar 5 

Checklisterne sidst profilerne (appendiks) mangler synkronisering med indholdet 

i selve profil-beskrivelsen. Der er eksempler på forskelle i både ordlyd (OIO Reliable 

Messaging 1.0 K1001) og indhold (OIO Basic Profile 1.0 K1002). 


Dokumenterne revideres, så der er overensstemmelse. 

Kommentar 6 

Der er dansk tekst flere steder i profilerne, der beskriver det videre arbejde - det 

bør fjernes og erstattes af den faktuelle information. De redaktionelle mangler 

gør det svært at danne et overblik over hvad profilerne egentlig indeholder/omfatter 

og det er derfor næsten umuligt at give et endeligt høringssvar herpå. 

Det vil være hensigtsmæssigt med en redaktionel iteration ovenpå denne høring 

efterfulgt af endnu en høringsrunde. 


Dokumenterne revideres med henblik på at fjerne den danske tekst samt andre 

redaktionelle mangler. 

Kommentar 7 

Mange af de involverede standarder er på forkant i forhold til, hvad der understøttes 

fra værktøjsleverandørerne. Det kan være et problem for dem der skal implementere 

standarden hurtigt, fordi man kan blive tvunget ud i selv at implementere 

teknisk understøttelse af standarden eller alternativt lave en teknologi opgradering 

(hvis der forefindes værktøjsstøtte fra leverandøren i nyeste version af 

værktøjet). 


Standarderne, som indgår i RASP er valgt i et bredt samarbejde med offentlige 

myndigheder og private leverandører. Man stod med valget mellem en række ISO 

15000 standarder som kunne anvendes som alternativ til de WS-* standarder, 

som indgår i RASP. ISO 15000 standarderne har opnået en større grad af modenhed, 

men leverandørtilslutningen er for ringe. Det blev derfor valgt at RASP 

skulle basere sig på de mere umodne WS-* standarder, som de største leverandører 

havde tilkendegivet deres støtte til. For at gøre det lettere for leverandører at 

understøtte RASP, har ITST udviklet 2 open source toolkits til hhv. .NET og Java, 

som gør det til en overkommelig opgave at understøtte RASP. Disse toolkits 

vil blive vedligeholdt af Styrelsen indtil 2010. 


3

Kommentar 8 

Der er behov for en verifikation af, at leverandørernes implementering af standarderne 

i profilen er OK. 


Der er ikke planer om et egentligt verifikationsprogram. ITST har implementeret 

en reference-klient, som leverandører kan teste deres løsninger imod. Der er også 

opsat et antal test-endpunkter, som det ligeledes er muligt at teste med. Lakmusprøven 

for om en leverandørs løsning er kompatibel, er at den kan interagere problemfrit 

med disse løsninger. 

Kommentar 9 

De foreliggende .NET og Java-toolkits på 

http://softwareborsen.dk/projekter/softwarecenter/serviceorienteret-infrastruktur 

er for nuværende i beta-versioner (1.0rc1p2) og frarådes anvendt til produktive 

formål. Dokumentations- og implementeringsmæssigt bærer ingen af de to toolkits 

præg af at være release-kandidater og OIO RASP profilen er ikke komplet 

funktionsmæssigt dækket af de foreliggende toolkits. Det vanskeliggør yderligere 

situationen for de første der skal implementere profilen. Java toolkittet baserer 

sig på en modificeret udgave af open source standard biblioteket Axis 2, mens 

.NET toolkittet baserer sig på .NET framework 3.0, der understøtter WS- 

ReliableMessaging 1.0. OIO Reliable Messaging Profile version 1.0 baserer sig 

imidlertid på WS-ReliableMessaging 1.1. Disse forhold antyder mulige interoperabilitetsproblemer 

- ikke mindst i forhold til andre tekniske platforme. 


Ifølge planerne for udvikling af RASP toolkits skulle den endelige driftsmodnede 

version først være tilgængelig til september 2007. Den beta-version som var tilgængelig 

på Softwarebørsen stammede tilbage fra maj måned. Alle interoperabilitetsproblemer 

blev løst hen over sommeren, og dette er afspejlet i bibliotekerne. 

Kommentar 10 

Af overordnede kommentarer i øvrigt er det desuden uklart, på hvilken måde 

OIO-RASP profilens lokale logon forholder sig til parallelle offentlige tiltag til 

etablering af en fælles offentlig logon service. 


Det er ikke tanken, at OIO-RASP profilen skal etablere logon med en session, og 

det er derfor i første omgang ikke relevant for profilen. Antydninger af dette vil 

blive fjernet i kommende versioner af profilen. IT & Telestyrelsen har planlagt en 

analyse af identitetsbaserede web services i efteråret, der vil behandle sammenhænge 

mellem SAML og sikre web services. 

Kommentar 11 


4

SMTP er tænkt anvendt hos de små parter. Men dette er teknologisk set meget 

avanceret og dermed ikke noget, slagteren nede på hjørnet umiddelbart kan finde 

ud af. Der er derfor behov for en relativt detaljeret implementeringsbeskrivelse, 

gerne suppleret af konkrete implementeringseksempler. 


Den reference-klient, som ITST har udviklet understøtter SMTP. Klienten er tilgængelig 

med dokumentation på Softwarebørsen, og bør danne et godt grundlag 

for at kunne implementere tilsvarende løsninger. Evt. på grundlag af den kodebase, 

der er tilgængelig i klienten allerede. 

Kommentar 12 

I R1004 og i referencelisten er OIO SMTP/MIME Base64 Transport Binding for 

SOAP 1.0 nævnt begge steder - men på selve høringssiden er der et link til version 

1.2. Hvilken er gældende? 


Dette er en fejl på høringssiden; se i øvrigt svar til kommentar 4 ovenfor. 

Kommentar 13 

I referencelisten nævnes kun to af de bagvedliggende profiler. Linket til OIO Basic 

Profile 1.0 er desuden forkert (det rammer en foreløbig udgave af profilen). 


Linket rettes og referencelisten opdateres. 

Kommentar 14 

Omkring OIO Basic Security Profile er angivet, at payload skal krypteres (nederst 

side 9); der bør være en blå boks indeholdende dette, da det er en skærpelse 

ift. WS-BasicSecurityProfile i sig selv. 


Dette præciseres i kommende udgaver, så det klart fremgår, at samtlige meddelelser 

skal krypteres og signeres. 

Kommentar 15 

I K2007 henvises til en 'OWSA Signature' - denne profil mangler / er ikke synlig. 


Der burde henvises til OIO Basic Security Profile i stedet. Dette indføres i kommende 

udgaver af profilen. 

Kommentar 16 


5

Under OIO Reliable Messaging 1.0-afsnittet er en henvisning til en figur, som 

ikke er medtaget. 


Korrekt. Henvisningen fjernes. 

Kommentar 17 

Definitionen for integritet under Business requirements" er lidt uheldig: "Only 

the sender and the receiver may know the content of the business document" har 

intet med integritet at gøre, men burde i stedet flyttes over i en ny definition kaldt 

"Confidentiality". 


Korrekt. Definitionen korrigeres. 

Kommentar 18 

Der var mange gode tegninger i den tidligere version 0.9. F.eks. var der i version 

0.9 de involverede profiler som byggeklodser, side 4, OIO server struktur, side 8, 

udveksling af et dokument (sekvensdiagram), appendix 2, side 19, Disse figurer 

var med til at give et godt overblik og en god forståelse af arkitekturen. 


Disse genindføres i revideret form. 

Kommentar 19 

I version 0.9 var profilen meget specifik omkring tidsintervaller ved genforsendelse 

af beskeder, når disse ikke kan leveres. Dette er helt udeladt i version 

1.0. Vi finder, at profilen bliver stærkere af at have nogle specifikke tidsangivelser. 


De specifikke tids-intervaller var i modstrid med ønsket om at anvende "exponentiel 

backoff". Det vurderes hensigtsmæssigt, at sådanne konfigurationsparametre 

kan behandles som en politik separat fra profilen, hvilket er årsagen til, at 

det er udeladt. 

Kommentar 20 

Side 11: Der er en henvisning til OIO WSDL, men denne beskrivelse er ikke synlig 

/ mangler. 


OIOWSDL er i høring på høringsportalen hvorfor der henvises til denne. 

Kommentar 21 


6

Side 16 nederst: henvisningen til ISB (InfraStructure Base) er vel forkert; det bør 

være en henvisning til OIO UDDI i stedet. 


Korrekt, beskrivelsen ændres. 

Kommentar 22 

Der har sneget sig for mange metodeanvisninger ind i profilen; alt hvad der 

kommer i appendikset Explanation and central standards er faktisk en metodebeskrivelse 

og grundlæggende vidensopbygning, som ikke hører hjemme i selve 

profilen. Appendiks bør fjernes, og så bør der i stedet laves en generel vejledning 

i et separat dokument, som omfatter samtlige profiler. En generel beskrivelse af, 

hvordan man kommer i gang med RASP og de øvrige profiler, er nemlig relevant 

nok. 


Afsnittet fjernes fra profilen. 

Kommentar 23 

Det er uklart hvilken type af certifikater (MOCES, POCES, DOCES, VOCES), 

der kan anvendes. På side 10 er én beskrivelse; i K1006 er noget andet angivet og 

i opsamlingen noget helt tredje. 


Profilen rettes så kun DOCES og VOCES tillades - DOCES anbefales. 

Kommentar 24 

Sender/Receiver og Consumer/Provider bruges lidt i flæng. Det vil lette læsevenligheden, 

hvis det blev ensrettet og sprogbruget mere konsekvent. 


Formuleringerne tilrettes, så de er konsistente indenfor hvert profildokument. Lavere 

niveau er i web service stakken anvender ofte sprogbrugen sender / receiver 

mens højere lag i stakken ofte benytter terminologien consumer / provider. 

Kommentar 25 

Side 6: Hvad menes med The model [xx] is based . ? 


Frasen erstattes af "The profile is based on the following elements". 

Kommentar 26 

Side 9: Reference til WSI-BasicSecurityProfile er problematisk; WSI- 

BasicSecurityProfile er under udarbejdelse og da OIO Basic Security Profile læner 

sig op ad denne (ifølge K1001), betyder det at der er risiko for ændringer og 


7

stor sandsynlighed for manglende værktøjsunderstøttelse. Hvis I- 

BasicSecurityProfile er en draft, er OIO Basic Security Profile så også en draft? 


WS-I Basic Security Profile har været færdig i version 1.0 siden 30. marts 2007. 

Se http://www.ws-i.org/Profiles/BasicSecurityProfile-1.0.html 

Kommentar 27 

Side 15: TDC er den nuværende og kørende OCES operatør, men da OCES udbuddet 

er annonceret, så det er mere passende at henvise til den aktuelle frem 

for en konkret. Ellers er der risiko for at skulle ændre, hvis opgaven går over til 

en anden operatør. 


Beskrivelsen omarbejdes så en liste af de nødvendige kontroller fremgår. 

Kommentar 28 

K1001 henviser til, at WS-ReliableMessaging 1.1 skal anvendes. Denne er først 

lige blevet godkendt i juni måned, så værktøjsunderstøttelsen er for nuværende 

sparsom; på Microsoft platformen kommer den med i .Net framework 3.5 og på 

Java platformen er det uklart, hvornår der kommer understøttelse. Det kan derfor 

blive omkostningsfuldt for first movers at implementere profilen. 


Jf. tidligere svar, er der nu fuld interoperabilitet mellem .NET 3.0 og Java Axis2 

med Sandesha og Rampart udvidelserne. De toolkits som ITST stiller til rådighed 

i kombination med gratis hands on workshops sikrer, at en udvikler hurtigt kan 

komme i gang. 

Kommentarer fra Forsvarskommandoen 

Kommentar 29 

Forsvarskommandoen skal bemærke, at, med baggrund i udveksling af data internationalt, 

ses det hensigtsmæssigt at tage udgangspunkt i den af OASIS ratificerede 

profil benævnt SAML. Denne profil er dog mere omfattende end den foreslåede 

nationale, men der kan evt. foretages fravalg i den internationale profil ved 

udarbejdelsen af den nationale profil. 


SAML dækker primært autentifikation, SSO og udveksling af attributter i scenarier, 

hvor en bruger via en browser tilgår en applikation (i bred forstand). I RASP 

er der tale om system-system kommunikation, der ikke sker på vegne af en bruger, 

og i dette scenerie er SAML mindre velegnet. For system-system kommunikation, 

hvor kaldet sker på vegne af en bruger, kan det give mening at medsende 


8

ugerens SAML token, men dette er der ikke tale om i RASP. Iøvrigt planlægger 

Styrelsen et studie af identitetsbasered web services i efteråret, hvor denne 

problemstilling vil blive behandlet. 


9

Notat 

Notat vedrørende høring af OIO UDDI Profil 

OIO UDDI profilen har været i høring på høringsportalen fra 31. oktober til 30. 

november 2007. 

Til advisering af høringen er anvendt udsendelseslisten knyttet til OIO Standarder 

samt enkelte særligt adresserede udvalgt af Styrelsen. 

Der indkom i alt ét svar på høringen (fra KMD). 


svar. Som konsekvens af høringssvarene er der planlagt udgivelse af profildokumentet 

i en revideret version (1.1.1). 



Holsteinsgade 63 

2100 København Ø 

Telefon 3545 0000 

Telefax 3545 0010 

E-post itst@itst.dk 

Netsted www.itst.dk 

CVR-nr. 2676 9388 

Sagsnr. 07-027214 





Kommentar 1 

Anvendelsen af versaler og minuskler i forbindelse med keywords MUST og 

SHOULD er inkonsistent. 


Dette er korrekt. Dokumentet tilrettes, så anvendelsen er konsistent. 

Kommentar 2 

Referencer i profilen side 17 bør være links og tjekkes. Vi har ikke kunnet 

finde OIO RASP 1.1 profilen [RASP]. [UDDI-3.0] henviser til dokument af 

19/7-02 er det korrekt? [OIOSI-ARCH] henviser til en draft version er 

det korrekt? 


Dokumenternes titler vil blive suppleret med links, hvor det er muligt. Links har 

dog den klare ulempe, at de kan ændre sig over tid. 

OIO RASP version 1.1 er en planlagt opdatering af OIO RASP 1.0, hvor høringssvar 

og input er blevet indarbejdet. Dokumentet offentliggøres snarest. 

[OIOSI-ARCH] dokumentet, der henvises til, er seneste version. Nye versioner 

vil blive publiceret på http://www.oio.dk 

Kommentar 3 

UDDI profilen afgrænses til NemHandel, men profilen indgår samtidig i OIO 

RASP, der er en generel model for webservice-kommunikation. Dette forekommer 

inkonsistent. 


Det medgives, at sammenhængen mellem profilerne har været udtrykt lidt uklart. 

Sammenhængen er, at OIO UDDI ikke er en obligatorisk del af RASP, men snarere 

er en profil, som står ved siden af RASP. Man kan eksempelvis forestille 

sig RASP web services, der ikke anvender OIO UDDI profilen. 

Samtidig er OIO UDDI profilen ikke strengt bundet til NemHandel, selvom dokumentet 

giver indtryk af dette. Hensigten har været generel understøttelse af 

run-time opløsning af forretningsniveau-nøgler til fysiske web service endepunkter. 


2

Profilerne opdateres, så ovenstående fremgår tydeligere. 

Kommentar 4 

Vi savner henvisning til en implementeringsmodel/SLA. Hvorledes undgås 

et single point of failure i infrastrukturen? Jf. motivationen for profilen bullit 

1 og 3. 


OIO UDDI er alene en specifikation for en datamodel og en søgearkitektur. Det 

er således udenfor profilens område at specificere en arkitektur for en bestemt 

løsning med et givet niveau af servicekvalitet, herunder adressere hvorledes et 

givet niveau af tilgængelighed opnås ved brug af konkrete teknikker som clustering, 

spejling, replikering etc. 

Kommentar 5 

Af hensyn til referencer kunne kravene, som UD-1004 henviser til, trækkes 

ud i et appendix eller anden nummereret oversigt. 


Det kunne man godt gøre, men det er fundet hensigtsmæssigt for læsevenligheden 

at holde dette i hoveddokumentet. 

Kommentar 6 

Kravene i UD-1005 er tautologiske. 


Ved tautologier forstår vi udtryk, der er logisk sande per definition. Det kan vi 

ikke genkende kravene i UD-1005 som?! Vi mener ikke engang, at de følger som 

logisk konsekvens af andre krav i dokumentet. 

Kommentar 7 

Figur 2 bør udvides med mængdeangivelser på relationerne. Derved kan 

det meste af listen under "Requirements for UDDI Entities" flyttes til appendix 

med en note om at det er angivet på figur 2. 


3


Figur 2 er en illustration af, hvorledes en konkret registrering kan se ud for en 

konkret organisation med et enkelt endepunkt. Der er således ikke tale om en 

normativ figur med specifikationsformål - sigtet er rent pædagogisk. Det giver 

derfor ikke mening at lade figuren erstatte kravene i teksten, der skal dække det 

generelle tilfælde. 


4

Cover 


Drøftelse 


Pkt. 6. Standardiseringsorganisationers åbenhed (D) 

Sagstype: Drøftelse 

Resumé 

Som tidligere drøftet er der en undersøgelse i gang om standardiseringsorganisationernes 

åbenhed. Dette arbejde nærmer sig sin afslutning og 

resultaterne forventes at tegne sig, når mødet holdes. 


Der orienteres mundtligt på mødet om de foreløbige resultater. 

Indstilling 

Det indstilles, at komitéen drøfter de foreløbige resultater. 



Sagsbehandler 

Søren Klostergaard 

Telefon 3337 9298 

Telefax 3337 9299 

E-post skp@itst.dk

Cover 


Beslutning 


Pkt. 7. Oversigt over standarder og beslutning om prioritering af tekniske 

standarder 


Resumé 

Hidtil har forslag til standarder i forslag og høring været fremlagt på OIO-itarkitekturkomitémøderne 

løbende. På mødet den 11.10.2007 blev der rejst 

spørgsmål til behandlingen af nogle af disse standarder, særligt vedrørende 

beskrivelse af processer. 


Foruden den sædvanlige liste over standarder under behandling er der vedlagt et 

forslag til prioritering af de standarder, der er indleveret som forslag. 

Prioriteringerne skal forstås således: 

Prioritet 1 tages under behandling primo 2008 

Prioritet 2 tages under behandling i første halvår 2008 

Prioritet 3 indgår samlet prioritering sammen med kommende forslag 

+ angiver, at standarden allerede er under behandling eller beskrevet 

andetsteds. 

Endvidere er der udarbejdet en indledende redegørelse for procesrelevante 

standarder. 

Indstilling 

Det indstilles, at komitéen 

tager den vedlagte Oversigt over standarder under behandling til 

efterretning 

tiltræder den foreslåede prioritering. 

Bilag 

1: Oversigt over standarder under behandling 

2: Forslag til prioritering af forslag til tekniske standarder 

3: Redegørelse for procesrelevante standarder. 



Sagsbehandler 

Søren Klostergaard Pedersen 

Telefon 3337 9298 

Telefax 3337 9299 

E-post skp@itst.dk

Bilag 1, pkt. 7, oio-it-arkitekturkomitéens møde den 13. december 2007 

Oversigt over standarder under behandling 

Den offentlige it-standardiseringsproces består i en række trin, som standarder 

gennemløber på deres vej mod godkendelse: 

Forslag => Validering => Høring => Vedtagelse => OIO IT-standard 

Indleveret som forslag: Dette er det første trin, hvor en aktør har foreslået en 

standard eller sekretariatet bag OIO-kataloget har identificeret et behov. 

Under validering: Dette indebærer, at sekretariatet undersøger tekniske, 

økonomiske og juridiske aspekter, der kan øve indflydelse på udformningen eller 

bedømmelsen af standarden. 

I høring: Valideringen er afsluttet, og standarden er i åben høring. 

Vedtagelse: Her er standarden under afsluttende behandling. Høringsprocessen er 

afsluttet, og høringssvarene er under behandling. Giver disse ikke anledning til 

væsentlige ændringer vedtages standarden som OIO-standard i enten oio-itarkitekturkomitéen 

eller i OIO-datastandardiseringskomitéen. 

Anbefalet eller godkendt: Standard som er blevet optaget i OIO-kataloget. 

På http://www.oio.dk/standarder/underbehandling findes en beskrivelse af de 

enkelte procestrin. 

NB. Beskrivelsen af standardiseringsprocessen er i øjeblikket under revision. 

Ændringer i oversigten i er markeret med kursiv. 

Oversigt over standarder under behandling 

1. Indleveret som forslag 

Tekniske standarder 

Message Queuing kategori (IBM WebSphere MQ, MSMQ og Oracle AQ 

mfl.) 

SCORM (standarder til web-baseret e-læring) 

OWL (ontologibeskrivelser for semantisk web) 

ISO 15000-2 (metadata som identificerer modtager og afsender og 

specificerer yderligere fejlhåndtering og sikkerhed.) 

WiMAX (højhastigheds trådløse netværk) 

WPA (Wifi-adgangskontrol) WEPs status revideres samtidig 

Bankernes Net-ID 

DNG (adobe billedformat) 

Ikke-webbaserede standarder (EDGE, WAP, UMTS, GPRS, SMS, MMS 

etc.) 

SNMP3 (netværksovervågning og -styring) (SNMP2s status revideres) 

MNG og SVG (grafik/multimedia standarder) 

GIS-kategorien overvejes udvidet 

WS-BPEL 2.0 (beskrivelse af forretningsprocesser) (WS-BPEL TC 

forventer OASIS godkendelse 15. oktober) 

BPMN (modellering af forretningsprocesser) (afventer WS-BPEL 

godkendelse i OASIS)

XPDL 2.0 (udveksling af forretningsprocesser) (afventer WS-BPEL 

godkendelse i OASIS) 

Web Service Transaction Framework (transaktioner mellem webservices) 

(afventer WS-BPEL godkendelse i OASIS) 

OpenDocument (præsentation) 

Datastandarder 

HR-XML opdatering, AMS 

OIOUBL, ITST 

Nummeroplysning, ITST 

Processtandarder 

Ingen 

FESD-standarder 

Ingen 

Metodestandarder 

BS 15.000 (beskrivelse af "best practices" inden for it-service ledelse) 

ISO 2000 (konstruktion af benchmarks for it-service ledelse) 

BCM (Business-Centric Methodology) 

2. Under validering 


Procesrelevante standarder 


HML (i vejledningsfasen) 

eSyn, Færdselsstyrelsen (til vurdering i XML-Sekretariatet) 

Motor, SKAT 

eIndkomst, SKAT (til vurdering i XML-sekretariatet) 

Jordemoderregistrering, CPR (afventer tilretning) 

OWSA-SD, KMD 

Sikker e-post, FESD 

Sammenlignelig Brugerinformation, Ementor 

Opdatering af diverse elementer, CPR 

Jordemoderregistrering, CPR 

Diverse blanket-elementer, Capevo 

Tid, ITST 

Sager og Dokumenter, FESD 

Nemkonto for private betalere, KMD 


Ingen 


Side 2


FESD Logning og Sikkerhed 

3. I høring 


RTF (Rich Text Format) 

WPD (Word Perfect Document) 

ODS (OpenOffice regnearksformat) 

XLSX (Office XML regnearksformat) 

WB2 (Quattro Pro regnearksformat) 

CSV (Kommasepareret tekst) 

JPEG (Joint Photographic Expert Group) 

GIF (Graphics Image Format) 

TIFF (Tagged Image File Format) 

BMP (Windows Bitmap) 

ISO Latin-1 (Tegnsæt) 

UCS (Tegnsæt) 

UTF-8 (Tegnsæt) 

DTD (Document Type Definition) 

IRC (Internet Relay Chat) 

SCORM (E-læringsstandard) 

NNTP (Network News Transfer Protocol) 

IPsec (Internet Protocol Security) 

UDP (User Datagram Protocol) 

TCP (Transmission Control Protocol) 


Ingen 


Ingen 


Ingen 

4. Under afsluttende behandling 


Ingen 


3 Grundbegreber, Servicestyrelsen (afventer godkendelse af SSU for 

Socialsektoren) 

Administrativt vejnummer, Vejdirektoratet 


Ingen 


Side 3


FESD Skanning v. 2.0 

FESD Datafølgeseddel 

FESD Grænseflade til CMS-løsninger 

5. Anbefalede standarder de sidste fire måneder 


Ingen 


Seks beskrivelsesfelter, Capevo 

Registreringskonto v1.1.0, Silkeborg Data 

Emnesystematik, FESD 

GIS-integration, FESD 

Ændring af pensionist-status, KMD 


Ingen 


Ingen 


Side 4

Bilag 2, pkt. 7, oio-it-arkitekturkomitémøde d. 13. december 2007 

Forslag til prioritering af indleverede forslag til tekniske standarder 

Kategori i 

Standard Forslag Ejer 

OIO-kataloget 

Status i 

OIO-kataloget 

Foreløbig 

Forretningværdi Prio 

ISO 15000-2 

metadata som 

identificerer modtager 

og afsender og 

specificerer yderligere 

fejlhåndtering og Ny tekn. 

Tekniske standarde/Dataintegration/ 

sikkerhed 

standard ISO 

Elektronisk handel 1 Til validering 

Ny tekn. 

Tekniske standarder/Interkonnektivitet/ 

Bankernes Net-ID standard 

Sikkerhed 1 Til validering 

OWL 

Tekniske standarder\Indholdsstyring og Metadata 

ontologibeskrivelser for Ny tekn. 

Definition\ 

I anledning af en borger centreret udvikling er 

semantisk web standard W3C 

Metadatabeskrivelse 

der behov gfor en fælles yontologi. g g g 1 Til validering 

WS-BPEL 2.0 

med at beskrive processer, er der et behov for 

beskrivelse af Ny tekn. 

Tekniske standarder/Net-baserede tjenester/ 

fælles format og identifikation af fælles 

I validering af 

forretningsprocesser standard OASIS 

Business Process Management Kommende processerg y g g g 1 procesfamilien 

BPMN 

med at beskrive processer er der et behov for 

modellering af Ny tekn. 




forretningsprocesser standard OMG 

Business Process Management 

processer 1 procesfamilien 

XPDL 2.0 


udveksling af Ny tekn. Workflow Management Tekniske standarder/Net-baserede tjenester/ 



forretningsprocesser standard Coalition (WfMC) Business Process Management 


ebBP 

I anledning af at flere myndigheder er i gang 

ebXML Business 


Process Specification Ny tekn. 




Schema 

standard OASIS 

Business Process Management 


Web Services Ny tekn. 

Tekniske standarder/Net-baserede 


Transaction 


tjenester/Advanced Web Services Features Kommende 2 WS-stakken 

WPA2 

I anledning af at flere myndigheder udnytter 

sikkerhed på trådløse Ny tekn. 

Interkonnektivitet/Wireless Networking/ 

trådløst netværk, er der behov for forbedret 

netværk 

MOM 

standard IEEE 

Security Erstatter WEP sikkerhed qua WEP erstattes med WPA 2 Til validering 

Message Oriented 

Interkonnektivitet/ 

Middleware Ny tekn. kategori Ikke standardiseret. Message Oriented Middleware 2 Til validering 

WiMAX 

Tekniske standarder/Interkonnektivitet/Wireless 

I anledning af at det offentlige bli'r mere 

afhængig af digitale netværk, er der et øgende 

behov for at i alle situationer kunne tilgå digitale 

netværk. I tilfælde af begrænset tilgang på 

højhastigheds trådløse Ny tekn. 

Networking/ 

kabel baseret netværk, er trådløst en mulighed. 

netværk 

NAC 

standard IEEE 

LAN Standards 

F.eks. naturkatastrofer 2 Til validering 

Network Access Ny tekn. 


Control 

standard Ikke standardiseret Sikkerhed 3 Til validering 

Fortsat 

arbejde

DNG 

adobe billedformat 

EDGE, WAP, UMTS, 

GPRS, SMS, MMS 

MNG 

Multiple-image 

Network Graphics 

ODP 

Open Document 

Presentation 

SCORM 

Shareable Content 

Object Reference 

Model 

WPA 

sikkerhed på trådløse 

netværk 

SNMP3 

netværksovervågning 

og -styring 

SVG 

Scalable Vector 

Graphics 

GIS 

Geografiske 

Informations System 

Ny tekn. 

standard ADOBE 

Ny tekn. 

standard 

Ny tekn. 

standard 

Ny tekn. 


Ny tekn. 

standard 

Tekniske standarder/Brugergrænseflader/ 

Grafik 


Wireless Networking 


Grafik 

Tekniske standarder/Dokument- og dataudveksling/ 

Præsentation 

Et fælles fotografisk format findes allerede i 

JPEG men i tilfælde af krav på oprindelig 

digitalt negativ (RAW) 

I anledning af at det offentlige bli'r mere 

afhængig af digitale netværk, er der et øgende 

behov for at i alle situationer kunne tilgå digitale 

netværk. I tilfælde af begrænset tilgang på 

kabel baseret netværk, er trådløst en mulighed. 

3 Til validering 

F.eks. naturkatastrofer 3 Til validering 

GIF dækker behovet og patenterne er udløbet 

men MNG kan på sigt erstatte animeret GIF 3 Til validering 

Det vurderes, at standarden vil blive interessant 

i takt med, at ODF vinder større udbredelse 

Tekniske standarder/Forretningsområdespecifikke 

standarder/E-læring: Godkendt + 

3 Til validering 

Indgår i 

revisions 

høring 07 

Ny tekn. 

standard + se WPA2 

Ny tekn. 

standard IETF 

Ny tekn. 

standard W3C 

Udvidet tekn. 

kategori 

Tekniske standarder/ 

Operationer 

Anvendelig 

(SNMP2) + 


Grafik Kommende + 

Tekniske standarder/Forretningsområdespecifikke 

standarder/ 

Geografisk Information + 

Indgår i revision 

07 med 

uændret status 

SVG Indgår i 

revision 07 med 

uændret status 

GIS Indgår i 

revision 07 med 

uændret status

Bilag 3, pkt. 7, oio-it-arkitekturkomitémøde d. 13. december 2007 

Procesrelevante standarder 

Nærværende dokument beskriver de processtandarder der skal undersøges nærmere i forbindelse med OIO 

standardisering på processtandard området. 

Business Process Modeling Notation (BPMN) 

Business Process Modeling Notation (BPMN) er en standardiseret grafisk notation for tegning af 

forretningsprocesser i en arbejdsgang (workflow). BPMN blev udviklet af Business Process Management 

Initiative (BPMI) og er siden 2005 blevet vedligeholdt af Object Management Group. BPMN findes i øjeblikket 

i en version 1.0 og version 2.0 er til høring. Det primære formål med BPMN er at sørge for en standard 

notation, som er forståelig for forretningsinteressenter og dermed dække det gab, der hyppigt forekommer 

mellem forretningsprocesdesignet og implementeringen. 

(http://www.bpmn.org/) 

Business Process Execution Language (BPEL) 

Business Process Execution Language (BPEL) er et forretningsprocesmodelleringssprog som kan udføres. Da 

BPEL ikke indeholder alle nødvendige semantiske og proces konstruktioner, er det derfor ikke muligt at 

modellere og udføre enhver forretningsproces. Af denne grund bruges BPEL ofte sammen med 

programmeringssprog eller properitære scripting sprog indeholdt i kommercielle implementeringer af workflow 

eller integrations brokere systemer. BPEL bliver vedligeholdt af OASIS i en version 2.0 af WS-BPEL. 

(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=wsbpel) 

XML Process Definition Language (XPDL) 

XML Process Definition Language (XPDL) er et format standardiseret af Workflow Management Coalition 

(WfMC) til at udveksle forretningsprocesdefinitioner mellem forskellige workflow produktion- XPDL definere 

XML skemaer til at specificere dele af et workflow. XPDL er designet både til at udveksle det grafiske og 

semantiske en workflow forretningsproces. Herved adskiller XPDL sig fra BPEL, som er fokuseret på 

udførselsaspektet af en proces. 

(http://www.wfmc.org/standards/xpdl.htm) 

ebXML Business Process Specification Schema (ebBP) 

ebXML Business Process Specification Schema(ebBP) definerer et standard sprog til at konfigurerer forretningssystemer til 

at udføre forretningsprocesser mellem forretningspartnere. ebBP bliver vedligeholdt af OASIS. 

(http://www.oasis-open.org/committees/tc_home.php?wg_abbrev=ebxml-bp)

Cover 


Orientering/Drøftelse 


Pkt. 8. ODF/OOXML vejledning, afsluttet pilotforsøg, laboratorietest, status 

m.m. 

Sagstype: Orientering/Drøftelse 

Resumé 

Baggrund: 

Videnskabsminister Helge Sander har efter et forhandlingsforløb sammen med 

Folketingets it-ordførere lagt en køreplan for den fremtidige anvendelse af åbne 

standarder. 

I forhold til standarder for dokumentudveksling af tekstebehandlingsdokumenter 

angiver køreplanen, at de to standarder Open Document Format (ODF) og ECMA 

Office Open XML (OOXML) i første omgang gøres obligatoriske i en 

prøveperiode startende 1. januar 2008. 

I prøveperioden skal offentlige myndigheder kunne modtage begge standarder, 

både ODF og EOOXML, og nyindkøb skal kunne håndtere mindst én af de to 

standarder. Prøveperioden skal evalueres i første halvår 2009 af en tredjepart med 

henblik på en ny vurdering i Folketinget. 

Idet begge standarder kun i begrænset omfang anvendes i det offentlige i dag, har 

IT- og Telestyrelsen i 2007 gennemført et studie med pilotforsøg med henblik på 

at indhente fornøden yderligere erfaring med disse standarder. 

Studiet har inddraget nyere internationale erfaringer og tidligere nationale forsøg. 

og der har været gennemført 4 pilotforsøg. 

Studiet er gennemført i dialog med branchen og andre interesserede og i et nært 

samarbejde med OIO Datastandardiserings- og IT-Arkitekturkomitéerne. 

Formålet har været at undersøge, hvordan formaterne ODF og OOXML bedst kan 

implementeres i den offentlige sektor. 

Studiets leverancer er anbefalinger og vejledninger til myndighederne til, 

hvordan de i praksis implementerer ODF og/eller OOXML. 

Projektet har været præsenteret og drøftet på tidligere ITA-kommittémøder, 

senest d. 11. oktober 2007. 



Sagsbehandler 

Jeannette Nielsen 

Telefon 3337 9132 

Telefax 3337 9299 

E-post jpn@itst.dk

Siden sidst: 

Alle væsentlige leverancer er nu publiceret. Opmærksomheden henledes særligt 

på novemberpublikation af: 

Vejledning v1.0 

Ajourført converterkortlægning 

test-selv pakke til myndighedernes brug 

nøgleleverandøreres selvevaluering mht. deres parathed ift. ODF og 

OOXML 

og IT- og Telestyrelsens anbefalinger på grundlag af pilotforsøg og 

laboratorietest. Dette notat opsummerer de væsentligste 

vejledningsrelevante konklusioner fra pilotforsøg og laboratorietest. 

Alle disse publikationer og andre findes på http://dokumentformater.oio.dk/ 

Resultaterne af arbejdet i projektet og de vejledningsmæssige implikationer 

er præsenteret på vejledningskonferencen i hhv. Århus (3.12) og i København 

(10.12). 


Projektet er nu i sin afsluttende fase. Alle pilotforsøg samt laboratorietesten er 

afsluttet. Parathedsvurderingen hos leverandører er ligeså afsluttet, men der 

publiceres stadig nye selvevalueringer efterhånden som leverandørerne sender 

dem ind. 

Du kan se resultater og leverancer på pilotprojektets hjemmeside, 

http://dokumentformater.oio.dk. Her kan du også finde en praktisk vejledning til 

myndighederne udarbejdet på baggrund af studier, pilotforsøg og laboratorietest. 

I 2008 vil IT- og Telestyrelsen følge udviklingen på converter- og interoperabilitetsværktøjerne 

og vil senest medio 2008 publicere en ajourført 

converterkortlægning. 

Indstilling 

Det indstilles, at komitéen: 

1) modtager en statusorientering over leverancer, pilotforsøg, 

vidensindsamling, laboratorietest samt en orientering om 

vejledningsindsatsen 

2) drøfter værdien af IT- og Telestyrelsens vejledningsindsats ift. de åbne 

dokumentformater 

3) orienterer om egen parathed, og drøfter erfaringer 


Side 2

Cover 


Drøftelse 


Pkt. 9. Projekt Fællesoffentlige it-arkitekturkrav 

Sagstype: Drøftelse 

Resumé 

Komitéen har tidligere drøftet Projekt fællesoffentlige It-arkitekturkrav (initiativ 32 

i digitaliseringsstrategien). Projektet forventes drøftet i STS i december og 

opstartet i januar 2008. 

Projektet ledes og gennemføres af IT arkitekturkontoret i IT- & Telestyrelsen. 

KIU vil fungere som styregruppe og den nye OIO-Komité forventes at spille en 

central rolle i gennemførelsen af projektet, herunder fastlæggelse af koncept og 

konkrete anbefalinger til den fremtidige portefølje af krav samt ramme for 

porteføljestyring og måling af fremdrift. 


ITST har siden sidste møde bl.a. drøftet initiativet med en række interessenter og 

arbejdet med at tydeliggøre projektets koncept og fremgangsmåde. 

På mødet vil der blive givet et mundtligt oplæg med henblik på en faglig 

drøftelse. 

Indstilling 

Det indstilles, at komitéen drøfter sagen. 



Sagsbehandler 

Michael Bang Kjeldgaard 


Telefax 3337 9299 

E-post mbk@itst.dk

OIO-it-arkitekturkomitémøde, 13. december 2007 Pkt. 1. Dagsorden ...

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?