OpenSAML user discussion

[Chad La Joie <>]

Scott and I chatted about this today and I think we're on the same page.

The normative SAML 2 spec does say the date/times are supposed to be 
without a timezone but also requires that it be xsd:dateTime compliant 
and in the UTC timezone.  The XML schema spec contains wording such that 
without the timezone component the timezone is undefined (and usually, 
but not always, considered local time).

We both agree that the spirit of the SAML spec, as reflected by the 
examples given in the spec, really means that the timezone is in UTC, 
has a timezone to specify that, and does not allow timezone offsets 
(which is just another way of saying UTC).

So, it is conceivable that the timezone component *could* cause issues 
with some products but Scott's experience has been that everyone uses 
the 'Z' timezone component.  So I've gone ahead and added that back into 
the default rendering of the date/times for OpenSAML 2.  If it does 
cause a problem with some product developers can override the behavior 
via the method:

Configuration.setSAMLDateFormat(String)

Chad La Joie wrote:
> Yep, sorry.  Was actually looking at two different formatting specs.
> The Z, it turns out, isn't supposed to be there.  SAML 2 says the time
> is not supposed to include the zone component (though SAML 1 did allow
> this it isn't required), and 'Z' is just the canonical representation of
> the UTC zone.
>
> So the default is: yyyy-MM-dd'T'HH:mm:ss.SSS
>
> Tom Scavo wrote:
> > On 8/8/07, Chad La Joie 
> > <>
> >  wrote:
> > > I have centralized the date/time format, however I do not provide a
> > > configuration file option to change it.  If you want to change it you
> > > just call
> > >
> > > Configuration.setSAMLDateFormat(String)
> > >
> > > By default the format is: YYYY-MM-ddTHH:mm:ss.SSS
> > Should the default be: "yyyy-MM-dd'T'HH:mm:ss.SSS'Z'"
> >
> > ?
> >
> > Tom

--
Chad La Joie             2052-C Harris Bldg
OIS-Middleware           202.687.0124