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 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.
Avgränsning
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.
Ambition för miljö
Ambitionen är att pilotens end-to-end-flöde ska 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.
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
- Användningsfall för anslutningsoperatör
- Dokumentation av funktionalitet i Diggs opens source stödtjänster
- ...
Användningsfall
Användningsfallen grupperas enligt när de prövas i pilotens livscykel.
A. Etablering och anslutning
- 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 och verifiering
- Uppslag och validering av entiteter via:
- 4a. Federationsoperatörens uppslagstjänst (Resolver vid Trust Anchor)
- 4b. Anslutningsoperatörens uppslagstjänst (Resolver vid intermediate)
- Skarpt 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 open source-komponenter (release, patch, versionshöjning) — rollfördelning mellan Digg och anslutningsoperatör prövas.
- Metadataförändringar inklusive nyckelrotation och avregistrering av ansluten komponent.
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. Kapacitet
- Lasttest av resolver hos federationsoperatör och anslutningsoperatör.
- genomförs i testmiljö som en tabletop-övning och/eller ett tekniskt simulerat scenario.
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. |
| 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 vid anslutning av anslutningsoperatör är prövad och utvärderad. |
| FO-5 | Livscykelhantering av open source-komponenter fungerar (release, patch, kommunikation med nyttjare). |
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 | Avtal är tecknat med anslutningsoperatör. |
| 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). |
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. |