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

> 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

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
> 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

(In fact, I brought it up on any number of occasions back then and was told
that it was up to the implementer.)

-- Scott

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