Styrelse: Ingen direkte opkobling til MitID - mellemhandlere bliver et krav

Et større marked for MitID-mellemhandlere vil vokse frem, når go-live af MitID nærmer sig, vurderer Digitaliseringsstyrelsen. Der er dog en ‘nødindgang’ til den nationale digitale ID-løsning.

Webshops og andre udbydere af digitale tjenester, fx medier, der ønsker at bruge fremtidens NemID, kaldet MitID, til login af deres brugere, kan ikke koble sig direkte på ID-løsningen man skal gøre brug af en mellemhandler, kaldet en broker.

Det fremgår af en ny status fra Digitaliseringsstyrelsen om MitID, som forventes at blive lanceret i 2020.

»I fremtiden bliver det kun såkaldte brokere, der direkte kan tilsluttes MitID. Offentlige og private tjenesteudbydere skal altså kobles op på en broker, før de kan tilbyde log-in med MitID til deres brugere,« skriver styrelsen.

Det er ikke blevet sagt direkte, men styrelsen har formentlig vurderet, at EUs regler for API imod den centrale MitID ‘motor’ gør, at det bliver langhåret og papirtungt at implementere og certificere – og dermed umuligt for en lang række parter, fx webshops.

Ved at indskyde brokers som mellemlag slipper man for, at den enkelte webshop skal forholde sig direkte til dette regelinferno.

Mere sikkert med færre opkoblinger til MitID-kernen

Brokerne skal certificeres til at udvikle klientløsninger med slutbruger-autentifikation og dermed sikrer man sig altså, at de lever op til de sikkerhedsregler og løbende ændringer, som det indebærer at være koblet op på MitID:

»Brokermodellen har en række fordele for tjenesteudbyderne. Det er en langt mindre opgave at koble sig på en broker end at implementere en log-in løsning direkte. Og det er kun brokerne, der behøver forholde sig til ændringer i MitID-snitflader. Samtidig skal implementering fremover ske via certificerede brokere, så der bliver færre opkoblinger til identiteterne i MitID’s kerne,« skriver Digitaliseringsstyrelsen, der også argumenterer for sikkerhedsmæssige fordele ved modellen:

»Det bliver derfor nemmere at beskytte brugerne mod phishing,« lyder det.

Styrelsen forventer at det nye marked for brokere vil vokse frem af sig selv:

»Formentlig vil der opstå et bredere brokermarked blandt den finansielle sektor og andre private virksomheder, når go-live nærmer sig,« skriver Digitaliseringsstyrelsen i et nyhedsbrev.

Men der er dog etableret en kattelem, hvis markedet for brokere skulle svigte. Private udbydere af tjenester kan i stedet for at tilslutte sig MitID via en broker vælge NemLog-in3. Men det giver dog ikke adgang til den fulde MitID-pakke:

»For at garantere adgangen til den digitale identitetsinfrastruktur for private tjenester vil NemLog-in3 kunne anvendes af private tjenesteudbydere til begrænsede, basale funktioner som fx autentifikation og signering.«

Styrelsen opforderer de it-ansvarlige hos både offentlige og private organisationer til allerede nu at forberede sig, hvis de vil tilbyde login med MitID på deres tjeneste.

»Vi vil bestræbe os på løbende at offentliggøre al nødvendig information om de nye systemer. Vi er opmærksomme på, at opgaver af denne type skal planlægges for at muliggøre planlægning af ressourcer og økonomi. Vi kommer snart med et nyhedsbrev og en implementeringssektion om de forestående ændringer her på digst.dk, og vi vil også indkalde løbende til informationsmøder for tjenesteudbydere – første gang i efteråret 2018,« siger kontorchef i Digitaliseringsstyrelsen, Charlotte Jacoby, ifølge meddelelsen.

Læs også: MitID-udbud på gaden: Det handler om brokere, brokere, brokere

Tidligere har det været fremme, at MitID forventes at omfatte ca. 6-9 mio. aktive registrerede slutbrugere eller identiteter, og cirka 1 milliard anmodninger om autentifikation per år.

Ændringer for offentlige tjenesteudbydere

Den fremtidige version af NemLog-in vil fortsat være baseret på de nuværende og kendte OIO SAML-snitflader. Der kommer dog nogle mindre ændringer i attributterne i snitfladerne, som de offentlige tjenesteudbydere skal forholde sig til.

Allerede nu findes en testportal for den eksisterende NemLog-in-løsning, hvor både offentlige og private tjenesteudbydere samt it-leverandører kan teste op imod NemLog-ins kommende snitflader og begynde at planlægge den forestående udviklingsopgave.

Læs også: Udbud køres i stilling: Det nye NemID – kaldet MitID – har et budget på 900 millioner kroner

Testportalen vil løbende blive udbygget, især med vejledninger til private tjenesteudbydere.

Der er endnu ikke indgået endelige kontrakter om MitID, men det forventes at ske ved årets udgang, se faktaboks.

Tips og korrekturforslag til denne historie sendes til tip@version2.dk
Kommentarer (25)
sortSortér kommentarer
  • Ældste først
  • Nyeste først
  • Bedste først
Jan Gundtofte-Bruun

Så hvor vi indtil nu kunne være (nogenlunde) sikre på, at hvis appletten loades fra en kendt url så var den god nok -- bliver det fremover sådan at vi må stole på en underskov af mellemhandlere?

Jeg forstår ikke hvordan dette adskiller sig fra en glorificeret "officiel" man-in-the-middle, og hvordan det er en fordel for lille mig som privatperson. Bevares, der er sikkert penge at tjene som mellemhandler, så måske er det bare mig der er i den gale branche...?

Markus Hornum-Stenz

Hvad forstår du ved "en rigtig PKI infrastruktur"?
Du kommer vel ikke udenom at såvel afsender som modtager skal have nøgler som udløber indimellem og skal fornys?
Og det kræver løbende en aktiv indsats fra begge parter - medmindre du bare vil gøre det automatisk (læs: obligatorisk)?

Det grundlæggende problem er vist, at du som afsender ikke uden videre kan gå ud fra, at den du ønsker at kommunikere med (ind og udland), har sine nøgler i orden?

Niels Flensted-Jensen

Disclaimer: Jeg er medstifter af Criipto som under de rette omstændigheder er en potentiel mellemhandler.

Jeg håber at det i udbuddet af MitID er præcist defineret at leverandøreren af MitID ikke må være mellemhandler (banestyrelsen kører jo heller ikke tog) og at det ikke er op til MitID-leverandøren at vælge mellemhandlere.

Jeg vil anbefale at man opstiller strikse - og reele - sikkerhedskrav til mellemhandlerne, og i højere grad lader de økonomiske forhold være op til slutkundernes vurdering. Dermed opnår man måske en større spredning af mellemhandlerne - og altså væk fra "Du skal have 4 års monsteromsætning fra triste, grå fagsystemer, så vi slipper for utidig innovation". Væk fra udelukkende tunge mellemhandlere, som kræver underlige "security-by-obstruction" firewall-åbninger - der iøvrigt kun kan udføres en gang om ugen - til de adrætte, der kan få dig op at køre med MitID på 10 min. De sidste vil måske primært være rettet mod de mindre virksomheder, der ellers slet ikke ville overveje MitID. Men nu kan de få MitID mindst lige så sikkert som fra de store mellemhandlere, men både tekniske og økonomisk i et langt mere medgørligt setup.

Hvis den dag kommer, ja, så er vi også med på vognen :)

Jesper Nielsen

Så hvor vi indtil nu kunne være (nogenlunde) sikre på, at hvis appletten loades fra en kendt url så var den god nok -- bliver det fremover sådan at vi må stole på en underskov af mellemhandlere?

Som det er i dag, skal du jo indtaste brugernavn, adgangskode og engangskode på tilfældige hjemmesider. Skal du logge ind på hos Sygeforsikringen Danmark, sker indtastning på sygeforsikring.dk. Skal du logge ind hos et spillesite, sker det på deres domæne. Og de skal alle individuelt sørge for, at sikkerheden på deres websites er høj, så hacker ikke kan komme til at indsætte scripts, der stjæler oplysningerne.

Jeg vil klart foretrække at skulle indtaste disse oplysninger på et begrænset antal kendte login-portaler (NemLog-in og de nye brokere) i stedet — portaler, der er ejet og driftet af firmaer med autentificering som en central del af deres forretning.

Henrik Biering Blogger

Ja sådan ser det ud, men reelt er der IFRAME elementer på siden der hentes direkte fra danid.dk -- men sådan bliver det måske ikke fremover?


Det kan du som IT-kyndig måske gennemskue, men det kan 99% af befolkningen ikke. Derfor er den generelle trustmodel for en browser at man kun kan stole på de oplysninger, der står i og omkring adresseliniefeltet. De fleste kommende brokere vil formodentlig integrere funktionaliteten fra NemID og Nemlog-in, og altså tilbyde SSO som det pt. kendes fra login til offentlige sites.

Povl Hansen

“Jeg håber at det i udbuddet af MitID er præcist defineret at leverandøreren af MitID ikke må være mellemhandler”

Jeg håber at det bliver et krav at de er mellemhandler, iforvejen er det utroligt usikkert at man kan logge ind alle mulige steder, hvis der så kommer et tilfældigt mellemled, så har folk da ingen mulighed for at vide noget som helst

Henning Wangerin

PGP virker jo netop med at man har en offentlig og en privat nøgle

Så man kan sende den offentlige nøgle over e-mail

Når der sendes en signeret mail, kan du til enhver tid checke om der er foretaget ændringer, men hvis ikke du kan verificere certifikatet kan du ikke validere HVEM der har sendt beskeden.

Med PGP kan certifitatet valideres via deres servere.

Med CA-cert kan certifikatet valideres via deres server.

Med MitID kan certifikatet vel valideres via deres server - ellers er det jo intet værd.

/Henning

Henning Wangerin

Jeg håber at det bliver et krav at de er mellemhandler, iforvejen er det utroligt usikkert at man kan logge ind alle mulige steder, hvis der så kommer et tilfældigt mellemled, så har folk da ingen mulighed for at vide noget som helst

Der er kun to muligheder.

Enten får vi den monolitiske løsning vi har nu, hvor der kun er en løsning, eller vi får en distribueret løsning på den ene eller anden måde, hvor der er masser af muligheder.

Men det kommer selvfølgelig an på hvordan setupet bliver skruet sammen, men jeg har svært ved at se hvordan det skal lykkes med en kombination.

/Henning

Henning Wangerin

Ligegyldigt hvor gerne du vil bruge MitID til at sende krypteret e-mail, så tror jeg stadig ikke at det bliver muligt

I princippet er der ingen forskel på om jeg vil kryptere og/eller signere mails eller om jeg vil signere beskeder/dokumenter via en hjemme side.

For at jeg (eller in computer) kan sende data til en anden krypteret til en anden skal jeg kende modtagerens verificerede offentlige nøgle. Det sker oftest via et certifikat, hvor mellemmanden (CA-en ) har verificeret hvem der ejer en given nøgle.

Når jeg signerer en mail eller en anden file, behøver modtager ikke have mit certifikat for at se om data er blevet ændrede, men for at checke om data er signeret af MIG har modtageren igen brug for at checke at den brugte nøgle rent faktisk tilhører mig. Det sker igen typisk ved at der er en CA som har verificeret mig, og står inde for at det er min nøgle.

Så ligegyldigt hvad, skal nøglen være tilgængelig for mig og min computer.

/Henning

Bjarne Nielsen

Så ligegyldigt hvad, skal nøglen være tilgængelig for mig og min computer.

"Tilgængelig" i videste forstand. Kryptografien kan godt ske et helt andet sted i verden, og derfor behøver den nøgle, som du bruger, ikke være umiddelbart tilgængelig for dig eller din computer - den kan godt befinde sig et helt andet sted.

Hele ideen er at certifikatet ligger hos en CA

Ikke nødvendigvis. CA underskriver offentlige nøgler ved at udstede et certifikat. Derefter behøver CA ikke længere den offentlige nøgle, og det er da heller ikke alle CA'ere, som beholder certifikatet.

Jeg ved faktisk ikke, om en CA er forpligtet til at føre tilbagekaldelseslister (udover, hvad den måtte love i certifikatpolitikken), men selv til det, behøver CA faktisk ikke gemme nogen informationer fra certifikatet.

At det så godt kan være "hele ideen" at certifikatet ligger hos CA af andre årsager, og at det derfor ofte er tilfældet, er så en anden snak.

Michael Bisbjerg

Finder det underligt her i foraet at diskussionen gik primært på om man kan få en key til S/MIME el.lign.. Det plejer at dreje i retningen af F/OSS løsninger :)

Men det kunne da være belejligt hvis der var garanti for at man som alm. website-ejer kan benytte sig af en SSO løsning for danskerne, som ikke kræver at man betaler 1-3 kr. pr. login - men måske bare "kan bruges".

Log ind eller Opret konto for at kommentere