OpenSAML user discussion

["Scott Cantor" <>]

> Not knowing any better, I'd assumed that the "conditions" 
> could be iteratively validated in a generalized manner (such 
> as with TSIK's validateConditions) and that an arbitrary 
> NotOnOrAfter could be set, but it seems that the bounding 
> condition is config.clock_skew_secs rather than NotOnOrAfter 
> -- what is the reasoning behind basing expiration on 
> IssueInstant rather than simply NotOnOrAfter?

Because the assertion has to be short lived, and I don't trust the IdP to do
the right thing. Ensuring freshness protects the SP, so I treat it as an
invariant condition. Note that this is explicitly permitted at line 814 of
bindings+profiles. I suppose it could be made an option, but I didn't see
any compelling reason to leave it up to the IdP.

-- Scott