RE: [saml-dev] the value of AuthnInstant

["Cahill, Conor P" <conor.p.cahill@intel.com>]

> To use one perhaps contrived example, using a certificate is prone to
> caching a user's PIN. So what's the right timestamp? The last time
they
> entered a PIN? Or every time the key is silently reused?

Contrived, yes.  I presume the certificate was presented to the IdP, so
I
would count any time the *IdP* walks through an authentication sequence
as being an authentication event that would/could impact the 
AuthnInstant.

The case that Tom brought up did not walk through a new authentication 
sequence at the IdP, but rather used the existing "session" with 
the user.  It's pretty clear that AuthnInstant shouldn't be updated
in that case and should have the value from the original authentication
event.

> 
> > For instance, consider an IdP that routinely sets IssueInstant and
> > AuthnInstant to the same value (NOW).  Is this implementation
broken?
> 
> Not IMHO. It certainly doesn't violate the spec as it stands now, at
least
> in core.

Core says that AuthnInstant is the time at which the *authentication*
took
place, not the time when the assertion was issued.  So, I would say that
this does violate the spirit of the setting.

> One reason I'd be against changing this is that I don't think it would
> help.
> Knowing that it's illegal to do something doesn't help an SP when the
IdP
> gets it wrong, and I think a lot would get it wrong. I think it's
better
> to
> be clear that the SP should do its homework before relying on the
value.

I think it is pretty clear as it is, so I don't think it needs a change,
but I disagree with this reasoning.   Knowing when something is illegal
and being able to point to specific statements in the spec make it much
easier for the SP, when they are doing their homework, to get the right
expected behavior.

Conor