...
Den andra frågan är hur e-tjänsten vill kontrollera att inloggningen sker med ett SITHS-kort med tillräckligt hög tillitsnivå. Gör man det genom att evaluera utställd biljett och därmed sköta behörighetsstyrningen själv eller vill man att IdP:n ska rapportera misslyckad inloggning genom att i anropet till IdP:n (AuthRequest→ RequestedAuthnContext) ange vilken/vilka LoA-nivåer som e-tjänsten kräver för en lyckad inloggning?
Varje 1. Varje förvaltning av en e-tjänst ansluten till IdP ombeds att se över ifall de anger LoA-nivå i sitt AuthRequest och fundera på om detta fungerar med e-tjänstens krav på LoA-nivå när reservkort och gamla SITHS-kort börjar att rapporteras som LoA 2 enligt tabellen nedan.
Observera att ifall en SP till exempel accepterar både LoA 2 och LoA 3 och vill ange detta i sitt AuthnRequest så måste båda skickas med då IdP endast har stöd för exakt jämförelse av tillitsnivå (detta då SAMBI ställer det som tekniskt krav).
2. Varje förvaltning av en e-tjänst ansluten till IdP ombeds att se över ifall de begär attributet (urn:sambi:names:attribute:levelOfAssurance) för LoA-nivå i SAML/JWT-biljetten och fundera på om detta attribut evalueras av e-tjänsten och om detta i sådana fall fungerar med e-tjänstens krav på LoA-nivå när reservkort och gamla SITHS-kort börjar att rapporteras som LoA 2 enligt tabellen nedan.
Se även avsnittet om Tillitsnivå (LoA) i Guide till IdP
...