Nedan är operativa tumregler för att avgöra var ett krav eller en regel hör hemma i din artefakt-arkitektur. De är formulerade som beslutskriterier och gränsdragningar för att minimera överlapp och normkonflikter.

1. Grundprincip: Fråga dig “Vad normeras egentligen?”

När du formulerar ett krav – avgör först om det normerar:

• Villkor för att delta → Anslutningspolicy

• Egenskaper/förmågor som krävs i federationen → Tekniska anslutningsregler

• Process för att få in en komponent → Registreringspolicy

• Exakt teknisk implementation → Tekniskt ramverk

Det är alltid objektet för normeringen som styr placeringen.

2. Tumregler per lager

A. Anslutningspolicy (styrningslager)

Lägg här när:

• Kravet gäller organisationen som aktör

• Kravet kan uppfyllas utan att du vet vilken teknik som används

• Kravet är kopplat till avtal, ansvar eller sanktion

• Kravet är av typen “måste ha förmåga att…”

Typiska formuleringar:

• “Aktören ska…”

• “Anslutning får ske om…”

• “Aktören ansvarar för…”

• “Vid bristande efterlevnad kan…”

Lägg inte här:

• Krav på algoritmer, claims, attributformat

• Testfall

• Konfigurationsdetaljer

• Metadatafält

Snabbtest:

Om du kan byta ut “SAML/OIDC” mot “valfri teknik” utan att texten påverkas → då hör det hit.

B. Tekniska anslutningsregler (teknikneutral federationsnivå)

Lägg här när:

• Kravet beskriver vilken egenskaper federationer/komponenter måste ha

• Kravet gäller alla tekniker i federationskontexten

• Kravet uttrycks som säkerhets- eller interoperabilitetsnivå

• Du kan formulera det utan att nämna ett protokoll

Typiska formuleringar:

• “Autentisering ska uppnå minst nivå X.”

• “Kryptografiskt skydd ska säkerställa…”

• “Metadata ska vara korrekt och aktuell.”

• “Spårbarhet ska möjliggöra…”

Lägg inte här:

• “ID Token ska innehålla…”

• “Assertion ska signeras med…”

• Endpoint-URL-format

• Claim-namn

Snabbtest:

Om du behöver nämna ett specifikt protokollelement → då är du på väg ner i ramverket.

C. Registreringspolicy (process + teknik)

Lägg här när:

• Kravet beskriver hur en komponent tas in i federationen

• Det rör ansökningsförfarande, verifiering, test, godkännande

• Det är kopplat till förändringshantering

• Det är kopplat till evidenskrav

Typiska formuleringar:

• “För registrering ska följande lämnas in…”

• “Före produktionssättning ska…”

• “Vid ändring av nyckelmaterial ska…”

Lägg inte här:

• Generella säkerhetsprinciper

• Federationsövergripande krav

• Protokollspecifika MUST/SHOULD-detaljer (de hör hemma i ramverket)

Snabbtest:

Om kravet upphör att vara relevant efter att komponenten är godkänd → då hör det sannolikt hit.

D. Tekniskt ramverk (normativ teknisk specifikation)

Lägg här när:

• Kravet är testbart på protokollnivå

• Du använder MUST/SHOULD/MAY

• Du refererar till RFC/OASIS-specifikationer

• Det påverkar interoperabilitet direkt

Typiska formuleringar:

• “ID Token MUST be signed using…”

• “Assertion SHALL contain…”

• “Clients MUST support…”

• “Metadata SHALL include…”

Lägg inte här:

• Avtalsvillkor

• Sanktioner

• Organisationskrav

• Allmänna säkerhetsprinciper utan teknisk konkretisering

3. Beslutsträd (snabbklassificering)

1. Gäller kravet organisationens rätt eller ansvar att delta?
   → Anslutningspolicy

2. Gäller det vilken säkerhets-/interoperabilitetsegenskap federationen ska ha?
   → Tekniska anslutningsregler

3. Gäller det hur en komponent tas in, testas eller ändras?
   → Registreringspolicy

4. Gäller det exakt hur protokollet ska implementeras?
   → Tekniskt ramverk

4. Överlapp – så undviker du dem

Regel: Uppåt är princip, nedåt är konkretisering

• Policy säger att

• Regler säger vad

• Registrering säger hur processen går till

• Ramverk säger exakt hur tekniken ska bete sig

Om ett dokument börjar svara på en fråga som hör hemma i ett annat lager → du är på väg att skapa normkonflikt.

5. Konfliktregel (väldigt viktig i normhierarki)

Om två dokument verkar säga olika saker:

1. Tekniskt ramverk konkretiserar – det får inte motsäga högre nivå.

2. Registreringspolicy får inte skapa nya materiella krav som saknar stöd i regler eller ramverk.

3. Tekniska anslutningsregler får inte smyga in avtalskrav.

4. Anslutningspolicy får inte smyga in tekniska implementationer.

6. Praktiska exempel

7. Mental modell: Fyra olika målgrupper

Detta är ofta den tydligaste distinktionen:

Om fel målgrupp måste läsa dokumentet för att förstå det – då är något felplacerat.

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.

Princip: 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.

Princip: Här står “exakt hur det ska implementeras”.

Dokumentkarta (”vem pekar på vem”)

1. Anslutningspolicy – Anslutningsoperatör

   • pekar på: Tekniska anslutningsregler, Registreringspolicy

   • beskriver: ackreditering, ansvar, tillsyn, avstängning/återkallelse av operatör

2. Anslutningspolicy – Federationsmedlem

   • pekar på: Tekniska anslutningsregler, Registreringspolicy, 

   • beskriver: medlemskap, åtaganden, sanktioner, avstängning/återkallelse av medlem

3. Tekniska anslutningsregler – SIB Federation

   • pekar på: Tekniskt ramverk (profil X/Y), 

   • beskriver: verifierbara minimikrav, miljöer, versionsföljsamhet, säkerhetskrav

4. Registreringspolicy – OpenID Federation/OIDC

   • pekar på: Tekniskt ramverk, Tekniska anslutningsregler, 

   • beskriver: registreringsflöden, evidens, validering, publicering, ändring, avregistrering

5. Tekniskt ramverk – standarder och profiler

   • refereras av: Tekniska anslutningsregler, Registreringspolicy

   • beskriver: exakta protokollkrav

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 tekniska funktionella krav som 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):

1. Syfte, omfattning och definitioner

2. Roller och ansvar (Federationsoperatör ↔ Anslutningsoperatör)

3. Tillitsstruktur för operatörsled (konsekvenser vid avstängning/återkallelse)

4. Kriterier för att få bli Anslutningsoperatör (juridik, säkerhet, kapacitet)

5. Godkännande och återkommande uppföljning (tillsyn/rapportering)

6. Krav på operativ förmåga (incident, förändring, kontinuitet, kommunikation)

7. Delegationer (t.ex. utfärdande av trust marks) – principnivå

8. Avstängning/återkallelse och konsekvenshantering (migrering, kommunikation)

9. Bilagor och hänvisningar (till tekniska anslutningsregler/ramverk)

Dokument 2: Anslutningspolicy – Federationsmedlem (styrning och ansvar)

Syfte: Reglerar relationen mellan Anslutningsoperatör och Federationsmedlem (medlemskap och efterlevnad).
Innehållsförteckning (förslag):

1. Syfte, omfattning och definitioner

2. Kriterier för medlemskap (juridik, roller, ansvar)

3. Tillitsstruktur för medlem (konsekvenser vid avstängning/återkallelse)

4. Medlemsåtaganden (metadataansvar, kontaktvägar, incident, förändring)

5. Godkännande, uppföljning och sanktioner

6. Avstängning/återkallelse (medlemsnivå)

7. 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):

1. Översikt: mål, tillämpning, miljöer

2. Gemensamma säkerhetskrav (TLS, nyckelhantering, loggning, tidsstämpling, driftinfo)

3. Metadata- och identitetskrav (kvalitet, aktualitet, kontaktuppgifter)

4. Versionsföljsamhet och övergångsregler (tidsfrister, bakåtkompatibilitet)

5. Krav per roll (Federationsoperatör / Anslutningsoperatör / Federationsmedlem) – utan protokollfält men med tydliga verifieringspunkter

6. Krav på tillitsstyrning (vilka trust marks/kategorier krävs när, principnivå)

7. Test, granskning och godkännande (vilka bevis krävs)

8. Incident- och återkallelsekrav (tekniska effekter och åtgärdstider)

9. 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):

1. Roller i registreringsprocessen (vem gör vad)

2. Onboardingflöde (steg för steg)

3. Registreringsobjekt (entitetstyper, relationer, kedjor)

4. Validering och kontroller (automatiska + manuella)

5. Miljöer: test/sandbox/produktion och flyttregler

6. Ändringshantering (metadata, endpoints, nycklar, certifikat)

7. Avpublicering och återkallelse (inkl. trust mark-status)

8. Loggning, spårbarhet och beslut 

9. Driftinformation och kommunikation

10. 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):

1. Refererade standarder och profiler

2. OpenID Federation-profil (exakta claims, endpointkrav, policy application)

3. OIDC/OAuth-profil (flöden, response types, tokenkrav, signing/encryption)

4. Algoritmer, nycklar, tidskrav

5. Felhantering och säkerhetskrav på protokollnivå

6. Testprofil/konformitet (testfall, assertions)

7. Versionering och kompatibilitet

Gräns: Endast tekniska detaljer.

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 ska bestå av tre sammanhängande delar:
A) Anslutningsvillkor (juridik/avtal),
B) Tekniska anslutningsregler,
C) Operativa rutiner (processer för drift/incident/ändring).

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.

-----------------------------utkast 20260220-------------------------

1. Syfte

Denna policy beskriver vad registrering av tekniska komponenter i federationen innebär och vilken betydelse (semantik) registrerade metadata-attribut har. Policyn ska skapa en gemensam förståelse för vilken tillit som kan läggas i registrerade uppgifter samt hur dessa används för automatiserad tillitsetablering, interoperabilitet och säker drift.

Policyn tar vid efter att en organisation är ansluten som federationsmedlem enligt anslutningspolicy (verifierad organisation och behöriga kontaktpersoner).

2. Styrande ramverk

Policyn bygger på OpenID Federation och den svenska profilen för OpenID Federation. Dessa anger den tekniska modellen för entity statements, trust chains, metadata per entity type och (i förekommande fall) trust marks. Denna policy preciserar hur metadata ska förstås, vilka tillitsantaganden som ska gälla och vilka minimikrav som behöver vara uppfyllda för att en registrering ska vara meningsfull och maskinellt användbar.

3. Vad andra parter kan förutsätta

När en teknisk komponent är registrerad enligt denna policy kan andra parter förutsätta att:

• Komponenten är knuten till en federationsmedlem (juridisk person) genom stabila organisationsuppgifter i metadata.

• Identifierare och domänval ger en kontrollerbar koppling mellan komponent och organisationens domän(er), för att minska risk för felregistrering och vilseledande identiteter.

• Metadata-attributen har en definierad semantik som kan användas för maskinell validering och resolution i federationen.

• Registreringen hänvisar till en identifierbar registreringspolicy (policy-URI) som anger vilket regelverk som gällde vid registreringstillfället och vid uppdateringar.

4. Omfattning och avgränsning

4.1 Omfattar

• Semantik för metadata-attribut vid registrering av tekniska komponenter: identitet, organisation, kontakt, nycklar, endpoints och protokollrelaterad metadata.

• Grundprinciper för hur metadata används för interoperabilitet och tillit inom ramen för OpenID Federation och svensk profil.

• Registreringslivscykel på policynivå (nyregistrering, uppdatering, avregistrering) med fokus på spårbarhet.

4.2 Omfattar inte

• Exakta fältkrav per profil, algoritmlistor, testfall eller detaljerade tekniska valideringsregler (hanteras i krav/spec/profil).

• Organisationsverifiering och mandatkedjor för medlemskap (hanteras i anslutningspolicy).

• Driftinstruktioner för resolver, cache och federationstjänster (hanteras i operativa dokument).

5. Roller och ansvar

• Ledningsaktör: fastställer policyn och kan initiera uppföljning/revision av efterlevnad.

• Federationsoperatör: ansvarar för federationens tillitsinfrastruktur och publicering av federationens gemensamma resurser (om rollen är separerad).

• Registreringsfunktion (Federation Registration Entity): ansvarar för att registrering sker enligt policyn, att policyidentifierare används och att tillitsartefakter publiceras.

• Federationsmedlem: ansvarar för att lämnad metadata är korrekt, aktuell och att förändringar hanteras enligt federationens processer.

6. Definitioner

• Teknisk komponent: federationsentitet som registreras och publiceras för upptäckt och tillit inom federationen, t.ex. OpenID Provider, Relying Party/Client, Authorization Server, Resource.

• Entity Identifier: entydig URI som identifierar en entitet i federationen.

• Entity Configuration: entitetens självdeklaration som utgör startpunkt för trust chain och metadata resolution.

• Subordinate Statement: uttalande signerat av entitetens överordnade registreringsfunktion som intygar bindningar och kontroller vid registrering.

• Registreringspolicy-URI: stabil identifierare som anger vilken version av registreringspolicy som tillämpats.

7. Grundläggande ställningstaganden

1. Registrering är tillitsskapande och ska möjliggöra maskinell bedömning av vem som står bakom en komponent, vilka nycklar som hör till entiteten och hur komponenten ska användas säkert och interoperabelt.

2. Metadata ska vara begriplig och verifierbar. Identitetspekande metadata (namn, org-id, domän, kontakt) ska vara spårbar till federationsmedlemmen.

3. Registreringspolicy-URI är en central del av tilliten: andra parter ska kunna förstå vilket regelverk som gällde vid intaget och vid senare ändringar.

4. Svensk profil tillämpas med rollseparation: federation service-roller och protokollroller ska inte blandas under samma entity identifier för protokollentiteter.

8. Registreringsobjekt och policyartefakter

Registrering av en teknisk komponent ska resultera i följande artefakter:

1. Entity Configuration som kan hämtas och valideras.

2. Subordinate Statement utfärdat av registreringsfunktionen, som binder ihop entiteten, dess federationsnycklar och dess medlemskap samt kan fixera eller stärka utvalda metadata.

3. Registreringspolicy-URI som gör policyn spårbar vid resolution och vid revision.

9. Registreringsprocess (policy-nivå)

9.1 Nyregistrering

Nyregistrering innebär att en ny entitet skapas med initial baseline-metadata. Registreringsfunktionen ska säkerställa att:

• organisationskoppling är etablerad,

• domänkoppling är rimlig och kontrollerbar,

• entity configuration kan valideras,

• subordinate statement kan utfärdas,

• registreringspolicy-URI kopplas till registreringen.

9.2 Uppdatering

Uppdatering innebär ändring av metadata för en befintlig entitet. Principer:

• Uppdateringar ska vara spårbara (vem, vad, när, varför).

• Nyckelbyte och endpointändringar ska hanteras kontrollerat.

• Uppdateringar kan kräva ny attest eller ny kontroll beroende på ändringens säkerhetspåverkan.

• Tillämplig policyversion ska vara tydlig (antingen kvarvarande version om policyn ej ändras, eller ny version om policyn uppdaterats och tillämpas).

9.3 Avregistrering och återkallelse

Avregistrering innebär att entiteten inte längre ska vara tillitsbar/upptäckbar. Principer:

• Avregistrering ska kunna ske kontrollerat vid avslutat medlemskap eller vid säkerhetsincident.

• Federationens tillitskedjor ska brytas eller markera entiteten som icke giltig på ett sätt som är konsekvent för relying parter.

10. Spårbarhet, transparens och bevisbarhet

• Registreringsbeslut ska kunna knytas till ärende/beslutsdatum och tillämpad policyversion.

• Federationens parter ska kunna skilja på vad som intygats av registreringsfunktionen (subordinate statement) och vad som är självdeklarerat (entity configuration).

• Underlag för kritiska bindningar (organisation↔entitet, domän↔identifierare, nycklar↔entitet) ska kunna redovisas vid revision.

11. Revision och uppföljning

• Efterlevnad kan följas upp genom stickprov, incidentuppföljning och granskning av publicerade artefakter.

• Vid brister kan federationen kräva korrigering, begränsa tillit eller avregistrera komponenten enligt federationens styrmodell.

Bilagor – Metadata-tabeller per entity type (portalformat)

Bilaga A – Entity Configuration (top-level claims) – svensk profil

Bilaga B – Trust Marks (generisk struktur)

Bilaga C – Gemensam organisations- och kontaktmetadata

Dessa fält bör finnas för samtliga protokollentiteter (OP, RP/Client, AS, Resource) för att stödja spårbarhet och mänsklig validering.

Bilaga D – Entity type: OpenID Relying Party / Client (metadata.openid_relying_party.*)

Bilaga E – Entity type: OpenID Provider (metadata.openid_provider.*)

Bilaga F – Entity type: OAuth Authorization Server (metadata.oauth_authorization_server.*)

Används för AS som inte nödvändigtvis är en OpenID Provider (ren OAuth AS), eller där man vill uttrycka OAuth AS-metadata separat.

Bilaga G – Entity type: OAuth Protected Resource (metadata.oauth_resource.*)

Avser resurs/API som skyddas av OAuth (Resource Server) och som kan beskrivas maskinellt för interoperabilitet.

Bilaga H – Minimiregler för semantik och kvalitet (gäller alla entity types)

H.1 Identifierare och domänkoppling

• Entity identifier och kritiska URI-fält ska vara valda så att koppling till federationsmedlemmens domän(er) är rimlig och kontrollerbar.

• URI:er ska vara långsiktigt förvaltningsbara och inte peka på innehåll/endpoints som kan bytas ut på ett sätt som skapar vilseledande beteende.

H.2 Nycklar och livscykel

• Federationsnycklar (i entity configuration) och protokollnycklar (i entity type metadata, t.ex. jwks_uri) ska kunna roteras på ett kontrollerat sätt.

• Nyckelbyte ska vara spårbart och hanteras som säkerhetskänslig ändring.

H.3 Kontakter och incidentförmåga

• Kontakter ska vara bemannade och kunna hantera incidenter, nyckelbyten och metadataändringar.

• Vid incident ska federationen kunna nå ansvarig part utan dröjsmål.

H.4 Rollseparation (svensk profil)

• Protokollentiteter ska vara leaf entities och får inte blandas med federation service-roller under samma entity identifier.

• Protokollentiteters entity configuration ska inte innehålla federation service-metadata (federation_entity).

Bilaga I – Mall för “registreringsbeslut” (spårbarhet)