Status: UTKAST
Datum: 20 Jan 2026 
Målgrupp: Taktiskt utskott och "Tisdagsmöte"

Varför denna MVP – behov och nyttor

Att etablera en nationell federationsinfrastruktur för identitet och tillit mellan system är ett komplext och långsiktigt åtagande. Det kräver gemensamma tekniska standarder, samordnade anslutningsprocesser, tydlig ansvarsfördelning och tillit mellan ett stort antal aktörer med olika förutsättningar.

I dag löses delar av detta behov genom olika punktlösningar. Exempelvis används certifikatutfärdande och bilaterala anslutningar för att skapa tillit mellan system och organisationer. Dessa lösningar har vuxit fram över tid och fungerar i praktiken, men de är ofta sektorsbundna, beroende av historiska val och saknar en gemensam, förvaltningsgemensam modell för hur tillit etableras och återanvänds i bredare samverkan.

Det saknas därmed i dag en gemensam, nationell lösning för hur offentliga aktörer och deras leverantörer kan etablera verifierbar och återanvändbar tillit mellan system på ett likvärdigt sätt, oberoende av sektor, teknisk leverantör eller anslutningsväg.

MVP 2026 adresserar inte hela detta problem, men etablerar ett första, nödvändigt fundament. Genom att fokusera på systemidentitet, organisationstillhörighet och gemensam anslutning skapas förutsättningar för att:

• minska beroendet av speciallösningar, manuella överenskommelser och bilaterala certifikatutbyten,

• etablera en gemensam och förvaltningsbar modell för tillit mellan system,

• möjliggöra stegvis utveckling mot mer avancerade scenarier utan att behöva göra om grunden.

MVP:n ska därmed inte ses som en ersättning av befintliga lösningar i detta skede, utan som ett första steg mot en gemensam och långsiktigt hållbar infrastruktur som kan bära vidare utveckling.

1. Syfte och strategisk inriktning

Detta dokument fastställer omfattning och inriktning för MVP 2026 avseende den nationella federationsinfrastrukturen för maskin-till-maskin-kommunikation.

MVP-leveransen består av två sammanhängande delar:

1. etablering av en gemensam teknisk federationsinfrastruktur med definierade roller, och

2. fastställande av en gemensam "ENA-anslutningspolicy" som reglerar hur organisationer och system ansluts till infrastrukturen.

Tillsammans utgör dessa delar den miniminivå som krävs för att tillit ska kunna etableras mellan federationsmedlemmar, oberoende av vilken anslutningsoperatör som använts.

1.1 Huvudsyfte

Syftet med MVP 2026 är att etablera ett gemensamt, återanvändbart basutbud för federativ tillit mellan system.

MVP:n fokuserar uteslutande på:

• verifierbar systemidentitet, och

• verifierad koppling mellan system och anslutande organisation.

Infrastrukturen tillhandahåller därmed ett gemensamt tekniskt och organisatoriskt underlag för tillit. Fokus ligger inte på inte färdiga behörighets eller åtkomstbeslut.

MVP:n säkerställer endast att rätt system från rätt anslutande organisation kan identifieras och kommunicera med verifierbar teknisk tillit.

2. Bakgrund och behov

Tidigare ansatser riskerade att bli oproportionerligt komplexa genom att blanda ihop:

• infrastrukturell tillit (identifiering och verifiering), och

• verksamhetsmässig tillit (behörighet, ändamål och rätt till data).

Genom att avgränsa MVP:n till ett basutbud adresseras följande centrala behov:

• Skalbarhet: Infrastrukturens första införande ska inte kräva att bakomliggande samverkansparter representeras som egna federationsnoder.

• Tydlig ansvarsfördelning: Infrastrukturens ansvar skiljs från den förlitande partens beslut om dataåtkomst och utlämnandet av informationen.

3. MVP:ns omfattning (scope)

3.1 Vad ingår

3.1.1 Systemidentitet och organisationstillhörighet

MVP 2026 etablerar en verifierbar identitet för tekniska komponenter och en entydig koppling till ansvarig organisation.

Varje system identifieras med egenutgivna kryptografiska nycklar eller certifikat. Systemet är kopplat till en juridisk person som har ingått avtal om anslutning till federationsinfrastrukturen och som ansvarar för systemets agerande.

Kopplingen mellan system och organisation är kryptografiskt säkrad och verifierbar via federationsinfrastrukturen.

I MVP 2026 gäller att endast den organisation som anslutit en teknisk komponent är den som kan identifieras, och som åtkomstbeslut kan baserat på.

3.1.2 Tekniska komponenter och roller

MVP 2026 baseras på etablerade mönster inom OIDC Federation och OAuth 2.0. Följande roller ska kunna förekomma i produktionslik miljö:

• Federation Entity: noder för uppbyggnad av tillitskedjor,

• Federationsoperatör (Trust Anchor): funktion som validerar och signerar metadata enligt gemensam anslutningspolicy,

• Client: anropande system,

• Authorization Server (AS): utfärdar åtkomstintyg för system (kan vara self-hosted inom MVP),

• Resource Server (RS): mottagande API eller tjänst.

3.1.3 Metadata och tillitsetablering

MVP 2026 etablerar:

• automatiserat uppslag och validering av metadata via federationsinfrastrukturen,

• verifiering av kryptografisk giltighet och status.

Tillit uttrycks binärt i detta skede:

• giltig och signerad metadata innebär att anslutning skett enligt gemensam "ENA-anslutningspolicy",

• ogiltig eller frånvarande metadata innebär att tillit saknas.

3.2 Vad som uttryckligen inte ingår

För att säkerställa tydlighet och leveransbarhet omfattar MVP 2026 inte:

• delegering eller ombudskap,

• stöd för att överföra information om å vilken parts räkning anropet utförs (om annan part än den som anslutit den tekniska komponenten),

• användning av trust marks för att uttrycka egenskaper hos komponent eller tillhörande organisation,

• personidentiteter, yrkesroller eller personbaserade attribut,

• materiell prövning, ändamålsbedömning eller verksamhetslogik,

Dessa frågor hanteras i senare utvecklingssteg.

4. Gemensam "ENA-anslutningspolicy"

4.1 Roll och funktion

Den gemensamma "ENA-anslutningspolicyn" är en förutsättning för federativ tillit inom MVP 2026.

Policyn beskriver de minimikrav och kontroller som ska tillämpas vid anslutning av organisationer och system, oavsett vilken anslutningsoperatör som används.

Syftet är att säkerställa att federationsmedlem A kan ha tillit till federationsmedlem B:s systemidentitet, även om anslutning skett via olika operatörer.

4.2 Vad anslutningspolicyn reglerar

"ENA-anslutningspolicyn" reglerar minst:

• identifiering och verifiering av juridisk person,

• fastställande av behörig företrädare,

• koppling mellan organisation och teknisk komponent,

• minimikrav på nyckelhantering och livscykel,

• anslutningsoperatörens kontroller före publicering av metadata,

• återkallelse och hantering vid incident.

4.3 Vad anslutningspolicyn inte reglerar

"ENA-anslutningspolicyn" reglerar inte:

• verksamhetsbehörigheter eller åtkomstbeslut,

• sektorsspecifika krav eller regelverk,

• ändamåls- eller sekretessprövningar,

• tekniska protokolldetaljer.

Policyn implementeras genom anslutningsoperatörernas processer, inte genom metadata eller protokollutökningar.

5. Centrala begrepp i MVP 2026

6. Mätbara mål och acceptanskriterier

MVP 2026 anses uppfylld när samtliga följande kriterier är uppfyllda:

• Produktionssatt kedja:

  • minst två oberoende federationsmedlemmar har system i drift (Client och Resource Server) som kan kommunicera via infrastrukturen.

• Automatiserad tillit:

  • ingen manuell utväxling av nycklar eller certifikat mellan parter,

  • tillit etableras genom federativ metadata och gemensam anslutningspolicy.

• Anslutningsprocess:

  • dokumenterad, testad och upprepad process för hur en organisation tecknar avtal och ansluter sin första komponent enligt "ENA-anslutningspolicyn".

• Finansiering:

  • framtagen och förankrad pris- och finansieringsmodell för drift och förvaltning av basutbudet.

7. Förvaltning, utveckling och livscykel

MVP 2026 utgör ett första införandesteg i etableringen av en långsiktigt förvaltningsbar federationsinfrastruktur inom Ena. MVP:n ska inte betraktas som en engångsleverans, utan som starten på en successiv och kontrollerad utveckling.

Förvaltning och vidareutveckling av federationsinfrastrukturen ska ske stegvis och med bibehållen tillit för redan anslutna parter. Nya funktioner, roller eller krav ska införas på ett sätt som inte bryter befintliga anslutningar eller förändrar innebörden av redan etablerad tillit utan föregående beslut och kommunikation.

Den gemensamma "ENA-anslutningspolicyn" utgör ett centralt verktyg för att säkerställa stabilitet över tid. Genom att hålla anslutningskrav och kontroller konsekventa mellan operatörer skapas förutsättningar för att infrastrukturen kan utvecklas utan fragmentering eller parallella tolkningar.

Utökningar av infrastrukturen – exempelvis stöd för komplexa organisationsrelationer, delegering eller hantering av system som agerar för flera organisationer – ska ske genom tydligt avgränsade steg. Varje sådant steg ska bygga vidare på tidigare etablerade principer och anslutningar, inte ersätta dem.

Hur förvaltning, beslutsprocesser och ansvarsfördelning organiseras i detalj hanteras utanför detta MVP-dokument och fastställs successivt i takt med att infrastrukturen mognar. MVP 2026 tar därmed inte ställning till slutlig förvaltningsmodell, utan säkerställer att den tekniska och organisatoriska grunden är möjlig att förvalta och vidareutveckla över tid.

8. Stegvis färdplan

Utvecklingen av federationsinfrastrukturen sker stegvis genom utökning av vilken typ av tillit som kan etableras och förmedlas. Varje steg bygger vidare på tidigare etablerade principer och anslutningar.

• Steg 1 – Systemidentitet och ansvarig organisation (MVP 2026)
  • Etablering av tillit till tekniska system och deras anslutande organisationer. Infrastrukturen möjliggör verifiering av att ett visst system agerar för en identifierad juridisk person enligt gemensam "ENA-anslutningspolicy".
• Steg 2 – Organisationsegenskaper och delegering mellan organisationer
  • Utökning av tillitsmodellen till att omfatta egenskaper kopplade till organisationer och tekniska komponenter, samt stöd för delegering där ett system kan agera för en annan organisation. Detta möjliggör mer komplexa organisatoriska relationer, exempelvis leverantör–huvudman-scenarier, utan att introducera användaridentiteter.
• Steg 3 – Användaridentitet och organisationstillhörighet
  • Införande av stöd för att förmedla och verifiera användaridentitet samt användarens organisationstillhörighet. Producenter och mottagande parter kan i detta steg lita på vem användaren är och vilken organisation användaren representerar, men utan att behörighetsbedömningar förmedlas genom infrastrukturen.
• Steg 4 – Användarbehörighet och förmedlad auktorisationsgrund
  • Vidareutveckling av infrastrukturen för att möjliggöra förmedling av behörighetsgrundande information om användare, såsom roller eller funktioner. Användarorganisationen kan intyga att en användare har en viss behörighet (exempelvis är lärare), medan den mottagande parten fortsatt fattar det slutliga beslutet om åtkomst.

9. Risker i MVP

Förväntansglidning - att aktörer förväntar sig att MVP:n löser juridiska frågor kring datadelning.

Hantering:

• tydlig kommunikation om att infrastrukturen endast verifierar avsändare och transport,

• den förlitande parten (Resource Server) ansvarar fortsatt för beslut om dataåtkomst och utlämning.

Tidigare utkast – Tidigare utkast – Tidigare utkast

Ingress – varför denna MVP?

Att bygga en nationell federationsinfrastruktur för identitet och behörighet som ska skapa förutsättningar för ett mer effektivt informationsutbyte inom och med det offentliga är oerhört komplicerat och komplext. Det kräver gemensamma standarder, tillit mellan parter, samordnade avtal och teknik som fungerar lika för alla. Helheten kommer att ta tid att realisera.

För att kunna ta oss dit behöver vi börja med ett första, konkret fundament. MVP:n är därför avgränsad till något mycket grundläggande: att en digital komponent ska kunna identifiera sig, visa vilken organisation den tillhör eller representerar och vilka avtal som gäller – och att en resursserver ska kunna fatta ett automatiserat åtkomstbeslut baserat på just det.

Det här är långt ifrån hela ambitionen med Samordnad identitet och behörighet – men det är en del som gör det möjligt att börja. MVP:n reducerar speciallösningar och manuella moment, och den ger oss den praktiska erfarenhet som behövs för att förstå vad som fungerar, vad som behöver justeras och vad som kräver ytterligare utveckling. Det är en startpunkt som bygger förutsättningar för både lärande och vidare expansion.

Nya eller oprövade förmågor vi behöver testa och lära oss i MVP:n

MVP:n ska ge oss praktisk förståelse för de förmågor som är nödvändiga för en federationsinfrastruktur men som ännu inte är realiserade i vårt uppdrag. Genom MVP:n behöver vi därför både bygga och pröva följande:

• Federerad registrering av komponenter och deras metadata, via olika anslutningsoperatörer men med en sammanhållen tillitskedja. Här behöver vi lära oss hur distribuerad metadatahantering fungerar organisatoriskt, tekniskt och i förvaltning.

• Standardiserad representation av organisationstillhörighet och avtalstillstånd, genom egenskapsintyg som realiseras som Trustmarks i metadata. Vi behöver pröva hur denna modell påverkar avtal, anslutning, ansvar och åtkomstbeslut.

• Automatiserade åtkomstbeslut baserade på åtkomstintyg och federationsmetadata, utan whitelistor, specialfall eller certifikatsberoende. Vi behöver förstå hur tekniken, policyn och metadata samspelar i verkliga M2M-flöden.

• Grundläggande förvaltningsprocesser för federation: anslutning, incidenthantering och ändringshantering. MVP:n ska hjälpa oss att se vilka minimiprocesser som krävs för att infrastrukturen ska vara stabil och skalbar.

• Tillitskedjor enligt OpenID Federation, där tillit byggs genom signerad metadata och verifierbara kedjor. Detta är nytt i vårt sammanhang och kräver lärande om hur det fungerar i drift och hur det påverkar anslutning.

• Representation av olika organisatoriska kopplingar, både när en organisation använder sina egna komponenter och när en organisation använder en annan organisations komponent som agerar för dess räkning. Här behöver vi förstå hur relationerna uttrycks i metadata och hur de påverkar åtkomst och avtal.

Syfte

MVP:n etablerar en minimal, produktionssatt federationsinfrastruktur för M2M som möjliggör:

• säker identifiering av digitala komponenter,

• verifierbar organisationskoppling baserad på etablerade identifierare (t.ex. organisationsnummer),

• maskinellt kontrollerbara avtalstillstånd via egenskapsintyg,

• automatiserade åtkomstbeslut i M2M-flöden baserat på komponentidentitet (via åtkomstintyg enligt OAuth 2.0), organisation, avtalstillstånd och lokalt definierad policy.

• en anslutningsmodell som är skalbar, förutsägbar och återanvändbar.

• tydlig pris- och finansieringsmodell

Mätbara mål

Minst följande ska vara uppnått:

• Minst en federationsmedlems komponent kan anropa en resursserver via federationsinfrastrukturen (t.ex. en region eller en leverantör för en region) 

• Minst en resursserver kan fatta åtkomstbeslut utan manuella specialfall, baserat på:

  • åtkomstintyg enligt OAuth 2.0 som identifierar den anropande komponenten,

  • organisationskoppling

  • egenskapsintyg (via Trustmarks i federationsmetadata),

  • samt lokalt konfigurerad policy.

• Alla federationskomponenter (hos operatörer och federationsmedlemmar) finns i produktionsdrift senast 1 juli 2026.

• Anslutning sker genom en standardiserad process med metadataregistrering och validering.

• Federationsinfrastrukturen ska kunna driftsättas och fungera fullt ut utan beroenden till externa kommersiella certifikatutfärdare. All tillit ska etableras via OpenID Federation-baserade tillitskedjor och signerad federationsmetadata.

• Förvaltningsprocesser för anslutning, incidenthantering och ändringshantering har testats i skarp drift.

• Pris- och finansieringsmodell framtagen

Scope

Funktionell omfattning

MVP:n ska stödja att:

• digitala komponenter kan identifieras och verifieras,

• organisationskoppling uttrycks genom etablerade identifierare,

• både organisationens egna komponenter och komponenter som drivs av annan organisation kan representeras korrekt,

• avtalstillstånd uttrycks genom egenskapsintyg och tekniskt realiseras via Trustmarks,

• resursservrar kan kombinera åtkomstintyg (runtime) och egenskapsintyg (metadata) för att fatta åtkomstbeslut,

• anslutningsprocessen kan genomföras utan specialanpassningar.

Förtydligande om tokens och metadata:

• Åtkomsthantering enligt profil för åtkomst till skyddade resurser:

  • https://ena-infrastructure.github.io/specifications/ena-oauth2-profile.html

• Organisationskoppling och egenskapsintyg hämtas via federationsmetadata och ska inte ingå i åtkomstintyg.

Begreppsförtydligande: egenskapsintyg och Trustmarks

• Egenskapsintyg avser verksamhetsbegreppet: en egenskap om en aktör, exempelvis avtalstillstånd.

• I MVP:n realiseras egenskapsintyg tekniskt som Trustmarks enligt OpenID Federation, publicerade i federationsmetadata.

Tekniska komponenter

Alla komponenter ska vara i produktion:

• Tillitsankartjänst (Trust Anchor enligt OpenID Federation)
• Resolver / uppslagstjänst Resolver enligt OpenID Federation)
• Anslutningstjänst (Intermediary entity som publicerar metadata)
  • registreringsgränssnitt
  • admingränssnitt 
  • metadata-publicering enligt MVP-profilen
• Åtkomstintygstjänst (OAuth 2.0)

  • Åtkomsthantering enligt profil för åtkomst till skyddade resurser:

    • https://ena-infrastructure.github.io/specifications/ena-oauth2-profile.html

(Vid behov av användarrelaterade identitetsintyg i andra flöden kan OpenID Connect användas, men det ligger utanför denna M2M-MVP.)

• Egenskapsintygstjänst (Issuer av Trustmarks)
  • utfärdar egenskapsintyg som anger avtalstillstånd för ett givet avtal eller en avtalsprofil,
  • publicerar dessa som Trustmarks i federationsmetadata,
  • möjliggör för resursservrar att verifiera egenskapsintyg via federationsinfrastrukturen.
• Resursserver
  • Tar åtkomstbeslut baserat på åtkomstintyg och egenskapsintyg
• Open source-komponenter
  • driftkomponenter för tillitsankare, anslutning, lint-verktyg, metadatahantering m.m.

"Federationsregelverk"

Fastställs:

• rollbeskrivning för federationsoperatör,

• rollbeskrivning för anslutningsoperatör,

• rollbeskrivning för federationsområdesansvarig (arbetsantagande),

• anslutningsavtal och tekniska profiler

• metadata-krav (inkl. organisationskoppling)

• policyer för federationsoperatörs- och områdesnivå.

• förvaltningsprocesser
  • onboarding
  • incident
  • change/release av "federationsregelverk"

Egenskapsintyg (avtalstillstånd)

• Representeras som binära egenskapsintyg: giltig/ogiltig.

• Realiseras som Trustmarks i metadata.

• Ska klara två typer av organisationsrelationer:

  1. Organisation A använder sin egen komponent.

  2. Organisation A använder Organisation B:s komponent.

Acceptanskriterier

Identitet & organisationskoppling

• Resursserver kan verifiera åtkomstintyg mha federationsmetadata.

• Organisationskoppling är tekniskt verifierbar genom identifierare som hämtas via federationsmetadata.

Kombination av intyg

Resursserver kan fatta åtkomstbeslut genom att kombinera:

• åtkomstintyg som identifierar komponenten (OAuth 2.0),

• metadata och egenskapsintyg (Trustmarks), verifierade via resolver.

Resursservern kan detektera att ett egenskapsintyg är ogiltigt eller utgånget.

Infrastruktur & process

• Alla komponenter i 3.2 finns i produktion.

• Metadata kan publiceras, valideras.

• Anslutning kan genomföras utan specialfall.

Governance

• Roller och ansvar är dokumenterade.

• Policyer är fastställda.

Antaganden

• Finansieringsmodell för anslutningsoperatörer är klarlagd innan driftstart.

• Federationsinfrastrukturen bygger på överenskomna profiler för specifikationerna:

  • OpenID Federation 1.0 som federationsprotokoll för egenskaps- och metadatahantering,

  • OAuth 2.0 som åtkomstprotokoll,

  • OpenID Connect som identietsprotokoll

    • kan användas i andra flöden där identitetsintyg för användare behövs, men ingår inte i kärnan av denna M2M-MVP.

Out of scope

• Personidentitet

• Finmaskiga verksamhetsbehörigheter

• Fullständig tillitsnivåmodell

• Färdig migrering från befintliga federationer (ev. endast påbörjad mappning ingår)