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