OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

saml-dev message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: RE: [saml-dev] the value of AuthnInstant

I think you're mixing apples and oranges.  Yes, a cookie could be
some form of authentication.  However, if the IdP says in the AC that
user presented username/password, then the AuthnInstant has to be when
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. 


> -----Original Message-----
> From: Scott Cantor [mailto:cantor.2@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,
> > 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
> 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
> > 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
> 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
> to
> remember the original time, it's not compliant?
> > Core says that AuthnInstant is the time at which the
> > took place, not the time when the assertion was issued.  So, I would
> that
> > this does violate the spirit of the setting.
> Not unless we define authentication differently than the glossary does
> just read it to verify that).
> > I think it is pretty clear as it is, so I don't think it needs a
> > but I disagree with this reasoning.   Knowing when something is
> > and being able to point to specific statements in the spec make it
> > easier for the SP, when they are doing their homework, to get the
> > 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
> it's intentionally vague precisely because of this issue, dating back
> 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: saml-dev-unsubscribe@lists.oasis-open.org
> For additional commands, e-mail: saml-dev-help@lists.oasis-open.org

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]