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 röra oss framåt och skapa en första konkret fundamenta har vi därför avgränsat en första, minimal men värdeskapande MVP. Den fokuserar på något mycket grundläggande: att en digital komponent ska kunna identifiera sig, visa vilken organisation den tillhör och vilka avtal som gäller – och att en resursserver ska kunna fatta ett automatiserat åtkomstbeslut baserat på just det.

Denna MVP löser inte hela federationen. Men den visar att kärnan fungerar och att den kan användas i verkliga M2M-flöden. Den skapar omedelbart värde genom att minska speciallösningar och manuella kontroller, samtidigt som den ger oss praktisk erfarenhet som är nödvändig för att bygga den fulla, mer avancerade federationsinfrastrukturen framöver.

MVP:n är ett uttryck för en startpunkt som skapar förutsättningar för att lära och växa.

Vad MVP:n ska hjälpa oss att lära oss

MVP:n är ett kontrollerat sätt att testa om följande förmågor fungerar i verkligheten:

• Federerad registrering av komponenter och deras metadata hos anslutningsoperatörer.

• Att åtkomstbeslut kan fattas automatiskt genom att kombinera:

  • åtkomstintyg (OAuth/OATS, runtime),

  • egenskapsintyg (Trustmarks i metadata),

  • organisationskoppling,

  • lokalt definierad policy.

• Att tillit till komponenter (nycklar, adresser, avtal) kan etableras och förvaltas via OpenID Federation.

• Att anslutningsprocessen, kraven och avtal är så pass tydliga att fler aktörer än piloterna kan ansluta utan specialhantering.

• Att distribuerad registrering och aggregering av metadata fungerar i praktiken och är förvaltningsbart.

• Hur vi representerar två typer av organisatorisk koppling:

  • Organisation A använder sin egen komponent.

  • Organisation A använder Organisation B:s komponent som agerar för A.

Nya förmågor som testas i MVP:n

MVP:n introducerar och testar följande förmågor – flera av dem är nya eller oprövade inom ramen för detta uppdrag, och kräver därför att vi testar och lär oss hur de ska omsättas praktiken:

• Federerad registrering av komponenter och deras metadata, där komponenter kan registreras via olika anslutningsoperatörer men fortfarande ingå i samma federationsinfrastruktur. Genom att realisera förmågan krävs att vi testar hur distribuerad metadatahantering faktiskt fungerar organisatoriskt, tekniskt och förvaltningsmässigt.

• Ett standardiserat sätt att uttrycka organisationstillhörighet och avtalstillstånd, genom egenskapsintyg som realiseras som Trustmarks i federationsmetadata. Det är en modell som är relativt ny och som behöver prövas för att förstå hur den påverkar ansvarsfördelning, avtal, åtkomstbeslut och tillit.

• Automatiserade åtkomstbeslut baserade på gemensam metadata, i stället för lokala whitelistor, manuella undantag eller certifikatsberoenden. Det innebär att både teknik och processer för att fatta beslut baserat på kombinationen av åtkomstintyg och metadata behöver utvärderas och valideras i verkliga flöden.

• Grundläggande förvaltningsprocesser, såsom anslutning, incidenthantering och ändringshantering, krävs för att federationen ska kunna skalas och fungera stabilt över tid. Detta område behöver uppdraget börja realisera där MVP:n tar sikte på de mest grundläggande processer som krävs och ger möjlighet för ökad förståelse för hur de bör utformas.

• Tillitskedjor enligt OpenID Federation, där tillit byggs genom signerad metadata och verifierbara kedjor, snarare än genom punktvisa certifikat och manuella nyckelutbyten. Denna tillitsmodell är ny där MVP:n syftar till att öka förståelsen för hur den fungerar i praktiken, vilka beroenden den skapar och hur den påverkar drift och anslutning.

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.

Mätbara mål

Minst följande ska vara uppnått:

• Minst en federationsmedlem 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.

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 som 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)