På sidan:

Varför stegvis produktutveckling?

  • Att etablera en ny identitet- och behörighetsinfrastruktur är komplext och innehållet många vägval 
  • En stegvis utveckling med ett utforskande arbetssätt, baserat på praktiska tillämpningar, skapar förutsättningar till ett kontinuerligt lärande för de aktörer som ska tillhandahålla infrastrukturen
  • Vi vill hitta lämpliga steg i utvecklingen som möter praktiska behov och därmed kunna ge värde.
  • Vi vill ha pilot(er) för respektive steg i utvecklingen, så att nödvändiga frågor identifieras och att dessa får svar
  • Att beskriva den stegvisa utvecklingen kan även förenkla dialog med aktörer som vill veta när specifika behov kan komma att stödjas av infrastrukturen

Idé till huvudsakliga steg

Bilden beskriver huvudsakliga steg för att möta behov hos organisationer längre ned i kedjan, dvs behov av pålitlig information om andra organisationer, system och användare.

MVP och inkrementell produkt

Vad realiseras i de olika stegen i färdplanen 

StegPrimär nyttaVad tillkommer
Steg 1Vilket system och vilken organisationen tillhör det?Systemidentitet, organisationskoppling
Steg 2Vad får organisationen göra?Organisationsbehörighet, uppdrag, avtal
Steg 3Vem är användaren och var hör den hemma?Användaridentitet, organisationstillhörighet
Steg 4Vad får användaren göra?Roller, uppdrag, behörighetsintyg

Steg 1 - Identitet på system och organisation (MVP)

I det första steget etableras en gemensam grund för tillit mellan organisationer genom att tekniska system kan identifiera sig och kopplas till en ansvarig organisation. Producenten får därmed pålitlig information om vilket system som anropar och vilken juridisk person som står bakom anropet.

Detta steg fokuserar på maskin-till-maskin-kommunikation utan användare i tillitskedjan. Infrastrukturen möjliggör verifiering av systemidentitet och organisationstillhörighet samt säkerställer att anslutning skett enligt gemensamma krav. Steget skapar förutsättningar för automatiserad tillit mellan system, men omfattar inga behörighetsbedömningar eller delegering.

Läs mer på Steg 1 (MVP 2026) - Federationsinfrastruktur för maskin-till-maskin (Basutbud) 

Centralt användningsfall - Verifiera systemidentitet

Producenten kan verifiera vilket system som anropar och vilken juridisk organisation som ansvarar för systemet. Ingen behörighet. Ingen användare. Endast verifierbar identitet och tillit.

Konsument

Producent

Federationsinfrastruktur

Huvudanvändningsfall

  • Anropa annan organisations API under egen systemidentitet

Delanvändningsfall

  • Registrera system och organisation i federationen

  • Publicera metadata enligt policy

  • Hantera nycklar och certifikat

  • Säkerställa att anrop görs med rätt systemidentitet

Löses i steg 1

  • Möjlighet att delta i federerad maskin-till-maskin-samverkan

Huvudanvändningsfall

  • Verifiera att inkommande anrop kommer från ett betrott system

Delanvändningsfall

  • Slå upp konsumentsystemets metadata via uppslags- och verifieringstjänst

  • Verifiera tillitskedja till rätt Tillitsankartjänst

  • Koppla systemet till juridisk organisation

  • Logga och spåra anrop per organisation/system

Löses i steg 1

  • Grund för automatiserad tillit

  • Eliminering av bilaterala certifikatutbyten

Huvudanvändningsfall

  • Tillhandahålla verifierbar systemidentitet kopplad till organisation

Delanvändningsfall

  • Utfärda och publicera metadata för system

  • Etablera tillitskedja till Tillitsankartjänst

  • Möjliggöra uppslag och verifiering av metadata

  • Säkerställa att anslutning skett enligt gemensam anslutningspolicy

  • Hantera livscykel för nycklar, metadata

Löses i steg 1

  • Teknisk och organisatorisk tillit

  • Spårbar ansvarig organisation

Steg 2 - Behörighet för organisation

I det andra steget utökas tillitsmodellen till att även omfatta organisationens egenskaper och relationer till andra organisationer. Producenten kan i detta steg få pålitlig information om vilken typ av organisation som står bakom ett system, exempelvis om organisationen är vårdgivare, huvudman eller annan relevant aktör.

Steget möjliggör även mer komplexa organisatoriska relationer, såsom att ett system kan agera för en annan organisation. Tilliten är fortsatt maskin- och organisationsbaserad, utan att användare introduceras. Detta ger ett viktigt mellansteg där organisatorisk behörighet och ansvar kan hanteras innan individnivån tillkommer.

Centralt användningsfall - Organisatorisk behörighet

Producenten kan avgöra om organisationen bakom systemet har rätt att agera i ett visst sammanhang. Fortfarande inga användare.

KonsumentProducentFederationsinfrastruktur

Huvudanvändningsfall

  • Visa att organisationen uppfyller krav för att nyttja viss tjänst

Underanvändningsfall

  • Ansöka om och förvalta tillitsmärken

  • Koppla system till rätt organisatoriskt uppdrag

  • Säkerställa korrekt organisatorisk kontext vid anrop

Löses i steg 2

  • Möjlighet att delta i fler samverkanskontexter

Huvudanvändningsfall

  • Avgöra om organisationen är behörig att nyttja tjänsten

Underanvändningsfall

  • Verifiera egenskapsintyg

  • Kombinera systemidentitet + egenskapsintyg

  • Fatta beslut om tillåtelse/avslag på organisationsnivå

Löses i steg 2

  • Automatiserad organisationsprövning

  • Minskad manuell avtalslogik i varje integration

Huvudanvändningsfall

  • Förmedla verifierbar organisatoriska egenskaper och relationer

Underanvändningsfall

  • Utfärda och verifiera tillitsmärken / egenskapsintyg

  • Koppla organisation till federationskontext(er)

  • Stöd för att ett system agerar för annan organisation

Löses i steg 2

  • Organisationsbaserad behörighet

  • Grund för juridiskt ansvar och delegering

Steg 3 - Användares identitet och organisationstillhörighet

I det tredje steget införs stöd för användares identitet och deras organisationstillhörighet. Producenten kan nu lita på vem användaren är och vilken organisation användaren representerar, även när användaren kommer från en annan organisation än producenten.

Detta steg möjliggör scenarier där användare kan använda tjänster över organisationsgränser utan att konton behöver förprovisioneras hos producenten. Steget omfattar dock inte behörighetsbedömningar på individnivå. Producenten får ett tillförlitligt beslutsunderlag om användarens identitet och organisatoriska kontext, men fattar fortsatt egna beslut om vad användaren får göra.

Centralt användningsfall - Användaridentitet och organisationstillhörighet

Producenten kan verifiera vem användaren är och vilken organisation användaren representerar. Ingen användarbehörighet ännu.

Konsument

Producent

Federationsinfrastruktur

Huvudanvändningsfall

  • Låta användare nyttja externa tjänster utan lokala konton

Underanvändningsfall

  • Intyga användarens identitet

  • Intyga organisatorisk tillhörighet

  • Säkerställa korrekt användarkontext vid åtkomst

Löses i steg 3

  • Minskad administrativ börda för användarkonton

Huvudanvändningsfall

  • Lita på vem användaren är och vem den representerar

Underanvändningsfall

  • Ta emot och verifiera användarintyg

  • Koppla användare till organisation i beslutslogik

  • Logga användaraktivitet med organisatorisk spårbarhet

Löses i steg 3

  • Inloggning över organisationsgränser

Huvudanvändningsfall

  • Förmedla verifierbar användaridentitet med organisatorisk kontext

Underanvändningsfall

  • Koppla användaridentitet till organisation

  • Förmedla att användaren agerar inom rätt organisatorisk kontext

Löses i steg 3

  • Federerad användaridentitet över organisationsgränser

Steg 4 - Användares behörighet

I det fjärde steget utökas infrastrukturen till att även förmedla behörighetsgrundande information om användare, såsom roller, funktioner eller uppdrag. Användarorganisationen kan i detta steg intyga att en användare har en viss behörighet, till exempel att användaren är lärare eller handläggare.

Producenten kan använda denna information som underlag för automatiserade åtkomstbeslut, samtidigt som det slutliga ansvaret för beslut om åtkomst och utlämning fortsatt ligger hos producenten. Steget skapar förutsättningar för att minska behovet av lokala behörighetsregister och manuella förvaltningslösningar, utan att centralisera beslutsfattandet.

Centralt användningsfall - Användarbehörighet

Producenten kan använda verifierbar behörighetsinformation om användaren som underlag för åtkomstbeslut.

KonsumentProducentFederationsinfrastruktur

Huvudanvändningsfall

  • Intyga användares roller och uppdrag

Underanvändningsfall

  • Förvalta behörighetsinformation

  • Utfärda behörighetsintyg (roller, uppdrag, funktioner)

  • Säkerställa korrekt behörighetsstyrning internt

Löses i steg 4

  • Återanvändbar behörighetsinformation i flera tjänster

Huvudanvändningsfall

  • Fatta automatiserade åtkomstbeslut baserat användares
    behörigheter

Underanvändningsfall

  • Verifiera behörighetsintyg

  • Kombinera identitet, organisation och behörighet

  • Tillämpa egen beslutslogik (ansvar kvarstår)

  • Logga beslut och intygsunderlag

Löses i steg 4

  • Minskade lokala behörighetsregister

  • Ökad rättssäkerhet och spårbarhet

Huvudanvändningsfall

  • Förmedla behörighetsgrundande information om användare

Underanvändningsfall

  • Säkerställa koppling mellan användare, organisation och uppdrag

  • Stöd för kombination av flera intyg

Löses i steg 4

  • Skalbar och standardiserad förmedling av behörighetsinformation

Roadmap för utveckling och lansering

Roadmappen illustrerar den övergripande riktningen för utveckling och införande av federationsinfrastrukturen. Den ska läsas som en orienterande bild av hur förmågor kan byggas upp stegvis över tid, inte som en detaljerad tids- eller leveransplan.

MVP 2026 är det enda steg som omfattas av detta beslutsunderlag. Efterföljande steg är beroende av erfarenheter och lärdomar från MVP:n samt av separata beslut om inriktning, omfattning och prioritering.

Varje steg i roadmappen förutsätter att föregående steg har införts, utvärderats och bedömts som tillräckligt stabilt innan nästa steg initieras.

Färdplan - stegvis införande

Legend

Avser framtagning, prototypning och teknisk realisering av förmågor. Innebär inte att funktionen är redo för användning i produktion.

Avser att funktioner tas i drift för faktisk användning inom definierad omfattning. Innebär inte automatiskt breddinförande.

Avser kontrollerad prövning av funktioner med utvalda aktörer i syfte att samla erfarenheter, verifiera antaganden och vidareutveckla lösning.

Avser formell tillgängliggörande av en förmåga för fler aktörer, efter genomförd utvärdering och separat beslut.



  • No labels