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

På sidan:

Registreringspolicy för tekniska komponenter

Domän: Teknisk interoperabilitet och tillitsetablering
Typ av normativt artefakt: Policy
Status: Utkast
Gäller från: (fastställs vid beslut)
Relaterar till:

• Anslutningspolicy för federationsmedlemmar (förutsättning: organisationen är verifierad och ansluten)

• Tekniska profiler/anslutningsregler (operationaliserar policyn som krav, valideringar och test)

• OIDF Deployment & Interoperability Profile (principer för registreringspolicy och policy-identifierare)

1. Syfte

Denna policy beskriver vad registrering av tekniska komponenter i federationen innebär och varför varje registreringsuppgift (metadata-attribut) finns. Policyn ska göra det möjligt för federationsmedlemmar att förstå vilken tillit de kan lägga i en registrerad komponent och hur komponenten kan användas för automatiserad tillitsetablering.

Policyn tar vid efter att federationsmedlemmen är ansluten enligt anslutningspolicyn (verifierad organisation och behöriga kontaktpersoner) .

Normhierki

1. OpenID Federation 1.0: definierar Entity Statements, trust chains, metadata-ramen och de informational metadata parametrar som bl.a. inkluderar description (alltså exakt den typ av semantik vi vill uttrycka) 

2. Svensk OpenID Federation-profil: preciserar hur (1) ska användas i svensk kontext (t.ex. val av identifierare, roller, constraints, ev. trust marks m.m.)

3. Registreringspolicy för tekniska komponenter anger vad attributen faktiskt signalerar och betyder i detta sammanhang.

2. Vad andra parter kan förutsätta

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

• Komponenten är kopplad till rätt federationsmedlem (juridisk person) via stabil organisationsinformation i metadata.

• Komponentens identifierare och domän är valda så att det finns en rimlig och kontrollerbar koppling mellan komponenten och organisationens domän(er) (motverkar “spoofing” och felregistrering) .

• Metadata-attributens semantik är entydig: samma attribut betyder samma sak oavsett anslutningsoperatör, och används som underlag för maskinell validering/resolution .

• Det finns en identifierbar registreringspolicy som anger vilket regelverk som gällde när komponenten togs in (policy-URI i federationens intyg/uttalanden) .

3. Omfattning och avgränsning

Omfattar:

• Semantik (betydelse) för metadata-attribut som används vid registrering av tekniska komponenter, inklusive organisationsuppgifter, kontaktuppgifter, identifierare, nyckelreferenser och protokollrelaterade metadata.

• Övergripande ställningstaganden om hur metadata ska stödja interoperabilitet och tillit.

Omfattar inte:

• Exakta fältkrav per profil, protokollspecifika detaljkrav, algoritmlistor, endpoint-valideringar eller testfall (det hör hemma i krav/spec/profil) .

• Organisationsverifiering och mandatkedjor för att bli federationsmedlem (det hör hemma i anslutningspolicyn) .

4. Roller och ansvar (policy-nivå)

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

• Federationsoperatör (om rollen finns separat) ansvarar för federationens övergripande tillitsram och publicering av tillitsinfrastruktur.

• Anslutningsoperatör / Registreringsfunktion (Federation Registration Entity) ansvarar för att registrering sker enligt policyn och att policyidentifierare används i federationens uttalanden om entiteter .

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

5. Definitioner

• Teknisk komponent: federationsentitet som registreras och blir upptäckbar via federationens metadata/tillitsinformation (t.ex. OP, RP/klient, AS, resurs/API) .

• Entity Identifier (entity_id / entity_identifier): entydig identifierare (URI) för entiteten i OpenID Federation .

• Entity Configuration: entitetens självdeklaration enligt OpenID Federation (kan vara hostad) .

• Subordinate Statement: federationsuttalande som en överordnad entitet signerar vid registrering och därmed “vittnar” om vissa bindningar (nyckel↔identifierare, medlemskap, kontroller) .

• Registreringspolicy-URI: stabil identifierare som anger vilken registreringspolicy som tillämpats för registreringen .

6. Grundläggande ställningstaganden (vad och varför)

1. Registrering är tillitsskapande, inte bara administration.
   Registrering ska göra det möjligt för andra parter att på maskinell väg avgöra vem som står bakom en komponent och hur den kan användas säkert.

2. Metadata ska vara begriplig och verifierbar.
   Där metadata pekar ut identitet (namn, org-id, domän, kontakt) ska den vara spårbar till federationsmedlemmens verifierade organisationsuppgifter och validerade domän(er) .

3. Deskriptiv metadata fixeras vid registrering; säkerhets- och funktionspolicy koncentreras högre upp.
   Registreringsfunktionen ska främst styra/deskribera sådant som kontrolleras vid registrering (visningsnamn, organisationskoppling). Mer komplexa säkerhets-/funktionsrestriktioner bör ligga i trust anchor-policy för att minska konflikt- och mergeproblem .

4. Policyidentifierare är obligatorisk del av tillit.
   Andra parter ska kunna se vilket regelverk som gällde vid intag av komponenten (t.ex. via registreringspolicy-claim/policy-URI) .

7. Metadata-attribut: betydelse och avsedd tolkning

Detta avsnitt är policykärnan: vad attributen betyder (motsvarande “description” i Sweden Connect-portalen) .

7.1 Identitet och organisationskoppling

entity_id / entity_identifier

• Betyder: Entitetens unika identifierare i federationen (URI).

• Varför: Är primär nyckel för discovery, resolution och signaturbindning i federationens kedjor.

• Tolkning i federationen: Ska vara stabil över tid. Ska representera entiteten på ett sätt som går att koppla till organisationens domän (minskar risk för att någon registrerar en “låtsas-entitet” på någon annans domän) .

organization_identifier

• Betyder: Organisationens identifierare enligt svensk standard (organisationsnummer, 10 siffror).

• Varför: Maskinell koppling mellan teknisk komponent och juridisk person.

• Tolkning i federationen: Avser ansvarig federationsmedlem, inte systemleverantör, driftleverantör eller enskild verksamhetsdel .

organization_name (multilingual)

• Betyder: Organisationens namn som visas i federationen, med språktaggar (t.ex. #sv, #en).

• Varför: Mänsklig begriplighet och spårbarhet i gränssnitt/loggar/revision.

• Tolkning i federationen: Ska spegla den anslutna organisationens namn, inte komponentens produktnamn .

contacts

• Betyder: Kontaktuppgifter (typiskt e-post) till ansvariga kontaktpersoner för komponenten/klienten.

• Varför: Incidenthantering, förändringskommunikation och spårbar förvaltning.

• Tolkning i federationen: Avser federationsmedlemmens utsedda kontaktvägar (administrativ/teknisk), inte enskilda personers privata adresser .

7.2 Visnings- och klientmetadata

client_name (multilingual)

• Betyder: Namn som identifierar komponenten/klienten som OIDC-part.

• Varför: Mänsklig identifiering i verktyg, loggar och UI.

• Tolkning i federationen: Ska vara ett stabilt komponentnamn inom organisationens förvaltning, inte en tillfällig projektetikett .

display_name (multilingual)

• Betyder: Namn som visas för användare (kan auto-genereras från client_name men kan skilja sig).

• Varför: Användarupplevelse, begriplig samtyckes-/inloggningsdialog, minskar social engineering-risk.

• Tolkning i federationen: Ska vara sant och igenkännbart för målgruppen; får inte utformas för att vilseleda om avsändare .

logo_uri

• Betyder: HTTPS-URI till logotyp som representerar komponenten/klienten.

• Varför: UI/igenkänning, minskar risken för felval.

• Tolkning i federationen: Ska representera federationsmedlemmen eller tjänsten, och vara förvaltningsbar över tid .

client_uri, policy_uri, tos_uri

• Betyder: Länkar till webbplats, integritetspolicy och användarvillkor.

• Varför: Transparens, regelefterlevnad, stöd för granskning.

• Tolkning i federationen: Ska peka på innehåll som gäller den registrerade tjänsten/komponenten i den kontext där federationen används .

7.3 Redirect- och request-URIer

redirect_uris

• Betyder: Tillåtna omdirigerings-URIer efter autentisering.

• Varför: Grundläggande säkerhetskontroll i OAuth/OIDC (hindrar kod/token till fel mottagare).

• Tolkning i federationen: Ska representera komponentens faktiska callback-endpoints och ligga under organisationens validerade domän(er) .

request_uris

• Betyder: URIer där Request Objects kan hämtas (Request Object by Reference).

• Varför: Stödjer mer avancerade OIDC-flöden och minskar parameterstorlek i authn-requests.

• Tolkning i federationen: Ska vara förvaltningsbara och kontrollerade av federationsmedlemmen, och får inte användas som “dynamiskt innehållsintag” utan kontroll .

7.4 Autentisering, token och nycklar

token_endpoint_auth_method

• Betyder: Klientens metod för autentisering mot token-endpoint.

• Varför: Avgör säkerhetsnivå och vilka nyckel-/hemlighetskrav som gäller.

• Tolkning i federationen: Ska väljas enligt gällande svensk OIDC-profil (i Sweden Connect-kontext är private_key_jwt central) .

token_endpoint_auth_signing_alg

• Betyder: Algoritm som används för klientautentisering (t.ex. vid private_key_jwt).

• Varför: Interoperabilitet och säkerhet (tillåtna/otillåtna algoritmer styrs i profil/krav).

• Tolkning i federationen: Är en del av komponentens säkerhetskonfiguration och ska vara konsistent med profilkrav .

response_types, grant_types, scope

• Betyder: Vilka OAuth/OIDC-flöden och rättigheter klienten avser använda.

• Varför: Underlättar interoperabel konfiguration och validering.

• Tolkning i federationen: Ska uttrycka teknisk kompatibilitet. Ska inte tolkas som verksamhetsbeslut om åtkomst, utan som protokollförmåga .

id_token_signed_response_alg, userinfo_signed_response_alg

• Betyder: Signeringsalgoritmer för ID Token respektive UserInfo-svar.

• Varför: Interoperabilitet och säkerhet.

• Tolkning i federationen: Är säkerhetsparametrar som ska vara förenliga med profil och policy. Restriktioner operationaliseras som krav, inte här .

jwks_uri / jwks

• Betyder: Var klientens publika nycklar finns (URI) eller inbäddad JWK Set.

• Varför: Nyckelmaterial behövs för signaturvalidering och klientautentisering.

• Tolkning i federationen: Nyckelreferenser ska vara långsiktigt förvaltningsbara och kopplade till entiteten. Val av jwks vs jwks_uri är en implementeringsdetalj inom profilkrav .

7.5 Federation-specifika uppgifter (OpenID Federation)

Entity Configuration (inkl. ev. ec_location)

• Betyder: Entitetens självdeklarerade federation- och rollmetadata, publicerad på standardplats eller via hosting-mekanism.

• Varför: Är startpunkten för federationens trust chain och metadata resolution.

• Tolkning i federationen: Om hosting används måste domän-/ägarskap vara kontrollerbart, eftersom annars kan någon peka om sin entitet till en annan kontrollpunkt .

Subordinate Statement (från registreringsentiteten)

• Betyder: Registreringsentitetens signerade uttalande som binder ihop entitet, nyckel och medlemskap samt kan fixera vissa deskriptiva värden.

• Varför: Gör att federationens deltagare kan lita på att registrering skett enligt definierad process.

• Tolkning i federationen: Ska primärt “vittna” om sådant som faktiskt kontrollerats vid registrering (organisationskoppling, namn, domänbindning, policy-identifierare) .

registration_policy (policy-URI)

• Betyder: Identifierar vilken registreringspolicy som tillämpades.

• Varför: Transparens och maskinell/administrativ möjlighet att avgöra vilka kontroller som låg bakom ett registreringsbeslut.

• Tolkning i federationen: Ska vara stabil över tid och versionshanteras på ett sätt som gör det möjligt att förstå historik .

8. Livscykelprinciper (policy-nivå)

• Nyregistrering: avser att skapa en ny federationsentitet med initial “baseline”-metadata.

• Uppdatering: avser ändring av metadata där semantiken är densamma men värden kan uppdateras (t.ex. nya endpoints/nycklar/contacts).

• Avregistrering/återkallelse: avser att komponenten inte längre ska vara tillitsbar/upptäckbar i federationen och att tillitskedjor ska brytas på ett kontrollerat sätt .

• Spårbarhet: varje registreringsbeslut ska kunna knytas till ärende/beslutsdatum och tillämpad policyversion .

9. Avgränsning mot krav och process

Denna policy konkretiseras av:

• Krav/specifikationer (exakta obligatoriska fält, valideringsregler, algoritmkrav, testkrav)

• Process/rutin hos anslutningsoperatören (hur registreringsärenden initieras, granskas, beslutas, publiceras, följs upp)

10. Revision och uppföljning (policy-nivå)

Federationen ska kunna begära underlag som visar att:

• registreringspolicy-URI användes vid registrering,

• komponentens organisationskoppling och domänkoppling var kontrollerbar,

• och att metadata-attributen som publicerats följer denna policys semantik.
  (Detaljerade stickprovsmekanismer och sanktionstrappor ligger i kompletterande regelverk/krav) .

. Vad från Anslutningspolicy för federationsmedlemmar som används av Registreringspolicy för tekniska komponenter

Utifrån anslutningspolicyn framgår att den inte reglerar registrering av tekniska komponenter, utan att detta hanteras i Registreringspolicy för teknisk komponent (avgränsning/scope).

Anslutningspolicy för federatio…

Samtidigt beskriver anslutningspolicyn vilka förutsättningar som andra parter kan lita på – och dessa är det som registreringspolicyn för tekniska komponenter typiskt bygger vidare på.

Anslutningspolicy för federatio…

Följande delar från anslutningspolicyn är direkt “input”/förutsättningar som registreringspolicyn behöver återanvända:

A. Verifierad organisationsidentitet (juridisk person)

• Organisationens existens och organisationsnummer verifieras mot relevant nationell registerkälla (ex. Bolagsverket).

  Anslutningspolicy för federatio…

  
  Användning i registreringspolicy (teknisk komponent):

• Låser komponentregistrering till en verifierad juridisk part.

• Blir grund för att sätta/validera fält som motsvarar “organisationsidentitet” i komponentens/federationsentitetens metadata (t.ex. organization_name, ev. organization_identifier/orgnr), och för att säkerställa spårbar koppling mellan metadata och juridisk part.

B. Behörig företrädare och avtalstecknande (mandat)

• Avtalstecknare identifieras med stark identifiering och mandat/behörighetsgrund verifieras och dokumenteras (firmateckning, delegation, fullmakt, etc.).

  Anslutningspolicy för federatio…

  
  Användning i registreringspolicy:

• Skapar den juridiska tillitspunkten: att organisationen faktiskt är federationsmedlem, vilket krävs för att organisationen ska få registrera komponenter/entiteter.

• Ger grund för regler om vem som får initiera/attestera “ny komponent”, “nyckelbyte”, “ändring av endpoints”, etc.

C. Kvalificerade kontaktpersoner med delegation för teknisk registrering

• Policyn kräver att federationsmedlemmen utser relevanta kontaktpersoner och att delegation/fullmakt finns om kontaktpersonen ska få utföra åtgärder i federationens system (t.ex. registrera tekniska komponenter).

  Anslutningspolicy för federatio…

  
  Användning i registreringspolicy:

• Styr åtkomsträtt i registreringsflödet: vem får registrera och uppdatera tekniska komponenter/metadata.

• Underlag för krav på contacts i metadata (och att dessa ska vara spårbart utsedda/behöriga).

D. Spårbarhet, dokumentationskrav och arkivering

• Operatören ska dokumentera och arkivera bevis/underlag, logga utförda kontroller (vem, vad, när, källor, resultat), samt lagra dokumentation under medlemskap + viss tid.

  Anslutningspolicy för federatio…

  
  Användning i registreringspolicy:

• Registrering/ändringar av tekniska komponenter måste vara revisionsbara: koppla varje registreringshändelse till verifierad kontaktperson/roll, beslut, underlag.

• Underlag för policykrav kring “change management” (nyckelrullning, endpointändringar, avregistrering).

E. Löpande re-verifiering och händelsestyrd uppföljning

• Årlig re-verifiering och triggers (t.ex. ändrad firmatecknare, fusion, konkurs, etc.).

  Anslutningspolicy för federatio…

  
  Användning i registreringspolicy:

• Om organisationen inte kan re-verifieras: påverkar förtroende/aktivering av organisationens tekniska komponenter (t.ex. karantän/avstängning av metadata, spärr av nycklar, etc.).

• Underlag för regler om när komponentmetadata måste uppdateras (t.ex. vid domänbyte/omorganisation).

Sammanfattande: Anslutningspolicyn etablerar “vem är organisationen och vem får företräda den”, medan registreringspolicyn kan fokusera på “vilka tekniska entiteter får organisationen publicera och hur säkras korrekthet över tid”. Det uttrycks också i anslutningspolicyn att organisationsverifieringen “ligger till grund” för verifiering kopplat till komponenter via registreringspolicyn.

Anslutningspolicy för federatio…

2. Ersätt “Sweden Connect metadata” med metadata relevant för OpenID Federation (inkl. Trust Marks)

I Sweden Connect metadata portal-underlaget beskrivs idag ett formulär-/metadataupplägg som i praktiken motsvarar OIDC-klientmetadata + vissa federationsrelaterade fält och med stark betoning på att fältnamn ska följa OIDC/OIDF-specifikationernas attributnamn.

Sweden Connect metadata portal_…

För att “ersätta Sweden Connect metadata” med OpenID Federation-relevant metadata (med fokus på OIDF och trust marks) bör man utgå från att det som registreras/publiceras är en Entity Configuration (en self-signed Entity Statement JWT) med dessa centrala delar:

A. Federation-lagret: Entity Statement / Entity Configuration (top-level claims)

OpenID Federation definierar claim-set för Entity Statements (t.ex. iss, sub, iat, exp, jwks, metadata) och att authority_hints är REQUIRED för leaf/intermediate (dvs alla som har en superior) och får inte vara tom.
metadata måste finnas för de Entity Types entiteten deltar i (t.ex. openid_relying_party).

B. Trust Marks: trust_marks + (för Trust Anchors) trust_mark_issuers/trust_mark_owners

OpenID Federation definierar trust_marks som en array av objekt med trust_mark_type och trust_mark (JWT).
Trust Anchor kan publicera trust_mark_issuers och trust_mark_owners för att styra/tydliggöra vilka utfärdare/ägare som är betrodda per trust mark-typ.

Den svenska profilen (utkast) anger dessutom att resolver-funktionen kan behöva hantera trust marks, inklusive att en resolver kan inkludera trust marks som inte ligger i entitetens egen konfiguration genom kommunikation med Trust Mark Issuer.
Notera: Själva avsnittet “Trust Marks” i profilen är i detta utkast i praktiken ett TODO-block, men det pekar på områden som måste beslutas (kortlivade vs långlivade trust marks, validering, namngivning, m.m.).

C. Svensk profil: rollseparation och att leaf/protokollentiteter inte ska bära federation_entity metadata

Profilen ställer krav att man inte kombinerar Federation Service-roller (Trust Anchor/Intermediate/Resolver/TMI) med protokollroller (OP/RP/Client/etc) under samma Entity Identifier, och att Federation Protocol Entity därmed är leaf och dess Entity Configuration inte ska innehålla federation_entity-metadata.

D. Registration Entity och “vad som intygas”

Profilen beskriver att en Federation Registration Entity (Immediate Superior) registrerar genom att skapa/signera Subordinate Statement, och att detta “vouching” bl.a. omfattar:

• bindningen mellan federationsnyckel och Entity Identifier,

• att innehavaren är legitim representant för Entity Identifier,

• att entiteten är legitim medlem i federationen.

Det är här kopplingen till anslutningspolicyn blir praktisk: anslutningspolicyns organisationsverifiering och delegationskontroller är det som gör att registreringsentiteten kan “vouch:a” på ett meningsfullt sätt.

3. Tabellutkast i samma format som Sweden Connect metadata (för OpenID Federation + Trust Marks)

Nedan är ett första utkast där jag använder samma kolumner som i portal-underlaget (Attribute, Type, Required, Description, Validation, Specification).
Jag har valt dot-notation för att tydliggöra var ett fält hör hemma (top-level i Entity Statement vs under metadata.openid_relying_party).

3.1 Entity Configuration 

Attribute	Type	Required	Description	Validation (svensk profil)
iss	String (URI)	Yes	Utfärdare av entity statement. För en entity configuration är detta entitetens entity identifier och den som signerar statementet.	HTTPS-URI. För self-signed entity configuration ska iss vara identisk med sub.
sub	String (URI)	Yes	Subjektet för entity statement; entitetens entity identifier i federationen.	HTTPS-URI. Ska motsvara entitetens identifierare.
iat	Number	Yes	Tidpunkt då entity statement utfärdades.	Unix-tid (sekunder).
exp	Number	Yes	Sista giltighetstid för entity statement.	Unix-tid (sekunder). Måste vara senare än iat. Bör sättas så att caching fungerar men att ändringar ändå kan slå igenom inom rimlig tid (profilen betonar operativa konsekvenser av för kort/lång giltighet).
jwks	Object (JWKS)	Yes	Publika federationsnycklar som används för att verifiera signaturer på entity statements (federation entity keys).	Endast publika nycklar. keys-array krävs. Varje nyckel ska ha unikt kid. Nyckeluppsättningen ska vara stabil nog för federationens cache-/resolverbeteende.
authority_hints	String[] (URI)	Yes (för Federation Protocol Entities)	Pekar ut entitetens immediate superior(s) som entiteten registrerats under. Används för att bygga tillitskedja.	I svensk profil är en Federation Protocol Entity alltid en leaf entity (p.g.a. rollseparation), och ska därför normalt alltid ha authority_hints (ej tom). Varje värde ska vara HTTPS-URI.
trust_anchor_hints	String[] (URI)	No	Extra hint om vilka trust anchors som är relevanta för entiteten.	Om angiven: får inte vara tom. HTTPS-URI. Bör endast användas om federationen kräver explicit förankring utöver normal kedjebyggnad via authority_hints.
metadata	Object	Yes (för Protocol Entities)	Metadata per entity type (t.ex. RP/OP/AS/Client/Resource). Anger protokollrollens kapabiliteter och preferenser.	Rollseparation: En Federation Protocol Entity ska inte inkludera metadata av typen federation_entity. Endast protokollrollernas metadata ska förekomma (t.ex. openid_relying_party, openid_provider, etc.).
trust_marks	Object[]	No	Trust marks som entiteten presenterar. Kan användas som kontrollmekanism i federationen.	Varje objekt ska innehålla trust_mark_type och trust_mark (JWT). Validering och eventuellt komplettering via resolver kan vara en del av federationens driftmodell; konsumtionsparter bör inte anta att avsaknad i entity configuration alltid betyder “saknas i federationens resolve”.

3.2 Trust Marks (struktur)

3.3 Metadata för openid_relying_party (exempel på RP/client-metadata inom federation)

Not: Ovan RP-tabell är avsiktligt kort (utkast). Portal-underlaget innehåller en mer komplett uppsättning OIDC client metadata-fält (redirect_uris, request_uris, token_endpoint_auth_method, response_types, grant_types, alg-val etc.).
För “ersättning till OpenID Federation” är den centrala skillnaden att dessa fält uttrycks som metadata.<entity_type>.<param> och att federation-lagret (Entity Statement claims + trust marks) tillkommer.

Om du vill att jag ska göra nästa iteration utan att vara “kort” i RP-metadata-delen kan jag ta hela fältlistan från portal-underlaget och:

• flytta den till metadata.openid_relying_party.*,

• lägga till federation-claims (authority_hints, fed

  Sweden Connect metadata portal_…

  st_marks`),

• samt rensa bort Sweden Connect-/Swedish OIDC Profile-specifika valideringar och ersätta med OpenID Federation-referenser och policy-hookar (Trust Anchor/Registration Policy).

Sweden Connect metadata portal_…

Sweden Connect metadata portal_…

Sweden Connect metadata portal_…

Sweden Connect metadata portal_…