[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] REFORMULATED ISSUE#2: SIGNATURECONTENTS (SIGN REQUEST DISCUSSION)
> > - "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 <pope@secstan.com> 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:trevp@trevp.net] > > Sent: 12 September 2003 21:52 > > To: Juan Carlos Cruellas; dss@lists.oasis-open.org > > Cc: ed.shallow@rogers.com > > 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]