2026-06-xx


2026-05-13

Noteringar från mötet:

Sammanfattning av mötesanteckningar

Syfte med mötet

Mötet handlade om en pilot för att etablera och testa en federationsstruktur för system-till-system-kommunikation, med fokus på både teknisk infrastruktur och verksamhetsmässiga/juridiska regelverk.

Det betonades att tekniken till stor del redan är verifierad, medan det stora kvarvarande arbetet gäller:

Piloten ska hjälpa till att konkretisera detta och skapa underlag för en framtida produktionssättning.

Övergripande mål med piloten

Piloten ska testa om parter kan ansluta till en federation och använda den enligt tänkt modell. Fokus ligger inte bara på teknisk funktion, utan även på att provtrycka hela den organisatoriska och regelmässiga strukturen.

Målet är att under 2026 kunna komma till produktionsmiljö, men deltagarna konstaterade att detta beror på respektive organisations förutsättningar, kostnader, resurser och behov.


Användningsfall och utvärderingskriterier

Följande områden nämndes som viktiga för piloten:

Det betonades att piloten inte får “fuska” med svårigheterna. Om parterna exempelvis bara laddar ned metadata manuellt och konfigurerar tjänsterna på vanligt sätt, bevisar piloten inte tillräckligt mycket om federationen.

Tidsplan

Den preliminära tidsplanen är:


Regelverk och artefakter

Det finns ett paket av artefakter som behöver tas fram. Dessa omfattar bland annat:

En viktig fråga var hur dessa dokument ska hänga ihop. Det uttrycktes behov av en tydligare “röd tråd” eller skelettstruktur som visar relationen mellan avtalsmallar, villkor, federationsregelverk, tekniska ramverk och profiler.

Det diskuterades också om alla artefakter verkligen måste levereras samtidigt, eller om de kan komma stegvis.

Registreringspolicy och kontroller

Registreringspolicyerna håller på att brytas ned i mindre, mer återanvändbara delar. Exempel på kontroller som nämndes:

Tanken är att sådana kontroller på sikt kan uttryckas som bevis eller markeringar i metadata, så att det framgår vilka kontroller en anslutningsoperatör har gjort.

Det föreslogs att registreringspolicyer bör hållas korta, tydliga och återanvändbara, snarare än att allt bakas in i en stor policy.

Teknisk profilering och system-till-system

En längre diskussion fördes om huruvida det behövs ytterligare specifikationer för system-till-system-kommunikation.

Frågan gällde bland annat om befintliga ENA OAuth-profiler räcker, eftersom basprofilen tillåter flera alternativ, exempelvis:

I detta användningsfall verkar private key JWT vara det relevanta alternativet.

Slutsatsen blev ungefär:

Metadata, hosting och OpenID Federation

En central teknisk diskussion gällde hur metadata ska hanteras.

Två modeller diskuterades:

  1. Parter publicerar sin egen metadata
  2. Metadata hostas av annan part eller anslutningsoperatör

Det konstaterades att hosting kan vara nödvändigt för befintliga system och legacy, men att det på sikt helst bör undvikas. Den långsiktiga ambitionen är att parter själva ska publicera sin metadata och upptäcka andra parter via federationen.

För piloten fanns argument för att testa båda modellerna, eftersom det kan vara viktigt att visa att de kan samexistera i samma federationskontext.

Produktionssättning och kostnader

Flera deltagare betonade att testmiljö inte är ett stort problem, men att produktion är en helt annan fråga.

Produktionssättning innebär bland annat:

Både Internetstiftelsen och Inera signalerade att testmiljö är hanterbart, men att produktion kräver större beslut och resurser.

Det noterades också att anslutningsgrad och framtida finansiering är avgörande. Det är svårt att investera i full produktionskapacitet utan tydligare bild av hur många parter som faktiskt ska anslutas.

DIGG:s komponenter och återanvändning

DIGG utvecklar komponenter primärt för sin roll som federationsoperatör för Sweden Connect, inte generellt för ENA. Samtidigt är ambitionen att så mycket som möjligt ska släppas som open source.

Komponenter som diskuterades:

Det förtydligades att en registreringsportal är mer verksamhetsspecifik och därför sannolikt inte direkt återanvändbar som färdig produkt. Däremot kan underliggande komponenter, flöden och erfarenheter återanvändas.

Skillnad mellan komponenter

Följande distinktioner gjordes:

Registry Admin

En komponent för federations- eller anslutningsoperatören. Den hanterar konfiguration, metadata, trust anchors, intermediates, trust marks och liknande.

Registration Flow

Ett konfigurerbart flöde som styr hur registrering ska ske för en viss entitet eller federationskontext.

Registreringsportal

En självbetjäningsportal där en förlitande part eller annan aktör kan registrera sig själv. Den är mer verksamhetsnära och behöver sannolikt anpassas per organisation eller sektor.

Testmiljö till 10 augusti

Det mest konkreta nästa steget är att klargöra vad som krävs för att få testmiljöer på plats till 10 augusti 2026.

En möjlig uppdelning:

Det föreslogs att nästa möte ska fokusera på miljökonfiguration och praktiska förutsättningar.

Beslut och överenskommelser

Följande framstår som beslut eller tydliga riktningar:

Öppna frågor

Strategiska och organisatoriska frågor

Juridiska och regelmässiga frågor

Tekniska frågor

Operativa frågor

Nästa steg

  1. Samla in frågor och behov från deltagande organisationer inom cirka två veckor.
  2. Boka nytt möte inom cirka tre veckor.
  3. Ha tema miljöer och tekniska förutsättningar på nästa möte.
  4. Bjuda in rätt tekniska personer, särskilt Rickard från Inera.
  5. Dokumentera tekniska synpunkter som utvärderingskriterier.
  6. Förtydliga vad som krävs för testmiljö till 10 augusti.
  7. Lyfta större frågor om SLA, kostnader, anslutningsgrad och produktion till taktisk/styrande nivå.


 

Nästa steg