> > - "selection transforms" A -> B, and the
> > - "signature transforms" A -> C, B -> C
Shouldn't the reciever be able to reapply the mentioned 'signature transform' using the enveloped data ? It doesn't make sense for me to envelope some data which you could NOT use as a starting point for the 'signature transform'. You couldn't verify this signature without additional access to the original data. This would proof the enveloped data as redundant.
I would prefer to allow only B -> C signature tranformations. The A -> B tranformation would degrade to be friendly service for the user.
Or do I have missed an important aspect (again ) ?
Greetings
Andreas
--- Nick Pope <> wrote:
> What is there a difference between selection transforms and other transforms
> (e.g XSLT). I can see uses in having enveloped documents that includes the
> post transformed document being enveloped after the style sheet has been
> applied. Something like this cam up in earlier discussions in this area,
> although I am not sure of the outcome.
>
> I would be concerned about not allowing enveloping of documents after
> transform.
>
> Nick
>
> > -----Original Message-----
> > From: Trevor Perrin [mailto:]
> > Sent: 12 September 2003 21:52
> > To: Juan Carlos Cruellas;
> > Cc:
> > Subject: Re: [dss] REFORMULATED ISSUE#2: SIGNATURECONTENTS (SIGN REQUEST
> > DISCUSSION)
> >
> >
> > At 02:08 PM 9/12/2003 +0200, Juan Carlos Cruellas wrote:
> >
> >
> > >COMMENT: For me this means that the text says that it may be the
> > case that
> > >a requester
> > >sends an Input document, A. He has to send in fact two
> > informations to the
> > >server:
> > > 1. Information on what elements of the input document A have to
> > > be signed.
> > > 2. Information of the additional transformations that
> > the server
> > > has to
> > >apply to these elements.
> > >Now the server does the following:
> > >
> > >1. It builds up B (set of elements that will eventually be
> > signed) from the
> > >information in 1. This information
> > >sent by the requester can be a XSLT transformation or a XPath expression.
> > >
> > >2. It builds up C by transforming B according the indications in
> > additional
> > >transformations.
> > >
> > >3. It envelopes B!!! in the signature. At least this is what I understand
> > >from the text.
> >
> > Hmm. So you're saying there's the:
> > - "selection transforms" A -> B, and the
> > - "signature transforms" A -> C, B -> C
> >
> > A = input documents
> > B = enveloped or enveloping documents
> > C = the final post-transformed data that's actually signed
> >
> > You're right, that's what 3.5.1 in the requirements doc appears to say.
> > I'd say that's the most complex of 3 choices:
> >
> > 1) selection transforms can produce enveloped or enveloping docs
> > 2) selection transforms can produce only enveloped docs
> > 3) no selection transforms
> >
> > Perhaps we can revisit the requirement. I'm not sure it's
> > important to be
> > able to select particular parts of Input Documents. Doing (3) would make
> > things easier.
> >
> > I'll try to get list feedback on this.
> >
> >
> > >So, you seem to say that the meaning of the text in the req. doc
> > is the one
> > >you mentioned?
> >
> > No, I think your reading is correct. But I'm wondering if we can revisit
> > this and cut out the words "particular parts" from 3.5.1.
> >
> > Trevor
> >
______________________________________________________________________________
38xTestsieger - WEB.DE FreeMail - Deutschlands beste E-Mail
Design-Mails - einfach schoenere E-Mails - http://f.web.de/?mc=021129
