18 juni 2018 kl. 18:55 skrev Ivan Kanakarakis <ivan.kanak at gmail.com>: Hey everyone, TL:DR the world disagrees with the SAML2 spec regarding datetime representation. I've been looking over issue #445 https://github.com/IdentityPython/pysaml2/issues/445 The user is using some software that generates a date like this: 2017-08-29T09:16:45.0631274-05:00 and this cannot be parsed by pysaml2. Even if pysaml2 did parse this, internally it does not take into account the timezone information. This means that comparing two dates with different timezones will return incorrect results. Dates can appear in a lot of attributes in SAML, but they are all defined as of type `dateTime` datatype. This type is defined by XML Schema Part 2: Datatypes Second Edition: https://www.w3.org/TR/xmlschema-2/#dateTime However, SAML2-core on section 1.3.3 specifies that: Note that at this point there are three layers: - SAML2-core, section 1.3.3 - XML Schema Part 2: section 3.2.7: dateTime datatype definition - ISO-8601 spec Each layer says it does exactly what the layer below does .. but with some exceptions .. which usually make things *a lot* harder to manage. This means that for SAML2 the `dateTime` datatype is assumed to be in UTC and must not define a timezone. In the example case above, the correct value would be: 2017-08-29T14:16:45.063 Notice that the fractional seconds have been stripped to 3 decimal places to represent milliseconds (instead of 6 places which would mean microseconds). The original representation had 7 decimal places which means nanosecond precision which cannot be supported by the native python types; numpy defines datetime64 which has greater precision https://docs.scipy.org/doc/numpy-1.13.0/reference/arrays.datetime.html So.. the question now becomes whether implementations actually hold that promise, and if not, how do we handle it.. Looking around, all I can find is examples where dates are in the form: 2017-08-29T09:16:45Z that is, they include 'Z' which means 'UTC', or '+00:00' or '-00:00'. By including the timezone part they are invalid values. The only place where I see correct values is the Wikipedia examples: https://en.wikipedia.org/wiki/SAML_2.0 Looking at the history, these examples used to include 'Z', but have been fixed by the following changeset: https://en.wikipedia.org/w/index.php?title=SAML_2.0&type=revision&d… which correctly summarises the change as "Removed time-zone component from examples as this is prohibited (see section 1.3.3 of SAMLCore)". How do we solve this? ## Plan A: Follow the spec. Treat 'Z'-suffixed and other timezoned values as invalid. This will probably break many running setups, as it seems other implementations send dates including the 'Z'/UTC timezone suffix. (It is still an open question whether implementations send other timezoned values.) ## Plan B: Ignore the spec, assume XML Schema dateTime datatype and accept 'Z'-suffixed values (along other timezoned values.) This means things will continue as normal, but there is a case that we now need to handle; comparing timezoned dates with untimezoned dates. This is covered by the XML Schema spec in section 3.2.7.4 Order relation on dateTime and defines the incomparable cases https://www.w3.org/TR/xmlschema-2/#dateTime-order ## Plan C: Do our own thing? Make things worse? Treat untimezoned dates as UTC? I'm putting this here to see what everyone else has to say. I'd love to go with Plan-A :) (What's the point of a specification that none follows? I understand though, it is not a viable solution, at least at the moment.) In the meantime, I'll look into other implementations to figure out what they do. -- Ivan c00kiemon5ter Kanakarakis >:3 _______________________________________________ Idpy-discuss mailing list Idpy-discuss at lists.sunet.se https://lists.sunet.se/listinfo/idpy-discuss

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**.