You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 12 Next »

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

  • 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 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

  1. Anslutningsoperatör ansluter sig till federationskontexten (avtal tecknas, intermediate driftsätts och registreras mot Trust Anchor).
  2. Federationsmedlem ansluter sig (avtal tecknas med anslutningsoperatör).
  3. 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

  1. Uppslag och validering av entiteter via:
    • 4a. Federationsoperatörens uppslagstjänst (Resolver vid Trust Anchor)
    • 4b. Anslutningsoperatörens uppslagstjänst (Resolver vid intermediate)
  2. 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

  1. Livscykelhantering av open source-komponenter (release, patch, versionshöjning) — rollfördelning mellan Digg och anslutningsoperatör prövas.
  2. Metadataförändringar inklusive nyckelrotation och avregistrering av ansluten komponent.

D. Incident- och krishantering

  1. Registrering av entitet med felaktigt entity-id (särskilt relevant vid hostad metadata, där entity statement location måste matcha domänen).
  2. Otillgänglighet av Trust Anchor respektive Resolver (kort respektive längre tid).
  3. 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

  1. Lasttest av resolver hos federationsoperatör och anslutningsoperatör.
    1. 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-1Anslutning och registrering av anslutningsoperatörer fungerar enligt fastställd anslutningspolicy och anslutningsprocess.
FO-2Konsekvenserna av otillgänglig Trust Anchor respektive Resolver är förstådda (kort resp. lång tid), inklusive effekter på federationens funktion.
FO-3Fö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-4Process för kontroll/revision vid anslutning av anslutningsoperatör är prövad och utvärderad.
FO-5Livscykelhantering 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-1Rollen anslutningsoperatör är konkretiserad: ansvar, befogenheter, beroenden till Digg och federationsmedlem.
AO-2Utformning av det kommersiella erbjudandet mot federationsmedlemmar är utvärderat (scope, prismodell, SLA).
AO-3Kravbilden mot anslutningsoperatör är förstådd och värderad: avtal, tekniska krav, organisatoriska krav.
AO-4Implementations- och förvaltningsinsatsen är uppskattad — vad kostar det att etablera och förvalta en intermediate och rollen anslutningsoperatör över tid.
AO-5Supportering 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-6Konsekvenserna av otillgänglig intermediate respektive resolver är förstådda.
AO-7Hur federationskomponenter kan integreras i befintliga tekniklösningar och driftsmiljöer är utrett.
AO-8Kundperspektivet: vad efterfrågar federationsmedlemmar, hur ser anslutningsresan ut för dem.

Federationsmedlem (EHM)

#Kriterium
FM-1Avtal är tecknat med anslutningsoperatör.
FM-2Lyckade anrop till VOK externt FHIR-API har genomförts, där åtkomstintyg verifierats via federationsinfrastrukturen.
FM-3Förståelse för vad en anslutning till federationsinfrastrukturen innebär tekniskt, organisatoriskt och avtalsmässigt.
FM-4Både egenpublicerad och hostad metadata har prövats (vid båda: motsvarande förståelse etablerad).

Federationsplattform och Federationskontext (tvärgående)

#Kriterium
FK-1Avtalsmodell och avtalsinnehåll är good enough som långsiktig grund — harmonierar med parternas befintliga avtalsstrukturer.
FK-2Processen för hur förändringar i avtal träder i kraft (inkl. grace periods) är hanterbar.
FK-3Hostad respektive egenpublicerad metadata är prövad vid registrering, uppslag och verifiering — båda metoderna fungerar.
FK-4Roller, krav och ansvarsfördelning vid krishantering är utredda i syfte att bibehålla förtroendet för federationen.
FK-5Normativt ramverk (anslutningspolicy, registreringspolicy, tekniska säkerhetskrav, egenskapsintygspolicyer) är verifierat i praktisk tillämpning och har identifierade förbättringar för Steg 2.


Vad sker efter att piloten är klar?

  • No labels