1:09 p.m.
On 2018-06-19 12:04, Ivan Kanakarakis wrote:
Hi Bas,
On Tue, 19 Jun 2018 at 12:09, Bas Zoetekouw <bas.zoetekouw at surfnet.nl> wrote:
Given what Bas just said maybe emit /with/ Z tz (if I understood that
correctly)
Cheers Leif
Hi!
If this holds, this is a big omission. This means that datetimes must
be in ISO-8601 format with timezone info always 'Z'/UTC. What happens
if 'Z' is missing?
However, SAML2-core on section 1.3.3 specifies
that:
#### 1.3.3 Time Values
All SAML time values have the type `xs:dateTime`, which is built in
to the W3C XML Schema Datatypes specification [Schema2], and **MUST
be expressed in UTC form, with no time zone component**.
According to Scott Cantor, this is misexpressed and should be read as
"MUST be expressed in UTC form, with no time zone _offset_":
https://lists.oasis-open.org/archives/saml-dev/201310/msg00001.html
I have no idea why this has never been addressed by a SAML erratum, as
this topic has popped up a number of times in the past (at least in the
context of SSP and eduGAIN).
So maybe we should apply the Postel principle
here and emit only
TZ-free datetime objects but parse all objects.
This is what I'm thinking:
- We accept all (ISO-8601) formats that we can parse, and convert them to UTC.
- If there is no tzinfo, we assume the other side is respecting the
current wording of the SAML2-core specification, and thus the time is
already in UTC.
As a result, all dates are normalised to UTC and can be compared and
worked-with under that assumption.
This leaves one question: when we need to emit a date what should the format be?
Note that at the very least SSP and Shibboleth
will break if non-
ISO8601-compatible dates are received, so please don't generate any
unqualified dates. I don't really have an opinion about _accepting_
such unqualified dates, though.
Taking this and Scott Cantor's reply on that thread above into
consideration, we should produce ISO-8601 datetimes in UTC with
timezone info always 'Z'.
I think we have a plan :)
--
Ivan c00kiemon5ter Kanakarakis >:3