...

...

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 etablering av förtroenderelatione som baseras på registrerade uppgifter, 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.

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.

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 uppslag och validering och 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).

• Anslutningsoperatör: ansvarar för registrering och ändringshantering av anslutningar enligt policyn, inklusive att policyidentifierare används, att nödvändiga kontroller genomförs samt att metadataunderlag (t.ex. certifikat, nyckelmaterial och andra uppgifter som används för validering.

• 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 uppslagning av metadata i federationen.

• Subordinate Statement: uttalande signerat av den Anslutningsoperatör som är överordnad entiteten och ansvarar för dess registrering, vilket intygar bindningar och genomförda kontroller.

• 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 Anslutningsoperatören, 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. Anslutningsoperatören 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 förlitande 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 Anslutningsoperatören genom sin 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.

På sidan:

...

Registreringspolicy för tekniska komponenter

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 etablering av förtroenderelatione som baseras på registrerade uppgifter, interoperabilitet och säker drift.

Policyn tar vid efter att en organisation är ansluten som federationsmedlem enligt anslutningspolicy för federationsmedlemmar (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.

Normhierki

1. OpenID Federation 1.0: definierar Entity Statements, trust chains och metadata-ramen, inklusive presentationsuppgifter (i standarden: Informational Metadata Parameters) såsom description, dvs. den typ av standardiserad betydelse (semantik) som denna policy bygger vidare på.

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.

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.

• För att motverka felregistrering och vilseledande identiteter ska Entity Identifier och domänval ge en verifierbar koppling till federationsmedlemmens domän(er). Federationsmedlemmen ska ha och kunna styrka kontroll över domänen. Domänval eller identifierare som antyder tillhörighet till annan organisation får inte användas.

• Metadata-attributen har en definierad semantik som kan användas för maskinell uppslag och validering och 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).

• Anslutningsoperatör: ansvarar för registrering och ändringshantering av anslutningar enligt policyn, inklusive att policyidentifierare används, att nödvändiga kontroller genomförs samt att metadataunderlag (t.ex. certifikat, nyckelmaterial och andra uppgifter som används för validering.

• 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 uppslagning av metadata i federationen.

• Subordinate Statement: uttalande signerat av den Anslutningsoperatör som är överordnad entiteten och ansvarar för dess registrering, vilket intygar bindningar och genomförda kontroller.

• 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

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

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

2. Subordinate Statement utfärdat av Anslutningsoperatören, 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

9.1 Nyregistrering

Nyregistrering innebär att en ny entitet skapas. Anslutningsoperatören 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. (Kanske är en del av subordinate statement men den kanske inte finns i specen och då ska den läggas till eller tas bort. )

9.2 Uppdatering

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

Principer:

• Uppdatering innebär ändring av metadata för en befintlig entitet. 
• Uppdateringar ska vara spårbara och journalföras med minst: ärende-ID, begärande part, beslutsfattare/godkännare, tidpunkt, ändringsbeskrivning och motivering (vem, vad, när, varför).
• Uppdateringar ska initieras och godkännas av behöriga roller enligt federationens ansvarsfördelning och attestkrav.
• Uppdateringar ska riskbedömas. Ändringar som påverkar tillit eller trafikflöden ska kräva ny kontroll och/eller ny attest (t.ex. organisationstillhörighet, domänkoppling, nycklar, endpoints, policykopplingar).
• Nyckelbyte ska hanteras genom dokumenterad nyckelhantering: verifiering att nycklarna hör till entiteten, spårbar nyckelregistrering/rotation och, när tillämpligt, kontrollerad överlappning så att förlitande parter kan validera under övergången.
• Endpointändringar ska verifieras mot domänkontroll och policykrav (t.ex. HTTPS, korrekt värdnamn, ingen förväxlingsbar/vilseledande domän) och vid behov föregås av teknisk kontroll.
• Tillämplig policyversion ska framgå: oförändrad version om policyn inte ändrats, eller ny version om uppdaterad policy tillämpas på entiteten.

9.3 Avregistrering och återkallelse

Principer:

• Avregistrering/återkallelse ska kunna initieras vid avslutat medlemskap, på begäran av federationsmedlem, eller vid säkerhetsincident.

• Avregistrering/återkallelse ska vara spårbar och journalföras med minst: ärende-ID, beslutsdatum, beslutsfattare och grund (orsak/incident/beslut).

• Avregistrering/återkallelse ska ge entydig teknisk effekt för förlitande parter. Entiteten ska antingen tas bort från publicerade resurser eller markeras som ogiltig på ett sätt som kan tolkas maskinellt och konsekvent.

• Federationens publicerade underlag ska uppdateras så att förlitande parter inte längre kan etablera tillit för entiteten, t.ex. genom att tillitskedjan bryts eller leder till ett “ogiltig” utfall.

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 Anslutningsoperatören genom sin 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.  Med kritiska bindningar menas kopplingar som måste vara korrekta för att federationens tillit och säkerhet ska hålla. 

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.

----------------------------------SLUT-----------------------------

Nedan bilagor ska ses som stödmaterial och inte som en del av 0.1 versionen ovan. 

...

Bilagor – Metadata-tabeller per entity type (portalformat)

...

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 H – Minimiregler för semantik och kvalitet (gäller alla entity types)

...

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.

...

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.

...

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.

...

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

...