Conformance to one datetime standard?

[tylerjmorg]

Summary

It looks like CXF uses both Epoch time (a.k.a. UNIX time) in sections 3.1.1 and 3.2.1, and uses RFC3339 in section 3.5.5.

Is there is specific reason Epoch time was chosen over RFC3339 or RFC9557 in those particular sections?

Even though some of these items may not be visible to the user (e.g., section 3.1.1), wouldn't it be a bit more human-palatable to use RFC3339 for all date and time members in the standard? Even if all we're using is UTC (Z)?

Details

No response

Proposed Feature Type

Format

Proposed Feature Name

No response

Related Content

No response

[Progdrasil]

This is a great question, which prompted some discussion in the working group, hence the delay in responding.

The format spec really has 2 kinds of fields:

• Machine generated/managed ones
• User input

With regards to the datetime standards used, you'll notice that there is currently only one use for each of the above kinds of fields. And there's a reason.

Machine managed fields

For machine managed fields, we currently use a unix timestamp with seconds as the degree of precision. This is because it is easily understood by machines and is also a good format to control the scope of usage in a spec.

For this kind of usage, from experience of other members in the working group, it is hard to correctly scope down the usage of RFC3339 for the full date spec. And even then it is harder still to support implementations that will deviate slightly from the specification.

User inputed fields

For fields where the value is expected to be input by users, we specify the use of RFC3339 date-full which is essentially YYYY-MM-DD. While we don't expect users to input a date in this way in all provider's UI, we do expect that what ever localized format is used, can be transformed to this standard format.

For this kind of usage, transforming a date to a timestamp is less than ideal since we would need to specify that it is at midnight for that date. Transforming a date to a timestamp is fraught with potential issues.

Data continuity

This all brings me to one of the unofficial goals of the specification, and that is to minimize the amount of transformations the majority of providers will need to do. In most cases providers will store creation and modification times as unix timestamps, and store user provided dates as a string of a structured date format (RFC3339, ISO 8601, etc). Having providers export the values with minimal transformation leads to less loss and errors during transfer.

Another example of this is the passkey secret key. You'll notice between WD01 and WD02 there was a change from a question to a definite format. Initially, we weren't sure whether to use a JWK, PKCS#8 or CoseKey as the format. So we did a poll of the different providers in fido, and took the format that a majority of the providers use to store passkeys internally.

Now the format will always need some amount of mapping, this is by no means the data model of most providers. It is simply the data model that most providers can map to and from relatively easily. Most of the mapping is done at the dictionary level, and while we try to minimize the mappings required for field values, it is inevitable at some point.

[tylerjmorg]

This makes much more sense! Thank you for looking into this!

This may be trivial, do you think it may be worth adding a similar explanation in the standard?

[Progdrasil]

I don't think it's trivial at all, Questions like these highlight what's missing in the standards.

I'll write this up for the next version.