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

[Chris McLaren <cmclaren@netegrity.com>]

> > >>- all times in UTC (i.e. no local times, no daylight savings) 
> > 
> > This is part of the dateTime datatype *DEFINITION* in XML 
> > schema. The definition also includes detailed rules on 
> > comparision of dateTime values. 
> As far as I know, XML schema dateTimes can include TZ 
> information in a 
> couple of different ways (and comparisons are still pretty 
> clear). I see 
> no problem mandating UTC time though if people care. 

I think the point is that we are using the standard dateTime constuct
defined by XML Schema. We respect the rules for handling it, and we
aren't requiring anything beyond a properly formed dateTime w.r.t. XML
Schema. 

Unless I am mistaken Stephen doesn't really care what the time looks
like as long as everyone knows how to interpret it as an unamiguous
identifier of a specific instant (I.e. I don't think he really requires
time to literally be encoded in a UTC string in every message, but
rather he wants to make sure you can't just say "5:00PM" without any
indication of what time zone you are talking about). Using the Schema
dateTime gives us that, and it also means that everyone else in the
universe who has code that can handle XML schema will know how to handle
the field without any special "SAML-specific" code.

I do feel like someone needs to say, though, that our charter is to
define an XML-based language for making security-related statements, not
to define something as close as possible to X.509, or some other
existing technology. 

Naturally wherever possible we should attempt to be compatible (at least
at the concept level) with existing technologies, but when design
decisions need to be made "closest to the standard XML way of doing
things" has to weigh more heavily than "closest to the <other
technology> way of doing things". 

C.