You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 5 Next »


Ett första utkast för att få igång samtalet


Bakgrund och kortfattad beskrivning av 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 är ett uttryck för en startpunkt som skapar förutsättningar för att lära och växa.



Driftsatt senast 1 juli 2026

1. Syfte

MVP:n etablerar en minimal, produktionssatt federationsinfrastruktur 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.

2. Mätbara mål

Minst följande ska vara uppnått:

  • Minst en region eller vårdgivare kan anropa en resursserver via federationsinfrastrukturen. OBS: det kan även vara Inera, så det viktiga är att en annan organisation kan anropa

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

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

    • 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.

3. Scope

3.1 Funktionell omfattning

MVP:n ska stödja att:

  • digitala komponenter kan identifieras och verifieras,

  • organisationskoppling uttrycks genom etablerade identifierare,

  • 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:

  • Åtkomstintyg enligt OAuth 2.0 representerar enbart komponentens identitet.

  • 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.

3.2 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)
    • admingränssnitt
    • lint/valideringsverktyg
    • metadata-publicering enligt MVP-profilen
  • Åtkomstintygstjänst (OAuth 2.0)
    • Utfärdar åtkomstintyg enligt OAuth 2.0 som representerar den anropande komponentens identitet.
    • Identifieraren i åtkomstintyget ska motsvara komponentens entity_id i federationsmetadata.

(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
  • Open source-komponenter
    • driftkomponenter för tillitsankare, anslutning, lint-verktyg, metadatahantering m.m.

3.3 "Federationsregelverk"

Fastställs:

  • rollbeskrivning för federationsoperatör,

  • rollbeskrivning för anslutningsoperatör,

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

  • anslutningsavtal, tekniska profiler och metadata-krav,

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

3.4 Egenskapsintyg (avtalstillstånd)

I MVP:n representeras avtalstillstånd som binära egenskapsintyg, d.v.s. ett givet avtal eller en avtalsprofil finns antingen som giltigt egenskapsintyg (via Trustmark) eller inte.

Egenskapsintyg ska vara kompatibla med hur befintliga federationer uttrycker medlemskap och avtalstillstånd.

Mer finmaskig avtalshantering hanteras senare.

4. Acceptanskriterier

Identitet & organisationskoppling

  • Resursserver kan verifiera åtkomstintyg enligt OAuth 2.0.

  • 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),

  • egenskapsintyg (Trustmarks) från federationsmetadata, verifierade via tillitsankare och resolver.

Resursservern kan detektera att ett egenskapsintyg är återkallat eller utgånget genom att kontrollera aktuella Trustmarks.

Infrastruktur & process

  • Alla komponenter i 3.2 finns i produktion.

  • Metadata kan publiceras, valideras och tillitskedjor byggas via resolver enligt OpenID Federation.

  • Anslutning kan genomföras utan specialfall.

Governance

  • Roller och ansvar är dokumenterade.

  • Policyer är fastställda.

5. Antaganden

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

  • Federationsinfrastrukturen bygger på specifikationer från OpenID Foundation (OIDF), främst:

    • OpenID Federation 1.0 för federationsmetadata och Trustmarks,

    • OAuth 2.0 för åtkomstprotokoll och komponentidentitet,

    • OpenID Connect 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.

6. 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)

  • No labels