Definition: Paraply för anslutning: villkor + process/bevisning + hänvisningar till ramverk, anslutningsregler, kravkataloger.
Artefaktkoppling: Villkor för anslutning, anslutningsprocesser, deklarationsmallar samt ev. hantering av åtkomstpolicy.
| Policy | Ställningstaganden och mål som operationaliserar principer. | Anger vad och varför (intention/ram). | Härleder från Princip. Konkretiseras av Regelverk/Krav. Operationaliseras av Process. |
1) Föreslagen artefakt-arkitektur (lager + ansvar)
Tänk “lager” från mest övergripande (policy) till mest specifikt (tekniska profiler):
Anslutningspolicy (SIB-nivå, organisations-/styrningslager)
Normerar: vem som får ansluta, på vilka villkor, och hur anslutning godkänns.
Innehåller inte: tekniska detaljer per protokoll.
Tekniska anslutningsregler per federationskontext (teknikneutral federationsnivå)
Normerar: vad som gäller, vilka gemensamma tekniska krav som gäller i federationskontexten, men uttryckt teknikneutralt (t.ex. “stark autentisering”, “spårbarhet”, “nyckelhantering”, “metadata-kvalitet”).
Innehåller inte: exakta SAML/OIDC-fält eller profilparametrar.
Registreringspolicy (teknikspecifik processnivå)
Normerar: hur en aktör registrerar en teknisk komponent (IdP, OP, SP, RP, API-gateway, attributkälla etc.), vilken evidens som krävs, test/validering, driftsättning, ändringshantering.
Innehåller: teknikberoende krav och flöden (eftersom registreringen skiljer sig mellan SAML och OIDC).
Tekniskt ramverk (teknikspecifik normnivå: standarder + profiler)
Normerar: exakta standarder, profiler, options, “MUST/SHOULD/MAY”, interoperabilitet, samt referens till testprofiler.
Beroende: både teknik och federationskontext
Policyn gäller för anslutning till SIB-federationen inklusive:
anslutning av AO till FO,
anslutning av FM (och deras entiteter) via AO,
publicering, uppdatering, avpublicering och revokering av metadata och trust marks.
...
Policyn reglerar inte bilaterala nyttjandeavtal mellan FM (tjänst-till-tjänst), men kräver att federationens metadata tydligt kan uttrycka avtals-/tillitsförutsättningar via policy/tillitsmarkeringar.2. Policyramverk och harmonisering
Policyn SHALL Policyn ska bestå av tre sammanhängande delar:
A) Anslutningsvillkor (juridik/avtal),
B) Tekniska anslutningsregler,
C) Operativa rutiner (processer för drift/incident/ändring).
2.2. Tekniska anslutningsregler SHALL Tekniska anslutningsregler ska vara verifierbara och knutna till anslutningsavtal (motsvarande Sweden Connect-principen att avtal definierar ansvar/avgifter och tekniska regler beskriver hur anslutningen ska fungera).
Policyn ska säkerställa att en Operatör (FO eller AO) som ansluts till SIB:
kan upprätthålla federationens tillit (trust chain) på operatörsnivå,
kan ansluta och hantera FM enligt separata medlemskrav (FM-policy),
kan genomföra drift, incident, ändring och revokering på ett sätt som skyddar federationen och dess deltagare.
Tekniska krav på Anslutningsoperatör (federationsinfrastruktur)
6.1 Federationsfunktion
Anslutningsoperatören ska:
publicera korrekt federationkonfiguration på avtalad well-known-lösning,
signera och publicera federationuttalanden (entity statements) för underliggande enheter enligt tilldelad roll,
kunna etablera en validerbar tillitskedja mot Federationsoperatören,
kunna tillämpa och vidareföra federationspolicy (t.ex. metadata-begränsningar) enligt Federationsoperatörens kravbild.6.2 Nyckelhantering
Anslutningsoperatören ska:
skydda privata nycklar mot obehörig åtkomst,
ha rutin för nyckelrotation och hantering av kompromettering,
kunna rotera nycklar utan oplanerade avbrott (t.ex. överlappande nycklar),
logga och kunna spåra nyckelrelaterade händelser.
6.3 Tillgänglighet och robusthet
Anslutningsoperatören bör:
dimensionera tjänster för att undvika att Anslutningsoperatören blir en gemensam felpunkt för sina Federationsmedlemmar,
ha backuper, återställningsrutiner och kontinuitetsplanering,
övervaka federationskritiska funktioner (publicering, signering, statuskontroller om tillämpligt).
6.4 Trust marks (om Anslutningsoperatören får delegerad utfärdanderätt)
6.4.1. Om Federationsoperatören delegerar utfärdande av trust marks till Anslutningsoperatören ska delegeringen vara tydligt uttryckt och möjlig att validera.
6.4.2. Anslutningsoperatören ska utfärda trust marks enligt federationspublicerad trust mark-katalog (definition, villkor, giltighet, status/återkallelse).
6.4.3. Anslutningsoperatören ska kunna återkalla trust marks och/eller signalera status enligt överenskommen mekanism (t.ex. status-endpoint eller kort giltighetstid med återutfärdande).
...
Syfte
Detta dokument beskriver hur SIB:s dokumentpaket hänger ihop och var olika typer av krav ska uttryckas. Målet är att undvika dubbelreglering och göra det tydligt vad som styr styrning, krav, process och tekniska detaljer.
Översikt
Lager 1: Styrning och ansvar
Anslutningspolicy – Anslutningsoperatör
Reglerar relationen mellan Federationsoperatör och Anslutningsoperatör: vem som får bli operatör, vilka ansvar som följer, hur uppföljning sker och hur avstängning/återkallelse hanteras.
Anslutningspolicy – Federationsmedlem
Reglerar relationen mellan Anslutningsoperatör och Federationsmedlem: medlemskriterier, åtaganden, efterlevnad, sanktioner och avstängning/återkallelse på medlemsnivå.
Princip: Policys beskriver “vem och varför”, ansvar samt konsekvens vid bristande efterlevnad.
Lager 2: Federationsgemensamma verifierbara krav
Tekniska anslutningsregler – SIB Federation
Fastställer gemensamma minimikrav som måste vara uppfyllda för att federationen ska fungera säkert och interoperabelt. Innehåller krav som går att kontrollera, och pekar vid behov ut vilket tekniskt ramverk/profil som gäller.
Princip: Här står “vad som ska uppfyllas”, inklusive versionsföljsamhet, miljöer, incident- och nyckelkrav.
Lager 3: Process och evidens (hur man gör i praktiken)
Registreringspolicy – OpenID Federation/OIDC (och ev. andra kontexter)
Beskriver hur en teknisk komponent registreras, valideras, driftsätts, uppdateras och avregistreras. Anger vilka artefakter/bevis som krävs och hur kontroller genomförs.
Kärnprincip: Här står “hur man gör”, steg för steg.
Lager 4: Exakta tekniska normer
Tekniskt ramverk – standarder och profiler
Innehåller exakta protokollkrav (profiler, parametrar, endpoints, claims, algoritmer, felhantering) som implementatörer behöver följa.
Kärnprincip: Här står “exakt hur det ska implementeras”.
| draw.io Diagram | ||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Dokumentkarta (”vem pekar på vem”)
Anslutningspolicy – Anslutningsoperatör
pekar på: Tekniska anslutningsregler, Registreringspolicy, Trust mark-katalog
beskriver: ackreditering, ansvar, tillsyn, avstängning/återkallelse av operatör
Anslutningspolicy – Federationsmedlem
pekar på: Tekniska anslutningsregler, Registreringspolicy, Trust mark-katalog
beskriver: medlemskap, åtaganden, sanktioner, avstängning/återkallelse av medlem
Tekniska anslutningsregler – SIB Federation
pekar på: Tekniskt ramverk (profil X/Y), Trust mark-katalog
beskriver: verifierbara minimikrav, miljöer, versionsföljsamhet, säkerhetskrav
Registreringspolicy – OpenID Federation/OIDC
pekar på: Tekniskt ramverk, Tekniska anslutningsregler, Trust mark-katalog
beskriver: registreringsflöden, evidens, validering, publicering, ändring, avregistrering
Tekniskt ramverk – standarder och profiler
refereras av: Tekniska anslutningsregler, Registreringspolicy
beskriver: exakta protokollkrav
Trust mark-katalog
refereras av: båda anslutningspolicys, tekniska anslutningsregler och registreringspolicy
beskriver: tillitsmarkeringars innebörd, governance, utfärdande och status
Praktiska tumregler för att undvika dubbelreglering
Om frågan är ”vem får, vem ansvarar, vad händer om…” lägg i anslutningspolicy.
Om frågan är ”vilka krav måste vara uppfyllda och hur mäter vi det” lägg i tekniska anslutningsregler.
Om frågan är ”hur går det till i onboarding/registrering/ändring” lägg i registreringspolicy.
Om frågan är ”vilka fält/claims/endpoints/algoritmer exakt” lägg i tekniskt ramverk.
Dokumentpaket
Dokument 1: Anslutningspolicy – Anslutningsoperatör (styrning och ansvar)
Syfte: Reglerar relationen mellan Federationsoperatör och Anslutningsoperatör (ackreditering av operatör).
Innehållsförteckning (förslag):
Syfte, omfattning och definitioner
Roller och ansvar (Federationsoperatör ↔ Anslutningsoperatör)
Tillitsstruktur för operatörsled (konsekvenser vid avstängning/återkallelse)
Kriterier för att få bli Anslutningsoperatör (juridik, säkerhet, kapacitet)
Godkännande och återkommande uppföljning (tillsyn/rapportering)
Krav på operativ förmåga (incident, förändring, kontinuitet, kommunikation)
Delegationer (t.ex. utfärdande av trust marks) – principnivå
Avstängning/återkallelse och konsekvenshantering (migrering, kommunikation)
Bilagor och hänvisningar (till tekniska anslutningsregler/ramverk)
Gräns: Inga protokollparametrar. Krav uttrycks som vad operatören ska kunna uppvisa och upprätthålla.
Dokument 2: Anslutningspolicy – Federationsmedlem (styrning och ansvar)
Syfte: Reglerar relationen mellan Anslutningsoperatör och Federationsmedlem (medlemskap och efterlevnad).
Innehållsförteckning (förslag):
Syfte, omfattning och definitioner
Kriterier för medlemskap (juridik, roller, ansvar)
Tillitsstruktur för medlem (konsekvenser vid avstängning/återkallelse)
Medlemsåtaganden (metadataansvar, kontaktvägar, incident, förändring)
Godkännande, uppföljning och sanktioner
Avstängning/återkallelse (medlemsnivå)
Bilagor och hänvisningar
Gräns: Inga tekniska fältlistor—bara åtaganden och efterlevnadsprinciper.
Dokument 3: Tekniska anslutningsregler – SIB Federation (verifierbara minimikrav)
Syfte: Definierar gemensamma, testbara krav som alla parter måste uppfylla för interoperabilitet och säker drift i SIB.
Innehållsförteckning (förslag):
Översikt: mål, tillämpning, miljöer
Gemensamma säkerhetskrav (TLS, nyckelhantering, loggning, tidsstämpling, driftinfo)
Metadata- och identitetskrav (kvalitet, aktualitet, kontaktuppgifter)
Versionsföljsamhet och övergångsregler (tidsfrister, bakåtkompatibilitet)
Krav per roll (Federationsoperatör / Anslutningsoperatör / Federationsmedlem) – utan protokollfält men med tydliga verifieringspunkter
Krav på tillitsstyrning (vilka trust marks/kategorier krävs när, principnivå)
Test, granskning och godkännande (vilka bevis krävs)
Incident- och återkallelsekrav (tekniska effekter och åtgärdstider)
Hänvisningar till tekniskt ramverk och registreringspolicy
Gräns: Här kan det finnas teknikbindning via hänvisning (“för OpenID Federation gäller Ramverk X”), men detaljparametrar ligger i ramverket.
Dokument 4: Registreringspolicy – OpenID Federation/
...
OIDC
Syfte: Beskriver hur registrering/uppdatering/avregistrering går till för federationens tekniska komponenter och metadata.
Innehållsförteckning (förslag):
Roller i registreringsprocessen (vem gör vad)
Onboardingflöde (steg för steg)
Registreringsobjekt (entitetstyper, relationer, kedjor)
Validering och kontroller (automatiska + manuella)
Miljöer: test/sandbox/produktion och flyttregler
Ändringshantering (metadata, endpoints, nycklar, certifikat)
Avpublicering och återkallelse (inkl. trust mark-status)
Loggning, spårbarhet och
...
beslut
Driftinformation och kommunikation
Mallar: checklistor, evidenskrav, tidsfrister
Gräns: Process + kontroller. Här
...
beskrivs “hur man
...
gör”
Dokument 5: Tekniskt ramverk – profiler och interoperabilitet
...
Syfte: Exakta standarder/profiler och parametrar som implementatörer behöver följa.
Innehållsförteckning (förslag):
Refererade standarder och profiler
OpenID Federation-profil (exakta claims, endpointkrav, policy application)
OIDC/OAuth-profil (flöden, response types, tokenkrav, signing/encryption)
Algoritmer, nycklar, tidskrav
Felhantering och säkerhetskrav på protokollnivå
Testprofil/konformitet (testfall, assertions)
Versionering och kompatibilitet
Gräns: Endast tekniska detaljer.