SL3 and requiring state changes from App to IdP

[mcguinness]

I noticed for SL3 we have "MUST communicate user, session, and device state changes to the Application" as a requirement for the RP.

I may have missed discussion on the calls but wanted to express some concerns that this is somewhat broad and needs some more constraints to be useful. What is the subset that is needed, for what outcomes, yet not too taxing for the RP (both economically and technically) to provide? Sending events for every user for every session in a RP is not free so there would need to be a clearer customer value prop to drive implementation and infra costs.

I am especially concerned about including device state changes. There isn't a useful device identifier that flows between RP and IdP in a typical browser based SSO flow using existing SSO protocols. The RP and IdP are different origins and as such are subject to the many layers of privacy and origin based security features in browsers. We are hopefully also going to require all native apps to follows best practices and use system browser for SSO which adds further indirection for a "device". Yes there are solutions for interoperable device id for managed devices that are deployed today but these are outside of the scope of the identity protocols used. If we are not going to define new standards I don't think there a simple solution to profiling that would make it possible for a RP to be SL3 complaint.

[aaronpk]

All good questions, the current language is meant to be a placeholder while we figure out these exact details. We'll be focusing on the SL1 and IL1 levels in the working group calls for now, so let's use this thread to keep this discussion moving in the mean time.