RE: [saml-dev] the value of AuthnInstant I agree with Conor here. The AuthnInstant has to be specific to the act of authentication being described by the rest of the AuthnStatement, not whatever time value the IdP happens to have access to/feels like putting in. Otherwise, it seems to me that it's of no use at all to a recipient of the Statement. If the spec's intent is to be considerate of IdPs that don't save details of the original user authentication context, then AuthnInstant should be optional, not arbitrary in value.

::Ari


> -----Original Message-----
> From: Cahill, Conor P [mailto:eomqp.l.cwyrpv@intel.com]
> Sent: Monday, February 11, 2008 4:21 PM
> To: Scott Cantor; Tom Scavo
> Cc: SAML Developers
> Subject: RE: [saml-dev] the value of AuthnInstant
> 
> 
> I think you're mixing apples and oranges.  Yes, a cookie could be
> considered
> some form of authentication.  However, if the IdP says in the AC that
> the
> user presented username/password, then the AuthnInstant has to be when
> that
> took place, not when some session cookie was presented to the IdP.   
> 
> So, yes, if I have an AuthnContext that says "Got a cookie", then the
> AuthnInstant can match the IssueInstant. 
> 
> Conor
> 
> > -----Original Message-----
> > From: Scott Cantor [mailto:bqbvdn.6@osu.edu]
> > Sent: Monday, February 11, 2008 4:06 PM
> > To: Cahill, Conor P; 'Tom Scavo'
> > Cc: 'SAML Developers'
> > Subject: RE: [saml-dev] the value of AuthnInstant
> > 
> > > 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.
> > 
> > If authentication doesn't imply the user is involved, then that's no
> > different than use of a cookie (relative strength aside). 
> And in fact
> the
> > AC
> > spec includes a context class for "existing session". What's it for?
> > 
> > > 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.
> > 
> > A bearer token is a form of authentication, and a cookie is a bearer
> > token.
> > But if an IdP decides to implement itself without retaining enough
> state
> > to
> > remember the original time, it's not compliant?
> > 
> > > 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.
> > 
> > Not unless we define authentication differently than the 
> glossary does
> (I
> > just read it to verify that).
> > 
> > > 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.
> > 
> > That hasn't been my experience , but either way I think the spec is
> not at
> > all clear, which is why I don't think it requires this behavior. I
> think
> > it's intentionally vague precisely because of this issue, 
> dating back
> to
> > SAML 1.
> > 
> > (In fact, I brought it up on any number of occasions back 
> then and was
> > told
> > that it was up to the implementer.)
> > 
> > -- Scott
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: zwui-opc-itsxkbbpazw@lists.oasis-open.org
> > For additional commands, e-mail: rnzp-zqv-xvvk@lists.oasis-open.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: zwui-opc-itsxkbbpazw@lists.oasis-open.org
> For additional commands, e-mail: rnzp-zqv-xvvk@lists.oasis-open.org
> 
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: zwui-opc-itsxkbbpazw@lists.oasis-open.org
For additional commands, e-mail: rnzp-zqv-xvvk@lists.oasis-open.org



