...
--------------------------------Tankar och noteringar--------------------------------
Krav
anslutningsoperatör ska endast utfärda Subordinate Statement efter genomförd verifiering enligt avsnittet “Verifiering och granskning”.
anslutningsoperatör ska dokumentera vilka kontroller som utförts och vilket beslutsdatum som gäller för utfärdandet.
anslutningsoperatör ska inkludera policy-identifierare så att andra parter kan förstå vilket regelverk som gällde vid intag
Federationsmedlem
Federationsmedlem är en organisation som ansluter en eller flera tekniska komponenter till federationen och nyttjar federationens tillitsinformation för samverkan. Federationsmedlemmar förutsätts ingå avtal med anslutningsoperatör för att kunna placera komponenter i federationen.
Krav
Federationsmedlem ska utse både administrativ och teknisk kontaktperson med mandat att initiera och godkänna registreringsärenden för organisationens komponenter.
Federationsmedlem ska säkerställa att inlämnad metadata/tillitsinformation är korrekt, aktuell och att ändringar hanteras enligt denna policy. Återstår att beskriva
Teknisk komponent
Med teknisk komponent avses i denna policy en federationsentitet som federationsmedlem ansluter och som ska kunna upptäckas och valideras genom federationens metadata/tillitsinformation. Exempel på komponenttyper (ej uttömmande):
legitimeringstjänst/OP,
förlitande part/RP,
auktorisationstjänst/AS,
resurs/API (RS) och API-klient,
attribut-/informationskälla??,
andra federationsprotokollentiteter enligt gällande tekniska profiler.
Förutsättningar för ansökan
För att en ansökan ska handläggas ska följande förutsättningar vara uppfyllda:
Krav
Federationsmedlem ska ha ett giltigt anslutningsavtal med anslutningsoperatör innan komponentregistrering påbörjas.
Federationsmedlem ska kunna styrka att ansökande person har mandat att företräda organisationen i registreringsärendet här blir det nån koppling till anslutingspolicy
Komponentens avsedda produktionsmiljö ska vara definierad (t.ex. prod/test/utbildning) och kunna särskiljas i registreringsunderlaget.
Teknisk metadata/tillitsinfo som krävs för registrering
För registrering ska följande lämnas in:
Komponentens Entity Identifier (ID) samt angiven komponenttyp/roller?: vilka roller stöds i federationen?.
Länk/åtkomstväg till komponentens Entity Configuration (som komponenten själv publicerar?).
Komponentens federationsnyckelmaterial (publika nycklar via Entity Configuration eller annat?).
Uppgifter om driftmiljö: test/produktion,
Uppgifter om relevanta endpoints/åtkomstpunkter enligt tekniska profiler
Uppgift om vilka överordnade federationsentiteter som ska kunna utfärda Subordinate Statement
Om Trust Marks används: vilka Trust Mark-typer som krävs och hur de ska tillhandahållas
Komponentnamn och intern komponent‑ID hos federationsmedlem.
Referens till godkända testresultat och datum.
Referens till ansökningsärende-ID, och ansvarig beslutsfattare hos federationsmedlem.
Krav
För registrering ska federationsmedlem tillhandahålla åtkomst till komponentens Entity Configuration så att anslutningsoperatören kan validera den före godkännande.
För registrering ska federationsmedlem ange vilka planerade produktionsendpoints som gäller, samt från vilken dag/tid de ska anses aktiva (aktiveringstidpunkt).
Kontaktvägar för incident/förvaltning
För registrering ska följande lämnas in:
Incidentkontakt (24/7 eller definierad beredskap): e‑post, telefon, eskaleringsnivåer.
Förvaltningskontakt: kanal för planerade ändringar (t.ex. ärendeportal), och kanal för akuta ändringar.
Beskrivning av hur anslutningsoperatören ska nå federationsmedlem vid kritiska avvikelser (t.ex. nyckelkompromettering, felpublicerad metadata).
Anslutningsoperatören ska koppla varje registrering till ett unikt ärende-ID och spara vilken policy-URI och vilken beslutsversion som tillämpades.
Federationsmedlem ska vid senare ändringar kunna hänvisa till senaste godkända baseline (versionsinfo) och uppge vad som ändrats.
Krav
Federationsmedlem ska kunna initiera akut ändringsärende (t.ex. nyckelkompromettering) via någon form av ingång och ange åtgärdsplan.
Anslutningsoperatören ska ha dokumenterad rutin för hur incidentkontakt används för att kunna avregistrera/stoppa komponent vid behov
Draft av dokumentsdisposition
Registreringspolicy (RP) – Rubriknivå med scope
...
- Koppling till anslutnignspolicy/avtal?
...
- Villkor för organisatorisk koppling, behörigföreträdare
- Metadataregler
- Teknisk metadata - organisationnr, orgnamn, entity_id, nycklar mm
Reglerar struktur, innehåll och validering av metadata. Anger obligatoriska element såsom organisationsinformation, endpoints, certifikat och UI-information. - Egenskapsintyg
7. Tillitsidentifierare och entitetskategorier
Fastställer hur tillitsnivåer och entitetskategorier ska deklareras i metadata. Reglerar kopplingen mellan godkänd tillitsnivå och tillåtna identifierare.
...
Registreringspolicy för tekniska komponenter
Normhierki
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)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.)
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)
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.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) .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 .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)
...
.