På sidan
| Table of Contents |
|---|
...
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).
Ambition för miljö
Ambitionen är att pilotens end-to-end-flöde ska köras i produktionsmiljö senast december 2026. 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 i steg 2.
Förutsättningar som måste vara på plats
- Digg har etablerat sig som federationsoperatör
...
- för Federationskontext BAS.
- Minst en anslutningsoperatör (Inera och/eller Internetstiftelsen) har etablerat sig
...
- inom
...
- Federationskontext BAS
...
- .
- EHM har anslutit
...
- sig som federationsmedlem via en eller flera anslutningsoperatörer
...
Användningsfall
...
- och registrerat sina komponenter (VOK:s auktorisationsserver, NVF och FHIR-klient).
- 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
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 federationsoperatörens uppslagstjänst
- Via anslutningsoperatörens uppslagstjänst
...
- registrera en entitet med fel enitity-id (särskilt intressant utifrån metoden host:ad metadata)
- stänga av trust anchor, resolver etc.
...
Utvärderingskriterier
Federationsoperatör
...
- 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
...
- Utvärdera vad det innebär att vara anslutningsoperatör, detta inbegriper:
- Förståelse för rollen Anslutningsoperatör
- Ökad kunskap om hur erbjudandet bör/kan utformas
- Vad krävs av oss som organisation - organisatoriskt och tekniskt - för att kunna
- implementera de tekniska...
- Ökad förståelse för kravbilden för anslutningsoperatör
- Avtal
- Tekniska krav
- Organisatoriska krav
- Implementationsinsatsen - förståelse för vad det kostar att etablera OCH förvalta intermediate och rollen anslutningsoperatör
- Supportering kring federationskomponenter - vilket stöd fås gällande open source-komponenter
- Inkl. Livscykelhantering - hantera förändringar - vem gör vad
- Förståelse för konsekvenser av att en intermediate samt resolver blir otillgänglig - kort respektive längre tid
- Förståelse för hur federationskomponenter kan implementeras i befintliga tekniklösningar
- Förståelse för kundperspektivet och erbjudanden*
Federationsmedlem
- Vi har ett avtal med anslutningsoperatör
- Vi har genomfört lyckade anrop till VOK i produktionsmiljö
Federationsplattform och federationskontext
...
(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. |