Another query out of left field: extending the session timeout indefinitely for E911 VOIP service

[Cantor, Scott]

> I saw nothing about a 24H timeout, e.g., in idp.properties I have the default
> # Inactivity timeout
> #idp.session.timeout = PT60M
> Elsewhere there are no references to a 24H timeout.

That would suggest their relying party is the thing with the 24H limit. And if they can't change it, then the question becomes how you'd expect the IdP to just never prompt you again if that's the case. It's not the IdP's job to make an SP session last a crazy long time because doing that would either apply to more than one SP or would push a whole lot of complexity back on the IdP.

One of the main jobs of an IdP operator is stopping people from passing the buck IMHO.

> OK -- periodic re-authentication of say phones without user intervention. 
> SAML does this, or some specific feature within the SAML specification, such as
> ECP?

Neither, that's not a standards issue, that's a "how are you doing authentication?" issue. If you want authentication without intervention, then you're going to have to implement a token-based authentication mechanism I guess.

But I suppose one could argue that a "cookie" is such a thing, in which case....you can configure it to reuse a particular authentication result as long as you want it to.

Alternatively, you proxy out to an IdP that does something we don't and you drop the IdP session out of the middle.

> The fact is I don't know exactly what I mean. This is partly because I've been
> dropped in the middle of someone's experiment.

Yes, I understand.

From my perspective, this is more about somebody pushing a solution, not somebody trying to solve a problem by understanding the root cause.

I will grant that we do not support a token-based authentication solution in a formal sense, but that's basically because every time I inch down that road, I come back to "that just sounds like a cookie and we already do that, that's SSO". It's just not as "managed" a solution as, maybe, OAuth would be, but to be fair, we also have the feature now to actually revoke sessions that would come with such an approach, we just didn't wrap it in a bunch of JSON and over-complicate it.

It's not impossible to create some sort of weird hybrid model where the IdP issues a token to itself that gets stored off, but that's a whole lot of extra hoops to recreate a cookie.

-- Scott