[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 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: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, 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: 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]