Vi startar ett arbete som sker parallellt och utanför teamets nuvarande kärnuppdrag att jobba mot realisering av MVP ( arbetet sker med resurser utanför teamet - detta är en platshållare). Syftet är att komma igång med att skapa en publicerbar och återanvändbar struktur för attribut inom Samordnad identitet och behörighet, med fokus på att minska “dialekter” och integrationsbörda för e-tjänster. Bakgrunden är de behov som lyfts från samverkande aktörer att komma igång med detta arbete.
Arbetet utgår från fyra attributtyper som först ska definieras och avgränsas. Varje typ bedöms kräva egen diskussion och hantering (t.ex. olika källor, tillitskrav, ansvariga parter och livscykel), för att undvika att allt blandas ihop.
SKR och Internetstiftelsen tar fram ett första utkast (0.1) med förslag på typindelning, en nationell minsta kärna och exempel på domänprofiler/mappning (t.ex. skola och vård). DIGG har för avsikt att stå för format, struktur och publiceringsyta och vara avsändare för normering, men inte ta fram definitionerna annat än det som är helt nationellt.
Status: UTKAST - sida och arbetsyta etableras nu; innehållet är under framtagning och ska återkopplas inom några veckor. Innehållet på denna sida ska betraktas som arbetsutkast som kommer tjäna som underlag för fortsatt diskussion
Inledning
Frågeställningar
Här finns ett antal frågor att besvara innan vi kan detaljera attributramverket.
Ska namnet på attributet spegla källan, till exempel /eid för e-legitimation och /idp för IdP?
OID som attributnamn
Ska vi använda Sweden Connects namn på vissa av attributen vilket i praktiken innebär OID:ar? Ska vi då förutsätta att attributen härrör från e-legitimationen? Det stämmer inte med nuvarande realiseringar som t ex Inera har.
Så här är Sweden Connects namn på ett attribut givenName: urn:oid:2544
Semantik i attributnamnet
Ska namnet på attributet spegla källan, till exempel /eid för e-legitimation och /idp för IdP?
I vissa användningsfall är det viktigt för e-tjänsten som begär attributen att skilja på om attributen kommer från själva e-legitimationen eller från attributkällan. För Ineras IdP så går det att peka ut certifikatets givenName med attributet urn:credential:givenName. Motsvarande attribut som hämtas från katalogen är http://sambi.se/attributes/1/givenName eller urn:oid:2544, beroende på vilken IdP man ansluter till. I det senare fallet finns det ingen metod att peka ut attributet som e-legitimationsspecifikt.
Vissa attribut kan relatera till en anställds organisationstillhörighet eller uppdrag/roll, hur ska e-tjänsten kunna skilja på detta?
Versionshantering av attribut
Ska attributnamnen ha en namnstandard som medger versionshantering enligt mönster från Sambi?
Exempel från Sambi: http://sambi.se/attributes/1/givenName
Om vi använder det i ramverket: https://federationer.se/attribute/1.0/givenName
Fördelar: om ett attribut får en annan betydelse, till exempel en annan värdemängd, behöver vi inte hitta på ett helt nytt namn utan bara byta som i detta fall 1.0 till 2.0. Den praktiska konsekvensen är att det är ett helt nytt attribut som kan leva parallellt med det gamla. Fråga: har detta någonsin använts i Sambi?