RE: [saml-dev] the value of AuthnInstant

["Scott Cantor" <cantor.2@osu.edu>]

> I would say that if an IdP does not retain enough state to produce an
> AuthnStatement that is internally consistent (i.e., all the content
> describes the same authentication event) then, in fact, it's not
compliant.
> Thus, if an IdP does not preserve the time that the user presented his
> password, it cannot claim Password AC after the first AuthnStatement, and
> must henceforth use ExistingSession as the AC.

That's fine. I'm simply pointing out (again) that SAML 1.1 had no such Authn
Method defined in the spec and implementations did behave in the way you
think is non-compliant. In other words, the meaning of the timestamp was
deployment-specific.
 
Since there's rarely been any mention of that ExistingSession AC class, it
struck me as odd that one could argue SAML 2.0 changed this constraint
without changing any of the relevant language in the spec to at least note
that, hey, now we can do this because we have an Authn Method (class) that
makes the difference clear.

So as Tom says, I think this is an errata.
 
-- Scott