No Subject

There are some advantages with these methods from a practical point
of view, mostly in the reduced number of values that are kept online. =20
On the other hand, disk space limitations are not what they used=20
to be six years ago :)  These techniques do require a return trip=20
to the TSA to bind the token to the subsequent "round" value=20
(the token already contains a binding to the previous "round" value=20
when it gets issued).

I hope this helps with your questions some. =20

>   - You mention a client getting a timestamp from a TSA, which can be=20
> verified by running a verification protocol with a TSA or other=20
> authorized=20
> 3rd party.  In this case, a client who wanted to verify a timestamp =
would=20
> only need to read the time from the timestamp, and enough identifying=20
> information to know which verification service to contact.  The client =

> could treat the evidence (i.e. the BindingInfo data) as opaque.  So =
maybe=20
> our timestamp data format should be something like:
>=20
> <TimestampData>
>=20
>    <Time>
>      <!-- An indication of the time -->
>    </Time>
>=20
>    <IssuingTSA>
>      <!-- URI of issuer, if exists -->
>    </IssuingTSA>
>=20
>    <VerifyingTSA>
>      <!-- URI of a verification service, purely informative; may occur =

> multiple times -->
>    </VerifyingTSA>
>=20
>    <Evidence Type =3D "http://www.oasis.org/dss#SomeTimeStampType">
>      <!-- Linked/aggregated/accumulated values and so on -->
>    </Evidence>
>=20
> </TimestampData>
>=20
> Then it could be left to follow-on work (maybe even a later document =
from=20
> this TC) to define different <Evidence> types?  This is similar to =
what=20
> Karel's paper suggests, except his paper goes further in=20
> describing generic=20
> structures that can be used with all different linking schemes.  =
That's=20
> probably how things should be done eventually, but it seems=20
> complex enough=20
> that we should work on the core protocol first, and just make sure it =
can=20
> be extended in the future.
>=20
> Trevor
>=20
> ...=20
>=20

I think Karel's document provides a lot of material for the necessary=20
XML elements.

Dimitri