Status: V.0.1
Vi har gått igenom Mål med piloten och påbörjat Användningsfall
På sidan
Mål med piloten
Huvudsyfte
Piloten ska verifiera att SIB:s federationsinfrastruktur fungerar end-to-end enligt Steg 1 (MVP) i Taktisk färdplan, genom ett skarpt anropsscenario i produktionsmiljö där NVF (hos EHM) hämtar data från VOK via externt FHIR-API med åtkomstintyg som verifieras via federationsinfrastrukturen.
Piloten testar hela kedjan: avtal, anslutningsprocess, organisationsverifiering, teknisk registrering, metadatahantering och det faktiska anropsflödet — inte enbart tekniska komponenter isolerat. Detta verifierar MVP i SIB.
Piloten ska även ge underlag för fortsatt vidareutveckling av SIB och vilka ytterligare piloter som bör genomföras.
Avgränsningar
Piloten omfattar uteslutande Steg 1 (MVP): verifierbar systemidentitet och verifierad koppling mellan system och anslutande organisation.
Piloten prövar infrastrukturell tillit, inte verksamhetsmässig tillit såsom behörighetsbedömning, ändamål eller rätt till data, dessa ansvar ligger kvar på den förlitande parten (VOK/EHM).
Piloten innebär inget åtagande för parterna utöver pilotens omfattning och mål.
Piloten verifierar inte direkt frågor gällande skalbarhet.
SLA för pilot överenskoms mellan de parter som deltar.
Miljöer
Pilotens ka köras i produktionsmiljö. Inledande verifiering sker i testmiljö. Om produktionsförutsättningar inte kan etableras hos samtliga parter under 2026 genomförs piloten i testmiljö med en tydligt dokumenterad plan för produktionssättning.
Det ska finnas QA/acceptansmiljö och produktionsmiljö. På sikt blir viktigt med SBX när det ska erbjudas för en bredare massa.
Förväntningar på Pilotmiljön måste definieras. Fallback behöver finnas då SLA troligen kommer var lågt
Förutsättningar för att bedriva pilot
- Avtal för federationskontext BAS (avtal med villkorsbilagor samt tillhörande anslutningspolicy, registreringspolicy, tekniska säkerhetskrav) är fastställt och undertecknat av parterna. Dessa ska basera sig på motsvarande regelverk som tas fram inom ramen för Federationsplattformen
- Krav på anslutningsoperatör färdigställda
- Överenskomna SLA:ER på federationskomponeneter
- Användningsfall för anslutningsoperatör
- Diggs federationskomponent (OpenID Federation Service - inte admin) vilka förvaltas löpande under piloten
- Dokumentation av funktionalitet i Diggs opens source stödtjänst
- Överenskommen code of conduct vid incidenter, fel, problem osv. (kanske kopplas till AO5)
- Vidareutveckla gemensammatestfall
- ...
Användningsfall
Användningsfallen grupperas enligt när de prövas i pilotens livscykel.
A. Etablering och anslutning
- Federationsoperatör finns och kan ansluta anslutningsoperatör
- Anslutningsoperatörens federationskomponenter installeras och konfigureras. Förvaltningsförmåga (resurser, rutiner, dokumentation, etc.) skapas
- Anslutningsoperatör ansluter sig till federationskontexten (avtal tecknas, intermediate driftsätts och registreras mot Trust Anchor).
- Federationsmedlem ansluter sig (avtal tecknas med anslutningsoperatör).
- Registrering av entiteter hos anslutningsoperatören:
- 3a. Egenpublicerad metadata (federationsmedlemmen hostar själv)
- 3b. Hostad metadata (anslutningsoperatören hostar federationsmedlemmens metadata)
B. Drift: uppslag, verifiering och anrop
- Uppslag och validering av entiteter via:
- 4a. Federationsoperatörens uppslagstjänst (Resolver hos federationsoperatör)
- 4b. Anslutningsoperatörens uppslagstjänst (Resolver hos anslutningsoperatör)
- Anropsflöde: NVF begär åtkomstintyg från EHM:s auktorisationstjänst, verifierar systemidentitet via federationsinfrastrukturen, och anropar VOK:s externa FHIR-API.
C. Förändringshantering
- Livscykelhantering av federationskomponenter, (release, patch, versionshöjning) — rollfördelning mellan Digg och anslutningsoperatör prövas.
- Metadataförändringar inklusive nyckelrotation och avregistrering av ansluten komponent.
- Vidareutveckla detaljerade testfall
D. Incident- och krishantering
- Registrering av entitet med felaktigt entity-id (särskilt relevant vid hostad metadata, där entity statement location måste matcha domänen).
- Otillgänglighet av Trust Anchor respektive Resolver (kort respektive längre tid).
- Simulerad major incident: en konstruerad händelse (t.ex. komprometterad nyckel) för att testa kommunikationsvägar, felsöknings- och supportkedjor och rollfördelning mellan tre parter.
E. Icke-funktionella verifieringar
- Robusthet av komponenter hos federationsoperatör och anslutningsoperatör
- Lasttest av resolver hos federationsoperatör och anslutningsoperatör.
- genomförs i testmiljö som en tabletop-övning och/eller ett tekniskt simulerat scenario.
Kvarstår att närmare diskutera testfall för E
Utvärderingskriterier
Utvärderingskriterierna är formulerade som lärandemål vilket innebär vad ska respektive part ha förstått, verifierat eller etablerat efter piloten.
Federationsoperatör (Digg)
| # | Kriterium |
|---|---|
| FO-1 | Anslutning och registrering av anslutningsoperatörer fungerar enligt fastställd anslutningspolicy och anslutningsprocess. |
| FO-2 | Konsekvenserna av otillgänglig Trust Anchor respektive Resolver är förstådda (kort resp. lång tid), inklusive effekter på federationens funktion för att förstå lämpliga SLA:nivåer, cache-tider. |
| FO-3 | Förväntningar och behov av stöd, support och vidareutveckling av tillhandahållna open source-komponenter är kartlagda. Rollfördelning mellan Digg och anslutningsoperatörer i förvaltningen över tid är beskriven. |
| FO-4 | Process för kontroll/revision (granskning) vid anslutning av anslutningsoperatör är prövad och utvärderad i syfte att förstå hurvida krav uppnår de effekter som avses |
| FO-5 | Livscykelhantering av frederationsregelverk, vad är lämpliga grace perioder för federationskontext bas? |
| FO-6 | Utvärdera vilka för och nackdelar som BAS kan tillföra i m2m användning. |
| FO-7 | Utvärdera vad som är en lämplig namnsättning för federationskontext BAS vid en mer långsiktig etablering. |
| FO-8 | Utvärdera utifrån konkret tillämpning vad som motiverar egna federationskontexter vs. vad BAS kan tillgodose genom att utveckla Regelverk för etablering av nya federationskontexter |
| FO-9 | Utvärdera om och i så fall vad BAS skulle omfatta i en fortsatt etablering när steg 2 i taktisk färdplan ska realiseras |
Anslutningsoperatör (Inera / Internetstiftelsen)
Piloten syftar till att ge underlag för att definiera rollen anslutningsoperatör och framtida erbjudande.
| # | Kriterium |
|---|---|
| AO-1 | Rollen anslutningsoperatör är konkretiserad: ansvar, befogenheter, beroenden till Digg och federationsmedlem. |
| AO-2 | Utformning av det kommersiella erbjudandet mot federationsmedlemmar är utvärderat (scope, prismodell, SLA). |
| AO-3 | Kravbilden mot anslutningsoperatör är förstådd och värderad: avtal, tekniska krav, organisatoriska krav. |
| AO-4 | Implementations- och förvaltningsinsatsen är uppskattad — vad kostar det att etablera och förvalta en intermediate och rollen anslutningsoperatör över tid. |
| AO-5 | Supportering kring federationskomponenter är prövad: vilket stöd ges av Digg, vad ligger på anslutningsoperatören, hur fungerar felsöknings- och supportkedjan i tre led. |
| AO-6 | Konsekvenserna av otillgänglig intermediate respektive resolver är förstådda. |
| AO-7 | Hur federationskomponenter kan integreras i befintliga tekniklösningar och driftsmiljöer är utrett. |
| AO-8 | Kundperspektivet: vad efterfrågar federationsmedlemmar, hur ser anslutningsresan ut för dem. |
Federationsmedlem (EHM)
| # | Kriterium |
|---|---|
| FM-1 | Utvärdera vad BAS löser i en samverkanskontext och vad som återstår att lösa mellan parter utöver. |
| FM-2 | Lyckade anrop till VOK externt FHIR-API har genomförts, där åtkomstintyg verifierats via federationsinfrastrukturen. |
| FM-3 | Förståelse för vad en anslutning till federationsinfrastrukturen innebär tekniskt, organisatoriskt och avtalsmässigt. |
| FM-4 | Både egenpublicerad och hostad metadata har prövats (vid båda: motsvarande förståelse etablerad). |
| FM-5 | Bedömning om vad anslutning till SIB innebär för andra kommande federationsmedlemmar, för medlemmar av olika typer och förutsättningar. |
Federationsplattform och Federationskontext (tvärgående)
| # | Kriterium |
|---|---|
| FK-1 | Avtalsmodell och avtalsinnehåll är good enough som långsiktig grund — harmonierar med parternas befintliga avtalsstrukturer. |
| FK-2 | Processen för hur förändringar i avtal träder i kraft (inkl. grace periods) är hanterbar. |
| FK-3 | Hostad respektive egenpublicerad metadata är prövad vid registrering, uppslag och verifiering — båda metoderna fungerar. |
| FK-4 | Roller, krav och ansvarsfördelning vid krishantering är utredda i syfte att bibehålla förtroendet för federationen. |
| FK-5 | Normativt ramverk (anslutningspolicy, registreringspolicy, tekniska säkerhetskrav, egenskapsintygspolicyer) är verifierat i praktisk tillämpning och har identifierade förbättringar för Steg 2. |
| FK-6 | Livscykelhantering av open source-komponenter fungerar (release, patch, kommunikation med nyttjare). |
Vad sker efter att piloten är klar?
PLATSHÅLLARE som behöver diskuteras med deltagarna