Subject: Re: TSP interop update

From: [email-masked] (Peter Gutmann)
Date: Fri, 1 Feb 2002 23:22:38 +1300 (NZDT)

Denis Pinkas <[email-masked]> writes:
>IF, I did say "IF", we go into that direction, then it would mean changing the
>reqPolicy field in TimeStampReq by allowing a sequence of TSA policies instead
>of a single policy.
>
>Would this fit the concern from Peter ?

To some extent, although you'd need to allow anyPolicy to allow the client to
specify that if it can't get an exact match, anything will do.  Consider for
example electronic tax filing, in which I have to get my submission timestamped
to prove I filed on time.  Before I submit the return to irs.gov I go to
time.gov and get my return stamped.  Ideally I'd want it notarised under the
2002 tax policy, or failing that the 2000 tax policy, or the general tax
policy, but if all else fails I can probably get it done under the dog-license
policy because if it goes to court all that matters is that it's timestamped.
If it was under any of the standard tax policies I wouldn't need to go to
court, but the dog-license policy is always better than having nothing at all.

However:

It's still making the decision at the wrong place.  Instead of the client being
able to decide what's acceptable, it now has to communicate more and more state
information to the server and still ask the server to make the decision for it.
It's turning into an uglier and uglier kludge because the client, who should be
making the decision, is banned from doing so, so all it can do is throw a
mountain of state at the server and ask it to make the decision for it.  In the
case of the tax-timestamping above I can easily encode this process at the
client, but I have no idea how I'd communicate that decision-making process to
the server.  The real solution, which is relatively straightforward, is to
allow the client to device what it wants to accept, not to require the server
to make the decision for it.

Peter.

---

From: Denis Pinkas <[email-masked]>
Date: Fri, 01 Feb 2002 15:15:51 +0100

Peter,

> specify that if it can't get an exact match, anything will do.  

If anything will do, then the client does not need to request any specific
policy. 

:-)

> Consider for

In a negotiation protocol, the client states what it is ready to accept and
mentions its order of preferences. Then the server chooses among the list.

Denis

---

From: "todd glassey" <[email-masked]>
Date: Fri, 1 Feb 2002 08:05:56 -0800

----- Original Message -----
From: "Denis Pinkas" <[email-masked]>
To: "Peter Gutmann" <[email-masked]>
Cc: <[email-masked]>
Sent: Friday, February 01, 2002 6:15 AM
Subject: Re: TSP interop update

> > to prove I filed on time.

Bad model - the IRS and the other tax collection bureaus care only when they
claim they recieved the document and unless there is a "rush to the
Courthouse" going on there - you have nothing to say about it other than
"err uhhhh Thanks." In order to have any effect here the Tax Bureau would
have to need to acknowledge independantly that you had paid your taxes and
there is no such tax process that needs that today - so this TSP is really
useless in taxation processing models.

>> Before I submit the return to irs.gov I go to
> > time.gov and get my return stamped.

No - Wrong - What matters is when the IRS.GOV site responds that it got the
filing not what time you submitted it. Who cares what time you submitted it
if the network eats the filing it is still your responsibility.

> > Ideally I'd want it notarised under the

The problem is that in this model there is assumed to be some agent between
you and the Tax Collector and that is just not how its being rolled out. The
Tax Bureaus are allowing people to tunnel into secured forms on their sites
and by that creating a session level connection to the transaction servers
and as this the only thing that is an issue is what time the server tells
you this filing was recieved - what time you submitted it is irrelevant in a
legal sense in most all instances.

> > information to the server and still ask the server to make the decision
for it.

This is feature creep because no real use model existed. All the Server
needs to be able to do is to "Create and Verify" tokens and that to
accomplish this it should have a verification service model built into the
client-side protocol to support the working within the cause of "Verifying
the individual externally provided data points" for the Marque to be
created.

> > mountain of state at the server and ask it to make the decision for it.

yes but this is true becuase the WG as a whole refuses to do what is clearly
necessary, which is to setup a set of use models for the protocol.

> > In the