RE: [security-services] the "NotOnOrAfter" issue

[Chris McLaren <cmclaren@netegrity.com>]

> The x509 notBefore/notAfter fields are second resolution, Stephen(?) 
> said. If SAML is going to follow those fields, as opposed to creating 
> new "pure and clean" ones, then it should subtype dateTime to 
> enforce that. 

The dateTime construct is the XML Schema way of capturing an instant. It
is not limited to second resolution.

We can add such a limitation, if there is a reason for doing so. I
haven't seen one yet, and I'm not demanding one from you--just stating
my position.

(Also, as I said, I am philosophically opposed to restricting design
flexibility unless there is a clear reason to do so. I'm a system
flexibility guy, which tends to make me unpopular at conformance parties
<g>.)

I'm perfectly willing to believe there is such a reason that I am
ignorant of... I just want it made explicit before we change what is
already in place. This makes sure that the reason can be reviewed by the
entire list, which allows for informed voting, and all the benefits of
our collective experience to be used in the decision. It also creates a
record in the list archives of why we did things a certain way.

> As for timezones, "here be dragons", so mandating everyone 
> convert to a 
> canonical format -- UTC -- seems to make sense to me, but it 
> was others 
> who were advocating, I was just suggesting how to achieve that. 

Same story. I don't mean to hound you particularly--I'm just bringing my
position to the list.

First off, there are definitely issues with timezones when you look at
performing comparisons or relative time operations. However, the
dateTime has enough information to resolve all of these issues without
any extra tweaking from us.

Secondly, I would like to hear a good argument for why having the
producer convert to a canonical representation is somehow a better
solution that having the consumer do so. 

If there is one, then we can implement that requirement as a subclass.

If there isn't one (and I'm fairly confident on this one for reasons I
won't bother going into unless there is a strong argument made by
someone) then we should leave well enough alone.

> My experience on the sopabuilders mailing list is that almost 
> EVERYONE 
> got it wrong initially, and I betcha almost everyone has leapseconds 
> still wrong. 

Yup. And then someone noticed and the generic packages had fixes done,
which caused those fixes to be passed on to all the applications built
on top of them.

And that's my point. Even if the first round of Schema implementations
don't handle dateTime right, the second round will. The applications
built on Schema processors will be improved in the second round. Apps
that hand-coded everything don't get the "library dividend".

If the argument is that "no one's going to implement it right" then
adding the subclass won't help--people are just going to implement it
wrong anyway. (Although I can completely understand how a person can get
to feeling like "they'll all just do it wrong, anyway". <G>). I think
the right answer to that problem is to fix it at the right level--i.e.
fix the dateTime implementations, don't try to work around
implementation bugs in the design of SAML.

C.