Trevor,
As far as the <TstInfo>, I think the extra "name"
attribute is all that's needed so we can use the
same <TstInfo> definition for tokens that carry
no ds:Signature/KeyInfo/KeyName field.
The current definition of <Tst> is not open to
extensions when the token is not signed. I would
argue for a token definition where the token
includes the <TstInfo>, possibly the <LinkingInfo> or
other elements to be determined in the future,
and possibly (minOccurs="0") an enveloped <ds:Signature>
over the token.
Dimitri
> -----Original Message-----
> From: Trevor Perrin [mailto:]
> Sent: Wednesday, October 22, 2003 5:32 AM
> To: Dimitri Andivahis;
> Subject: Re: [dss] TSTInfoType
>
>
> At 01:50 PM 10/20/2003 -0400, Dimitri Andivahis wrote:
>
> >I propose adding the following optional attribute to
> >the TstInfoType complex type:
> >
> > <xs:attribute name="TSA" type="xs:anyURI" use="optional"/>
> >
> > TSA [Optional]
> > This attribute SHALL identify the TSA that issued the token.
> >
> >This will facilitate future extensions of the protocols
> >to TSAs using mechanisms other than X.509 certificates.
>
>
> Tim's intent, I think, was for the name of the TSA to be carried in the
> ds:Signature/KeyInfo/KeyName field.
>
> To help consider your proposal, can we look into how extending the
> time-stamp format would work? How do you see the current <Tst> and
> <TstInfo> being extended? Could linking information be added as
> additional
> "signed attributes" within a <Tst>? Or would you just re-use the
> <TstInfo>
> inside a different wrapper?
>
> Trevor
>
