[security-services] Following up on dateTime

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

I offered to research the issues around handling of dateTime and time
zones in XML a little, which I've done. I'm still not 100% sure I
understand what the schema specification means by canonical
representation in sec 3.2.7.2 (it's not defined anywhere as a term that
I can see).

If it's merely a way to subset the lexical forms allowed without having
to specify a pattern restriction, then it doesn't seem very clearly
articulated.

The interpretation I'm finding from those involved in various mailing
list posts is that in the absence of a time zone specification in the
value, an application is free to impose whatever interpretation it
wants. So I guess that means SAML can use xsd:dateTime and simply
include text in the specification that requires canonical form and
specifies the absence of a Z at the end to be the same as a Z (that is,
UTC time).

I don't really see the wisdom in this, since it makes the SAML
application responsible for insuring the rules are followed instead of
the parser. I think it makes more sense to either:

a) Allow any legal lexical form, with the additional wording that
absence of time zone is taken to mean UTC time. This will provide a
complete ordering while allowing the parser (perhaps not currently, but
someday) to hopefully consume the time zone value and provide the proper
conversion.

b) Derive a saml:dateTime (or perhaps name it something else) using a
pattern restriction that calls out exactly what syntax is permitted as a
subset of the lexical forms allowed by xsd:dateTime, probably requiring
that a Z appear on the end.

Either of these seems better to me than trying to impose conditions
entirely in textual fashion.

What have other specifications that use times for security processing
done?

-- Scott