Diskussionspunkt - Aktörer, roller och avtal

En kommun med behov av behov av integration med E-hälsomyndigheten realiserar denna integration med en tjänst från CGI.

1. Klienten (kommunens verksamhetssystem) nyttjar en tjänst från CGI för att hantera utgivning och hantering av egenutgivna klientcertifikat, samt skapande och verifiering av systems identitetshandlingar i form av privat key JWTer.
2. CGI:s integrationstjänst begär också åtkomst till EHM:s API å klientens räkning och returnerar åtkomstintyget till klienten
3. Klienten anropar EHM:s digitala tjänst

Utestående frågor:

1. Vilka avtal behöver tecknas mellan vilka parter?
   1. GDPR PuB-avtal
      1. Kommun → CGI
      2. Kommun ↔ EHM
   2. SIB federationsavtal
      1. Kommun – via Inera → Digg (verksamhetssystemet som klient)
      2. CGI – via Internetstiftelsen → Digg (integrationstjänsten som klient)
      3. EHM – som överenskommelse mellan myndigheter då dessa har samma huvudman → Digg (åtkomstintygstjänst och API)
   3. EHM tjänsteavtal?
      1. Kommun → EHM

Vilka leverabler bifogas till vilka avtal?

Aktörskvalificering

Tillitsramverk

Tillitsramverket reglerar summan av tillitsskapande villkor som ska uppfyllas. Villkoren "aktiveras" av en medlems engagemang inom federationen, d.v.s. när en teknisk komponent av en viss typ ansluts regleras villkoren med automatik för komponenten, verksamheten som ansvarar för och handhar komponenten, samt den juridiskt ansvariga organisationen.

Exempelskrivning:

Om och när du som medlem i federationen Samordnad identitet och behörighet ansluter en teknisk komponent behöver du som medlem säkerställa att kraven i Tillitsramverk - Bas ((referens: Kravkatalog och Ena tillitsmärken) uppfylls. Vilka krav som är tillämpliga styrs av tillitsramverkets definition av en komponentens förmågor. Villkoren kan träffa ansvarig organisation som helhet, den verksamhet inom organisationen som ansvarar för komponenten, och/eller komponenten själv.

Samordnad identitet och behörighet förbehåller sig rätten att ensidigt revidera krav årligen. Detta görs för att kunna bibehålla en stabil tilllitsskapande grund över tid i en föränderlig värld avseende informationssäkerhets- och cybersäkerhetsläge.

Tekniskt ramverk

De tekniska komponenter du som medlem ansluter till federationen Samordnad identitet och behörighet ska vara följsam gentemot Samordnad identitets tekniska ramverk för de integrationer 

Incidenthantering

...

Föreslagen artefakt-arkitektur (lager + ansvar)

Tänk “lager” från mest övergripande (policy) till mest specifikt (tekniska profiler):

1. Aktörskvalificering och avtalsvillkor (Infrastrukturnivå, organisations-/styrningslager)

   • Normerar: vem som får ansluta, på vilka villkor, och hur anslutning godkänns.

   • Innehåller inte: tekniska detaljer per protokoll.

   • Operatörer
     • Vilka organisationer får bli,
       • Federationsoperatör
       • Anslutningsoperatör
       • Egenskapsintygsutfärdare
     • Vilka villkor ska gälla för deras verksamhet
       • Betrodd part - inte möjligt för vem som helst att ansöka om att bli operatör
       •  Måste för att få verka i rollen acceptera att bli tillitsgranskad 
         • inför initial etablering
         • återkommande (årlig?) självdeklarerad villkorsuppfyllnad
         • riskbaserade stickkontroller
       • ...
   • Medlemmar
     • Vilka organisationer får ansluta,
       • OP/AS
       • RP/Api
     • Vilka villkor ska gälla för deras verksamhet

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.

  • Operatörer
    • Vilka villkor ska gälla för de tekniska komponenter som de tillhandhåller
  • Federationmedlemmar
    • Vilka villkor ska gälla för de tekniska komponenter som de tillhandhåller

Registreringspolicy vid anslutning av teknisk komponent

• • • • Normerar: processen för hur en operatör registrerar en aktörs tekniska 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).

      • Organisationsidentifierare
      • Fastställande av företrädare 
      • Registrering av grundläggande metadata
      • Eventuell utfärdande av egenskapsintyg?
      • Operatörer
        • Verifiering av teknisk interoperabilitet
      • Federationmedlemmar
        • Krav på teknisk interoperabilitet
        • Hantering av avvikelser och uppföljning av åtgärdsplaner

Policy för tilldelning av egenskapsintyg/egenskapsintygsutfärdartjänst

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

----------------------------------

1) Föreslagen artefakt-arkitektur (lager + ansvar)

Tänk “lager” från mest övergripande (policy) till mest specifikt (tekniska profiler):

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.

Ö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),

...

1. Syfte

Denna anslutningspolicy fastställer villkor och krav för att en organisation ska kunna anslutas som Federationsmedlem i SIB via en Anslutningsoperatör. Policyn ska:

• säkerställa att Federationsmedlemmar uppfyller federationsgemensamma krav,

• reglera ansvar och skyldigheter mellan Anslutningsoperatör och Federationsmedlem,

• beskriva principer för anslutning, uppföljning, avstängning och återkallelse på medlemsnivå.

2. Omfattning och avgränsning

2.1. Policyn omfattar:

• medlemskriterier och åtaganden,

• ansvar för metadata, nycklar, incident och förändring,

• principer för registrering, publicering och avpublicering,

• principer för avstängning/återkallelse på medlemsnivå.

...

• detaljerade protokollparametrar och fält (Tekniskt ramverk),

• detaljerade registreringssteg och valideringsregler (Registreringspolicy),

• ackreditering av Anslutningsoperatör (se separat policy).

4. Definitioner

• Federationsmedlem: organisation som ansluter via Anslutningsoperatör och publicerar/driver entiteter/komponenter i federationskontext.

• Anslutningsoperatör: organisation som ansluter och hanterar Federationsmedlemmar och deras livscykel.

• Federationsoperatör: organisation som styr federationen på övergripande nivå.

5. Tillitsstruktur för Federationsmedlem

5.1. Federationsmedlem ansluts under Anslutningsoperatörens tillitskedja.

...

• Avstängning eller återkallelse av Federationsmedlem påverkar normalt endast Federationsmedlemmen och dess entiteter.

6. Kriterier för medlemskap

För att godkännas som Federationsmedlem ska organisationen:

1. kunna ingå avtal med Anslutningsoperatör,

2. ha utsedda kontaktfunktioner för teknik, säkerhet och verksamhet,

3. kunna uppfylla tillämpliga krav i Tekniska anslutningsregler,

4. implementera relevanta krav i Tekniskt ramverk för den entitetstyp som ansluts,

5. genomgå registrering och validering enligt Registreringspolicy.

7. Åtaganden för Federationsmedlem

Federationsmedlemmen ska:

• säkerställa att publicerad information och metadata är korrekt, aktuell och spårbar,

• skydda kryptonycklar och tillämpa nyckelrotation samt hantera kompromettering,

• följa krav på loggning och spårbarhet enligt Tekniska anslutningsregler,

• använda rätt miljöer och inte använda produktionsdata i testmiljö,

• följa incident- och ändringsrutiner och informera Anslutningsoperatör vid händelser som kan påverka tillit eller interoperabilitet,

• medverka i omprövning och uppföljning när detta krävs.

8. Avtal och villkor mellan Anslutningsoperatör och Federationsmedlem

8.1. Federationsmedlemmen ska ha ett undertecknat anslutningsavtal med Anslutningsoperatör innan produktionsanslutning.

...

• ansvarsfördelning, kontaktvägar och rapporteringskrav,

• villkor för publicering, uppdatering och avpublicering,

• villkor för avstängning/återkallelse och rättelsefrister,

• incidenthantering och samverkan,

• uppföljning och möjlighet till kontroll.

9. Anslutnings- och registreringsprocess (principnivå)

9.1. Anslutningsoperatören prövar ansökan baserat på:

...

• avtal är tecknat,

• registrering/validering är genomförd,

• entiteter/komponenter är publicerade enligt Registreringspolicy.

10. Uppföljning, omprövning och rättelse

10.1. Anslutningsoperatören får:

...

• åtgärda avvikelser inom överenskommen tid,

• vid behov tillfälligt begränsa funktion eller avpublicera för att minska risk.

11. Avstängning och återkallelse av Federationsmedlem

11.1. Anslutningsoperatören kan besluta om avstängning eller återkallelse om:

...

• genomföra teknisk avpublicering/ogiltigförklaring enligt Registreringspolicy,

• dokumentera beslut och kommunicera till Federationsmedlemmen,

• informera Federationsoperatören vid väsentliga händelser enligt överenskommen rutin.

12. Bilagor och hänvisningar

• x

• y

• z

• Tekniska anslutningsregler – SIB Federation

• Registreringspolicy – OpenID Federation/OIDC

• Tekniskt ramverk – standarder och profiler

Eventuella checklistor och evidensmallar (publiceras separat)