Mål | Berörda artefakter | Prioritet | Ev. Deadline | Bakgrund/Behov | Leverabler (vad är klart när uppgiften är genomförd) | Involverade team | Utkomst |
|---|
| Behov och utestående frågor - ambitionen är att det ska uttryckas som mål. | Hänvisning till vilka artefakter som (kan) omfattas av uppgiften- Normativa artefakter - RU Identitet & Behörighet - Confluence | Använd följande statusar (revideras löpande) | Status |
|---|
| colour | Yellow |
|---|
| title | Should have |
|---|
|
| Status |
|---|
| colour | Green |
|---|
| title | Could have |
|---|
|
| |
|
|
| Här läggs hänvisning till utkomst in efter uppgiften är slutförd |
|---|
| Vad krävs av Anslutningsoperatörerna för att vi ska nå tillräcklig tillit i en anslutning som gör att konsumenter känner sig säker på att en anropande komponent tillhör en viss organisation. |
|
|
|
|
|
|
|
| Vilka möjligheter har Anslutningsoperatörer att styra vilka organisationer som ansluts? |
|
|
|
|
|
|
|
| Vilka skyldigheter och rättigheter har jag som anslutningsoperatör gentemot federationsoperatören? |
|
|
|
|
|
|
|
| Får jag som anslutningsoperatör ansluta mig själv federationsmedlem? |
|
|
|
|
|
|
|
| Kommer staten själv att vara Anslutningsoperatör? |
|
|
|
|
|
|
|
| Ansvarsfördelning - vilket ev. ansvar har en Anslutningsoperatör vid fel i anslutning och de konsekvenser som det får (t.ex. en komponent registreras med koppling till felaktig organisation) |
|
|
|
|
|
|
|
| Vilka möjligheter har jag som Anslutningsoperatör att finansiera mina åtaganden i rollen som Anslutningsoperatör genom SIB |
|
|
|
|
|
|
|
| Vilka kostnader åtar jag mig som Anslutningsoperatör i förhållande till SIB |
|
|
|
|
|
|
|
Vilka för- och nackdelar finns med att etablera rollen federationsområdesansvarig och vad innebär den?
Frågeställning Vilket problem löser “federationsområdesansvarig” som inte redan täcks av andra roller? Hur undviks segmentering? Hur undviks och divergerande villkor mellan områden om en sådan roll införs?
|
|
|
| Bakgrund | Mål Avtal för identifieringsdelen (förbetalda e-tjänstelegitimeringsavtalet) Frågeställning | Bakgrund Regioner/kommuner bedömer att nuvarande “förbetalda” avtal inte är ändamålsenligt/användbart och att ett nytt avtal behöver tas fram för att SIB ska kunna bygga på existerande identitetshantering. Problem som listas: ersättningslöshet (affärsmodell), begränsning till offentliga aktörer trots privata utförare, Diggs rätt att lägga till nya förlitande parter, samt HSM+flerpersonkontroll som kostnadsdrivande och potentiellt motverkar robust/distribuerad infrastruktur för kris/krig. Samtidigt refereras till RK-rapport 2025 som pekar mot återanvändning av nuvarande struktur/avtal för e-legitimering, vilket gör frågan akut att reda ut.
| Mål Ett samverkansframtaget avtal som möjliggör återanvändning av befintlig identitetshantering och som kan införas och anvädas för regioner/kommuner med hänsyn till hela aktörslandskapet. |
|
|
Metadata/registrering – delade tekniska komponenter och indirekt anslutning Frågeställning Ska metadata modelleras per teknisk komponent eller per samverkande part som nyttjar den? Hur representeras “företrädande” i metadata för att förlitande part ska kunna verifiera denna? Behövs särskilt systemleverantörsavtal och/eller villkor för indirekt anslutning?
|
|
|
| Bakgrund Det finns en öppen fråga om hur tekniska komponenter som delas av många organisationer ska registreras i federationen (ex. regioners vårdinformationssystem som nyttjas av många vårdgivare). Behov av villkor för indirekt anslutning: hur indirekta anslutningar ska registreras och vilka organisationer en komponent får företräda. Egenskapsintyg kopplas till tekniska komponenter, inte samverkande parter, vilket skapar friktion när samma komponent används av flera parter. En möjlig inriktning är att kommersiella leverantörer representerar olika kunders användning som separata logiska komponenter; icke-kommersiella kan i vissa fall dela.
| Mål |
|
|
Målbild och berättelsen Frågeställning / beslutspunkter Vilka 3–5 “flaggskeppsscenarier” ska användas för att förklara nyttan och driva anslutning? Vilken målgrupp riktar vi oss till per scenario (kommun, region, myndighet, leverantör)?
|
|
|
| Bakgrund Gemensam målbild/berättelse saknas och scenarier behövs där övergång till SIB beskrivs utifrån ett effektivitets och kostnadsperspektiv Exempel på scenariokategorier: myndighetsrapportering, företagsinriktade tjänster med manuell kontoprovisionering, informationsdelning mellan organisationer. Det finns ett exempel på scenario (kommun ↔ myndigheter) som kan användas som “storyboard”.
| Mål |
|
|
Nationell strategisk plan och politisk förankring Frågeställning Vilka beslutsforum och vilken ordning för förankring (Ena → myndigheter → RK → leverantörer)? Vilka tjänstekategorier ska prioriteras nationellt (rapportering, informationsdelning, samverkan)?
|
|
|
| Bakgrund För att nå önskad nyttoeffekt behövs en politiskt förankrad nationell strategisk plan för vilka tjänster som börjar erbjudas baserat på anslutning till SIB; i nuläget planeras främst för NLL och ambitionen är att fler myndighetstjänster ska baseras på SIB. Föreslagna aktiviteter: kommunikationsmaterial, förankring inom Ena-strukturen, med tongivande myndigheter, RK och IT-leverantörer.
| Mål |
|
|
Efterlevnadskontroll (tillit) – nivå och modell Frågeställning Vilken miniminivå av efterlevnadsmodell ska gälla i SIB (och när krävs högre nivå)? Ska egenskapsintyg användas för att representera efterlevnad – och i så fall hur hanteras “självdeklarerad” vs tredjepartsintygad efterlevnad?
|
|
|
| Bakgrund Det är inte förankrat hur efterlevnadskontroll av organisationers/verksamheters förmågor inom informationssäkerhet ska hanteras. Alternativ spänner från ingen faktisk kontroll till självdeklaration, internrevision eller extern revision; risk måste vägas mot samhällskostnad. Det kan behövas komplettering till juridiskt ansvar i form av ramverk för efterlevnadsredovisning/-kontroll, med hänsyn till organisationstyp och befintliga revisioner och certifieringar.
| Mål Ett riskbaserat, skalbart ramverk för efterlevnad som skapar tillräckligt hög tillit, är praktiskt genomförbart och kostnadseffektivt,
|
|
|
|
|
|
|
|
|
|
|