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)