[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Subject: RE: [security-services] the "NotOnOrAfter" issue
> 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]
Powered by eList eXpress LLC