t+/-dt

[Tim Moses <tim.moses@entrust.com>]

Colleagues - There are two common ways of expressing the time when there is
a degree of uncertainty.

1. a=t+dt, b=t-dt, or
2. a=t, b=dt

Of course, one can readily convert values between the two styles.  

I can think of a couple of reasons for choosing style 2.  The first is that
paradoxical statements cannot be made in style 2 (one cannot say before
2:00pm on Friday, but after 2:30pm on Friday).  The other is that style 2 is
more compact, or stated differently, in most cases, the year, month, date,
hour, minute and time-zone offset values in t+dt and t-dt will be identical.

But, it seems to me that the most appropriate way to choose between the two
styles is to consider whether the client or the server should bear the
computational burden in the most common applications.  In keeping with the
philosophy of the architecture (simplifying matters for the client) it seems
apparent that any computational burden should fall on the server.

Except in cases where the client is not concerned about the accuracy, I
cannot think of an application in which the client is interested separately
in the server's estimate of the time and its estimate of the uncertainty in
that time.

Some of the most common situation are where the relying party wants to know
definitively whether t is earlier or later than some t'.  In the former
case, it should compare t' with t+dt and in the latter case, it should
compare t' with t-dt.

Here are some examples where the relying party compares times:

- Determining if a signed document was created within the validity interval
of a private key.
- Determining if a signed document was created before a certificate was
revoked.
- Determining whether a bank deposit was made before a withdrawal.

There are also situations in which the relying-party wants to know
definitively the earliest or latest time at which a certain event could have
occurred (e.g. creation of a document).  In the former case the relying
party is interested in t+dt and in the latter case in t-dt.

If the relying-party is not concerned about accuracy, then there it can
simply choose to use t-dt or t+dt, in place of t.  We could make it
mandatory to include t+dt in a timestamp token and optional to include t-dt.

It has been argued that style 2 is more conventional or intuitive; it is
more consistent with a service that simply asserts that it performed a
certain action at a certain time, regardless of how one might use that
information in a given business context.  Personally, I don't find that
argument persuasive.

What do others think?  All the best.  Tim.


-----------------------------------------------------------------
Tim Moses
613.270.3183