...

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

Korta, obekväma men viktiga observationer (så ni slipper upptäcka dem i remissrunda)

...

Er nuvarande “registreringspolicy v15” är till stor del process/disposition och lämnar precis det ni efterfrågar här (semantik/“description”) som ett hål . Den här texten fyller det hålet, men ni behöver fortfarande skilja policy från kravprofil så att ni inte råkar stoppa valideringsregler i fel dokument.

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)

...