RE: [saml-dev] the value of AuthnInstant

["Scott Cantor" <cantor.2@osu.edu>]

> I understand that that's what you were *told*.   I, however, don't see
> that flexibility in what was written in the spec (at least not what's in
> there now).

When it comes to SSO and cookies, the general SAML attitude was don't ask,
don't tell. Nobody wanted to talk about what was *really* happening in
implementations (look at that "intersite-transfer-service"), so it was all
left out of scope. This was just part of that general attitude. I didn't
agree with it.

> There doesn't appear to be any ambiguity in the wording in the spec
> as it currently stands to me.  If there is, I'd like someone to point
> out where it says that the AuthnInstant is allowed to be something other
> than when the *authentication* of the user took place.

I understand the viewpoint that the AuthnMethod should only be set to what
you can back up, but again, there was NO method defined for "cookie" in 1.1.
The attitude was that you did your best and that was that.

If this is changed because of that AC class, then I just think the spec can
say so. (Particularly in the SSO profile.)
 
> I certainly have no problems with an errata directed at such ambiguity.
> However, I don't see it and I don't think we should have an errata for
> what people said or discussed outside of the spec, especially if that
> was in conflict with the current wording of the spec.

This isn't the first time somebody has felt the spec was unclear and others
thought it was completely clear. (Usually I'm the one who thinks it's
clear.)

In this case, I happen to also think the wording is clear...it just happens
to conflict with the interpretation of the same text that came before it,
and that's why I think something should be changed. It's a self-inflicted
problem.

> In any case, those who want to do an errata, I'd like to hear/see what
> the proposed changes would be.

I would call out in the SSO profile that the AuthnInstant MUST reflect the
time at which the asserted AC class or declaration (if any) was associated
with the user's session. If that time can't be determined, the IdP SHOULD
assert the ExistingSession class with AuthnInstant set to the value of the
current time.

If what you're all saying is true, none of that is a normative change,
because it's the only way to follow the rules (since AuthnInstant is
required, as Ari noted).
 
-- Scott