...

1. 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.

2. 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.

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

4. 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

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:

• Rätt att delta → Anslutningspolicy

• Egenskaper 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 egenskap federationen 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

Snabbtest:

Om kravet kan verifieras med ett tekniskt testverktyg → det hör hit.

...

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.

...

Vill du att jag även formulerar 5–7 designprinciper som kan fungera som övergripande arkitekturprinciper för hela normstrukturen (t.ex. teknikneutralitet, minsta möjliga normering, spårbarhet, testbarhet, separering av styrning och implementation)?

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.

...