SL3 - and optional processing of shared state

[gffletch]

Given that SL2 allows for the concept of step-up, I think the IDP MUST be able to reset the session to the "base" authentication level within the application. Such that even if the session within the application is currently "stepped-up", that session state will be changes ensuring that the next "high risk" transaction will be forced to step-up again.

The Identity Service communicates changes in the account and device posture to the application, enabling the application to take actions it determines are necessary based on its own policies about these changes. Neither application nor identity services are obliged to act upon any state changes, the policies for responding to state changes are not in scope for SL3.

Maybe the key here is that we need more than a session-termination event that MUST be acted upon, we need a session-downgrade event as well.

[mcguinness]

Can you expand on your use case, its not clear why this isn't just an app's responsibility if the app-specific transaction doesn't meet assurance requirements. Assurance decreases over time so SL2 just enables the app to request an assurance level from the IdP when needed and gives the IdP a chance to enforce its security controls when issuing/renewing a token.