Pilotplan – miljöer, anslutning och tester

Syfte och avgränsning

Planen visar vad Digg, Inera, Internetstiftelsen och EHM behöver leverera tillsammans för att etablera produktionsinstanser, genomföra tester och avsluta piloten. Parterna planerar sitt interna arbete mot gemensamma invärden och milstolpar.

Planen omfattar federationsinfrastrukturen och registrering av EHM:s protokollentiteter. Fullständiga NVF–VOK-anrop och övriga verksamhetsmål ligger utanför. Avtal och prövning nämns där de är förutsättningar för produktionsanslutning eller fortsatt användning.

Utgångsläge: Anslutningar och registreringar i sandbox är redan klara. De är invärden till testerna och redovisas inte som en kvarstående aktivitet.

Läs bilden: Faserna ligger längs en horisontell tidsaxel. M1–M4 markeras med trianglar och linjer genom spåren. Aktiviteternas nummer återkommer nedan. Miljöetablering, anslutning, tester och produktionssättning hålls isär; ett kompletterande spår visar gemensamma arbetssätt. Fas 2 och 3 överlappar i februari. Streckade aktiviteter om egenskapsintyg är förslag. Tidsplaceringen är schematisk.

Begrepp och ansvar

Aktiviteter gäller de parter och instanser som berörs. M1 kräver minst en ansluten Intermediate, inte att båda AO är klara samtidigt. Vilken AO och EHM-entitet som ingår ska bekräftas.

Faser och milstolpar

Datumen 1 mars och 1 april behöver hänga ihop

Det tidigare kravet: Senast den 1 mars ska utvärdering, komplettering av pilotanpassade krav och undertecknade fortsättningsavtal vara klara.

Det som inte går ihop: Den nya planen innehåller tester och incidentövning under mars. Resultaten från dessa kan inte vara slutligt utvärderade den 1 mars. En slutlig sammanställning i april kan inte heller användas som beslutsunderlag för övergången den 1 april.

Förslag att förankra:

• 1 mars: en första utvärdering, avtalsläget och en lista över kvarstående krav och tester redovisas. Varje kvarstående punkt får ansvarig och sista datum.
• Före 1 april: nödvändiga resultat och godkännanden för fortsatt användning finns. Parterna beslutar om övergång, avveckling eller uttryckligen ändrade villkor/tider.
• Under april: slutrapport, samlad återföring av lärdomar och administrativt avslut färdigställs.

Detta är ett förslag till precisering, inte en beslutad flytt av 1 mars-milstolpen. Tills parterna beslutat gäller den tidigare milstolpen som en olöst planeringsförutsättning.

Fas 1 – sandbox till produktion

Sandbox används före produktion med hänsyn till den begränsade tillämpningen och att det gäller en första etablering. Grundläggande samordning av rättningar, omtester och störningar behövs redan nu; den gemensamma förändrings- och incidentförmågan utvecklas och övas i fas 3.

1.1 Säkerställ produktionsinstanser och driftförutsättningar

Invärden

• Digg och AO: utpekade tjänster, driftansvariga och pilotkrav.
• EHM: vald protokollentitet och dess registreringsunderlag.

Genomförande

• Digg: säkerställer produktionsinstanser av Trust Anchor och Resolver samt registreringsåtkomst.
• Berörd AO: bekräftar en särskild produktionsinstans av Intermediate, redo senast den 14 december, och att den uppfyller pilotkraven oavsett internt miljönamn.
• Alla: bekräftar adresser, nycklar, ansvar, kontaktvägar och hantering vid störningar.

Klart när: Berörda produktionsinstanser är tillgängliga för anslutning och verifiering. Driftförutsättningar och begränsningar är dokumenterade.

1.2 Genomför gemensamma sandboxtester

Invärden

• Digg, berörda AO och EHM: befintliga sandboxregistreringar är tillgängliga; testurval, testdata, utförare, verktyg, testtid och acceptanskriterier är överenskomna.

Genomförande

• Digg och AO: testar tillitskedjor, uppslag och metadatahantering, initialt manuellt med tillgängliga verktyg.
• EHM: tillhandahåller entitetsunderlag och rättar brister i det.
• Testsamordnaren: sammanställer resultat, avvikelser och omtester.

Klart när: Överenskomna normalfall samt nödvändiga fel- och säkerhetsfall är verifierade. Kvarstående brister är bedömda inför produktion.

1.3 Godkänn och genomför produktionsanslutning

Invärden

• Digg och berörd AO: instanser från 1.1 och godkända testresultat från 1.2.
• EHM: minst en protokollentitet med kontrollerade uppgifter.
• Berörda parter: prövning, pilotavtal och klartecken för anslutning är klara.

Genomförande

• Digg: ansluter AO:s Intermediate som produktionsinstans.
• AO: registrerar EHM:s protokollentitet; EHM bekräftar uppgifterna.
• Digg och AO: utför överenskomna manuella metadatakontroller där automatiskt stöd saknas och bestämmer hur ändringar upptäcks och hanteras.

Klart när: Produktionsregistreringen omfattar Diggs Trust Anchor, minst en Intermediate och minst en protokollentitet hos EHM.

1.4 Verifiera produktionsanvändningen

Invärden

• Digg, berörd AO och EHM: 1.3 är klar; verifieringstid, utförare, förväntat resultat och hantering vid fel är överenskomna.

Genomförande

• Digg och AO: verifierar tillitskedja och uppslag via Resolver.
• EHM: bekräftar att rätt entitetsuppgifter används.
• Utsedda godkännare: bedömer resultat och accepterade begränsningar, inklusive avsaknad av metadatapolicy hos Diggs Trust Anchor.

Klart när: M1 är dokumenterat uppnådd senast den 14 december. Om villkoren inte är uppfyllda fattas beslut om åtgärd eller senareläggning.

Fas 2 – utökad testförmåga och metadata enforcement

Digg tar fram gemensam metadatapolicy. AO inför motsvarande regler för sina Intermediate och registreringskontroller. Det innebär inte ett krav att kopiera samma policyfil ordagrant: policy från Trust Anchor gäller genom kedjan för berörda entitetstyper. Intermediate kan komplettera med förenliga skärpningar men inte luckra upp överordnad policy. Resolver behöver kombinera och tillämpa kedjans policy korrekt. Därför testas både registrering och uppslag. [S4]

2.1 Etablera gemensamma testförutsättningar

Invärden

• Alla: behov, tillgängliga instanser, resurser och erfarenheter från fas 1.

Genomförande

• Digg och AO: etablerar/anpassar instanser för QA/test och genomför nödvändiga anslutningar och registreringar.
• EHM: tillhandahåller testentiteter och testdata.
• Alla: enas om tillgänglighet, versionskombinationer, återställning av testdata och gemensamma testfönster.

Klart när: En sammanhängande uppsättning testinstanser och testdata finns med avgränsning mot produktionsanvändningen.

2.2 Etablera automatiserade testverktyg

Invärden

• Digg, AO och EHM: överenskommet testurval, förväntade resultat och dataformat.
• Testsamordnaren: utsedd verktygsansvarig, bemanning och tillgång till instanserna i 2.1.

Genomförande

• Utsedd verktygsansvarig: återanvänder eller utvecklar verktyg som utför tester och sparar resultaten.
• Digg och AO: tillhandahåller åtkomst och granskar testerna för sina tjänster.
• EHM: tillhandahåller entitetsvariationer; testsamordnaren samordnar provkörning.

Klart när: Det valda testurvalet kan köras automatiserat och upprepas med spårbara resultat. Verktygen kan vidareutvecklas för metadatapolicytesterna i 2.5.

2.3 Ta fram gemensam metadatapolicy

Invärden

• Digg: identifierade krav som policyn ska uttrycka och vilka entitetstyper de gäller.
• AO och EHM: aktuella metadata, kända variationer och begränsningar i komponentstödet.

Genomförande

• Digg: utformar och versionssätter policyn samt beskriver förväntade utfall.
• AO: granskar införandet i Intermediate och registreringskontrollerna.
• EHM: identifierar nödvändiga ändringar i egna entiteters metadata.
• Alla: enas om omfattning, godkännandekriterier och hantering av redan registrerade entiteter.

Klart när: En överenskommen policyversion med införandeansvar och testbara förväntningar finns.

2.4 Implementera metadatapolicy i QA/test

Invärden

• Digg och AO: testinstanser från 2.1, policyversion från 2.3 och nödvändigt komponentstöd.
• EHM: testmetadata för både fungerande och felaktiga fall.

Genomförande

• Digg: inför policyn i Trust Anchor så att den publiceras i relevanta signerade uttalanden om underordnade entiteter.
• AO: inför motsvarande regler i sina Intermediate och registreringskontroller; dokumenterar eventuella förenliga kompletteringar.
• Ansvariga för Resolver: säkerställer stöd för att kombinera och tillämpa policyn vid uppslag.

Klart när: Policyversionen är införd i berörda testinstanser och kan verifieras genom hela kedjan.

2.5 Verifiera enforcement med automatiserade tester

Invärden

• Digg och AO: implementation från 2.4 samt verktyg från 2.2 anpassade till policytesterna.
• EHM och testsamordnaren: testdata och förväntade utfall från 2.3 är tillgängliga.

Genomförande

• Digg och AO: kör tester av registreringskontroller, policyns genomslag och uppslag via Resolver.
• EHM: medverkar med metadata som prövar tillåtna värden, regelbrott och förändringar.
• Testsamordnaren: jämför resultat mellan instanser och samordnar rättningar och omtester.

Klart när: Policyn ger förväntade utfall: metadata kontrolleras eller justeras enligt reglerna; policykonflikter och ogiltiga kedjor avvisas. Befintlig avsedd funktion fungerar fortsatt. [S4]

2.6 Inför metadatapolicy i produktion

Invärden

• Digg, berörda AO och EHM: godkända resultat från 2.5, bedömning av befintliga registreringar, införandebeslut, gemensamt tidsfönster och återställningsplan.

Genomförande

• Digg och AO: inför policyn samordnat i berörda produktionsinstanser och verifierar utfallet.
• EHM: genomför nödvändiga metadataändringar inför aktiveringen.
• Utsedda godkännare: avgör vilka manuella kontroller som kan ersättas och vilka som behöver behållas.

Klart när: M2 är uppnådd: automatiserat testurval och införd, verifierad metadata enforcement. Införandet samordnas med 3.1; ett dokumenterat införandebeslut och återställningsansvar behövs även om hela förändringsprocessen ännu inte är färdig.

Fas 3 – förändringshantering och incidenthantering

Arbetssätten tas fram från februari. Tekniska tester och övningar genomförs när nödvändiga testförutsättningar från fas 2 finns. En grundläggande förmåga att hantera störningar finns redan från fas 1; här utvecklas och prövas den gemensamma kedjan.

3.1 Etablera gemensam förändringshantering

Invärden

• Alla: utsedda kontakter, interna beslutsvägar, beroenden och möjliga införandefönster.

Genomförande

• Digg, AO och EHM: enas om ändringsförslag, konsekvensbedömning, beslut, test, versionssamordning, information, återställning och uppföljning.
• Utsedda godkännare: väljer en ändring som ska pröva arbetssättet. Förslaget är egenskapsintyg enligt 3.2–3.4.

Klart när: Gemensamt arbetssätt, ansvarsfördelning och omfattning för försöksändringen är överenskomna.

3.2 Anslut EHM som Trust Mark Issuer – förslag

Invärden

• Alla: förslaget om egenskapsintyg är godkänt enligt 3.1.
• EHM: TMI-instans, ett avgränsat egenskapsintyg och en egen protokollentitet.
• Digg och berörd AO: tekniskt stöd och överenskommen registreringsväg.

Genomförande

• EHM: tillhandahåller Trust Mark Issuer (TMI).
• Digg och berörd AO: registrerar och konfigurerar tilliten till utfärdaren enligt överenskommen ansvarsfördelning, först i QA/test.

Klart när: EHM är ansluten som TMI för test och kan utfärda ett egenskapsintyg för en egen protokollentitet.

3.3 Testa utfärdande och teknisk verifiering – förslag

Invärden

• EHM: fungerande TMI och testentitet från 3.2.
• Digg och berörd AO: utsedd verifierande tjänst, stöd och överenskomna testutfall.

Genomförande

• EHM: utfärdar egenskapsintyget.
• Ansvarig för verifierande tjänst: kontrollerar trust mark tekniskt och prövar överenskomna ogiltiga fall.
• Testsamordnaren: dokumenterar resultat och avvikelser.

Klart när: Ett giltigt trust mark kan verifieras för rätt entitet och överenskomna ogiltiga fall avvisas. Testet visar teknisk förmåga, inte verksamhetsmässig rätt till åtkomst.

3.4 Inför och följ upp försöksändringen

Invärden

• Alla berörda: godkända tester, beslut enligt 3.1, införandefönster samt verifierings- och återställningsplan. För egenskapsintyg krävs godkänt 3.3.

Genomförande

• Varje berörd part: inför sin del i överenskommen ordning.
• EHM och ansvarig för verifierande tjänst: verifierar utfärdande och kontroll i produktion om egenskapsintyg valts.
• Alla: följer upp införandet och förbättrar arbetssättet.

Klart när: En ändring har förts genom hela arbetssättet och verifierats i produktion. Om egenskapsintyg inte väljs behöver en annan försöksändring beslutas.

3.5 Fastställ gemensam incidenthantering

Invärden

• Digg, AO och EHM: befintliga incidentrutiner, kontaktpersoner och interna mandat.

Genomförande

• Digg: samordnar förslaget för incidenter som berör flera parter.
• AO: beskriver kontakt- och eskaleringskedjan mellan EHM, den egna organisationen och Digg.
• EHM: beskriver upptäckt, anmälan och mottagning av information för egna entiteter.
• Alla: enas om mottagning, påverkansbedömning, eskalering, åtgärdsbeslut, lägesinformation, återställning och avslut. Kontaktkanaler och förväntade svarstider fastställs för piloten.

Klart när: En gemensam incidentrutin och kontaktlista finns med tydligt ansvar i varje led. Förslaget bygger vidare på pilotunderlagets AO-V3.5 och AO-V4. [S2]

3.6 Öva incidentkedjan och återställningen

Invärden

• Alla: rutin från 3.5, bemannad övningstid, valt scenario, förväntade utfall och avgränsad testmiljö.

Genomförande

• Digg och AO: förbereder ett scenario, exempelvis felaktig metadata som ger misslyckade uppslag, eller en otillgänglig Resolver.
• EHM, AO och Digg: övar upptäckt, rapportering, eskalering, samordnade åtgärder, information och återställning i båda riktningar genom kedjan.
• Utsedd övningsledare: dokumenterar händelseförlopp, svarstider, brister och förbättringsåtgärder.

Klart när: Incidentkedjan har demonstrerats, återställning verifierats och förbättringar fått ansvarig. M3 kräver både genomförd försöksändring (3.4) och utvärderad incidentövning (3.6).

Fas 4 – avslut och utvärdering

4.1 Avsluta, sammanställ och lämna över

Invärden

• Digg, AO och EHM: testresultat, incidentövning, erfarenheter, kvarstående brister och besked om fortsatt användning.
• Berörda beslutsfattare: före den 1 april har fortsättningsvillkor och pilotavsteg hanterats eller lett till ett uttryckligt beslut om annan hantering.

Genomförande

• Digg, föreslagen samordnare: sammanställer utvärdering och överlämning.
• Alla: bekräftar slutsatser, tar ansvar för kvarstående åtgärder och hanterar egna instanser och registreringar enligt beslut om fortsatt drift eller avveckling.

Klart när: Piloten har upphört den 1 april och slutrapport samt administrativt avslut är färdiga under april. Vad som fortsätter, avvecklas och lämnas över är dokumenterat. Pilotavslut innebär inte automatiskt att produktionsinstanser stängs.

Att fastställa gemensamt

• Alla: ansvariga per part, testsamordnare, verktygsansvarig, övningsledare, godkännare och tillgänglig tid.
• Digg, AO och EHM: instanser/entitet för M1, acceptanskriterier och produktionsklartecken.
• Digg och AO: policyomfattning, komponentstöd, testverktyg och införandeordning för M2.
• Alla: gemensamma test- och övningsfönster samt om egenskapsintyg väljs som försöksändring.
• Alla: preciseringen av 1 mars och beslutsunderlaget inför 1 april.

Vid avstämning anger varje part klart, planerat datum eller blockerande beroende för sina invärden. Sena inleveranser följs till berörda aktiviteter och milstolpar.

Underlag och antaganden

• [S1] Johan Tjäders förtydliganden och inspelade kommentarer, chatten 22 oktober 2026: styr den uppdaterade omfattningen, perioderna och att sandboxanslutningen är klar. ”14 oktober” i senaste inspelningen har tolkats som 14 december, eftersom decembermålet samtidigt bekräftas.
• [S2] RIB-221026-1329-108.pdf: s. 5–17 om miljöer och tester; s. 37–38 om tidigare avslutsdatum; s. 43–44, AO-V3.5 och AO-V4, om kontaktvägar, samordning, incidentkommunikation och uppföljning. Underlaget innehåller förslag och pilotanpassningar; inga nya bindande incidenttider har antagits.
• [S3] Tidigare transkriberingar och image(2).png, ”SIB programplan”: underlag för beroenden, inleveranser och bildens tidsstruktur. Bildens längre färdplan har inte förts över som åtaganden.
• [S4] OpenID Federation 1.0, avsnitt 6.1.1 och 6.1.4: kontroll av policyhierarki och enforcement. Ansvarsfördelningen och införandeaktiviteterna här är planeringsförslag för piloten, inte krav som standarden tilldelar de namngivna organisationerna.

Aktivitetsnumreringen har uppdaterats. M2/M3:s detaljerade acceptans, incidentövningens scenario och preciseringen av 1 mars behöver förankras.

Miljöetablering

September

• 10 september – OIDF/OIDC-sandbox version 1 etablerad

Oktober

• 15 oktober – QA- och produktionsmiljöer etablerade (Inera TEST)

November

• v. 45 – Pentest av QA-miljön genomfört
• 15 november – Skarpa anslutningar till QA och produktion möjliga (Inera TEST)
• 20 november – GO/NO-GO-beslut inför produktionsstart

December

F.K

• 1 december – Produktionsstart för Sverige-id och OIDC i Sweden Connect
• 14 december - Produktionssättning Federationskontext BAS

Februari 2027

• Inera lyfter till QA senast sista februari

Mars 2027 

• Inera har PEN-testat och lyfter till PROD senast sista mars

Miljöstrategi

SBX - ska vara öppen för parter (AO och FM) att ansluta till löpande, även parter utanför definierad VOK-pilot

QA - Förberedande miljö för pilotförberedelser, här sker tekniska tester

Prod - Genomförande av pilot

Produktionsmiljö för pilot

Federationsoperatör och anslutningsoperatör ska tillhandahålla miljöer för produktion i enlighet med regelverk för Federationskontext BAS och pilotavtal. I pilotavtal regleras bland annat SLA.

Parterna är införstådda med att piloten bedrivs med produktionstjänster och att de miljöer som används inom piloten därför ska uppfylla de krav som gäller för produktionsmiljöer enligt regelverk och avtal, oavsett miljöernas interna benämning.

E-hälsomyndigheten är enda federationsmedlem i piloten. I de fall då infrastrukturtjänster inte är tillgängliga eller inte fungerar som förväntat kommer E-hälsomyndigheten att använda lokal registrering av entiteter för att möjliggöra åtkomst till API:er.

Pilotstrategi

• Etablera metadataspec med "enforcement" i SBX så att