...

Syftet är att bidra till en enhetlig, interoperabel och långsiktigt förvaltbar modell som kan användas av kommuner, regioner och nationella aktörer.

Uppdraget omfattar att:

1. Ta fram behörighetsattribut för exemplifierade domäner

Identifiera och definiera ett första urval av behörighetsattribut inom några utvalda domäner. Dessa ska fungera som konkreta exempel och kunna användas för att pröva struktur, semantik och tillämpning.

2. Ta fram en struktur för hur behörighetattribut beskrivs

Utforma en struktur för hur behörighetsattribut ska namnges och beskrivas.  

3. Ta fram en förvaltningsstruktur

Definiera hur behörighetsattribut ska förvaltas över tid, inklusive roller, ansvar och beslutsprocesser. Förvaltningsmodellen ska tydliggöra ägarskap, förändringshantering och samordning mellan berörda aktörer.

4. Ta fram styrande principer

Formulera övergripande principer för användning och hantering av behörighetsattribut.

...

Görans e-tjänstelegitimation är utfärdad av SML-IT, som är gemensam IT-organisation för flera kommuner.
Göran är anställd som bygglovshandläggare i Lysekils kommun och vill logga in i en e-tjänst från Lantmäteriet.

Flera organisatoriska dimensioner (utfärdare, hemvist och uppdrag)

Lars har en e-tjänstelegitimation utfärdad av Höglandets IT-förbund.
Han är anställd på Aneby kommuns miljökontor som livsmedelsinspektör.
För närvarande utför han ett uppdrag åt Jönköpings kommun och har inom ramen för detta genomfört en inspektion. Han ska nu logga in i Livsmedelsverkets e-tjänst.

...

• Koordinerar och utvecklar attribut inom sin domän
• Säkerställer att domänen använder domänoberoende attribut där sådana finns
• Identifierar behov av domänunika attribut
• Beslutar om införande av domänunika attribut inom ramen för sitt mandat

• Säkerställer att domänunika attribut:

  • Följer fastställd namnstandard
  • Beskrivs enligt ledningsaktörens styrning
  • Publiceras enligt fastställd modell

...

• Transportstyrelsen samordnar domänen
• Flera aktörer kan vara ansvariga för enskilda attribut
• Helheten hålls samman genom den gemensamma strukturen

Exempel på domäner

 Styrande attribut

Styrande principer för behörighetsattribut

1. Standardiserad namngivning och identifiering

Attribut ska i första hand utgå från etablerade och registrerade standarder (exempelvis IANA, OID eller motsvarande internationella register).
Nya attribut ska endast definieras när befintliga standarder inte täcker behovet.

2. Selektiv användning

Den gemensamma attributlistan beskriver möjliga attribut.
Vid varje enskilt användningstillfälle ska endast de attribut som är relevanta för ändamålet användas.

3. Uppgiftsminimering

Vid överföring av attribut ska principen om uppgiftsminimering alltid tillämpas.
Endast den information som är nödvändig för det aktuella syftet får delas.

4. Källoberoende attributmodell

Attribut ska definieras oberoende av var informationen hämtas ifrån.
Ett attributvärde kan komma från exempelvis katalogtjänst (IdP), e-legitimation, uppdragsregister eller annan betrodd källa.
Semantiken ska vara densamma oavsett källa.

Principer för arbetets inriktning

1. Standardnära och konfigurerbart

De lösningar och modeller vi tar fram ska vara möjliga att implementera genom konfiguration i etablerade standardprodukter.
Arbetet ska följa internationella standarder och etablerad federationspraxis så att leverantörer inte behöver utveckla särskilda speciallösningar för den svenska marknaden.

2. Design för det normala

Vi designar primärt för det vanligaste användningsfallet. Undantag och specialfall ska identifieras och hanteras separat, utan att göra huvudmodellen onödigt komplex.
Arbetet ska sträva efter en 80/20-balans mellan generalitet och praktisk användbarhet.

Inledning

Frågeställningar

Här finns ett antal frågor att besvara innan vi kan detaljera attributramverket.

• Vem har givit ut e-legitimationen?
• Vem är personens huvudsakliga arbetsgivare?
• Vem är personens uppdragsgivare för den rolll personen agerar i just nu?

Ska namnet på attributet spegla källan, till exempel /eid för e-legitimation och /idp för IdP?

I den överenskommelse som finns mellan regionerna och E-hälsomyndigheten när det gäller den SAML-propageringslösning för åtkomst till NLL har man etablerat en namnstandard för attribut som härrör sig från IdP:n. Ett exempel på detta är https://idp.inera.se/attributes/identityProviderForSign Som man kan se så innehåller attributnamnet referens till en organisation. En mera neutral namngivning på detta attribut kunde vara https://federationer.se/attribute/idp/1.0/identityProviderForSign

...

Så här är Sweden Connects namn på ett attribut givenName: urn:oid:2.5.4.42

Övrig semantik i attributnamnet

Vissa attribut kan relatera till en anställds organisationstillhörighet eller uppdrag/roll, hur ska e-tjänsten kunna skilja på detta? I Ineras fall när det gäller den anställdes HSAid beror det på vilka andra attribut som e-tjänsten begär. Observera skillnaden mellan ett HSAid som är knutet till e-legitimationen och HSA-id som finns i katalogen. I den senare kategorin finns ingen namnsättning som skiljer på organisationstillhörighet och uppdragssituation.

När det gäller domänspecifika attribut inom vård och omsorg finns "health" med i attributnamnet https://id.ena-infrastructure.se/attributes/health/healthcareProfessionalLicenseIdentityNumber bland de attribut som används för åtkomst till NLL och är överenskommet med E-hälsomyndigheten och regionerna.

Versionshantering av attribut

Ska attributnamnen ha en namnstandard som medger versionshantering enligt mönster från Sambi?

...