What I'm saying is you can implement the functionality of the parameter -- i.e., arbitrary data that survives a round-trip through a SAML login -- without literally using RelayState.
For example, the ID of a SAML `AuthnRequest` always gets echoed back to you in the SAML `Response`. So you can use that as an opaque identifier. You store ID/state pairs in the database when you start SAML logins, and look them back up when the assertion comes back to you. Basically, that's what we do on behalf of our customers.
It's a bit more work for us to implement, but it gives SSOReady customers the "deeplinking" functionality without the weird caveats that RelayState carries.
For example, the ID of a SAML `AuthnRequest` always gets echoed back to you in the SAML `Response`. So you can use that as an opaque identifier. You store ID/state pairs in the database when you start SAML logins, and look them back up when the assertion comes back to you. Basically, that's what we do on behalf of our customers.
It's a bit more work for us to implement, but it gives SSOReady customers the "deeplinking" functionality without the weird caveats that RelayState carries.