[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Compound operation Verify & Sign
Ed, I agree with your aim for flexibility and that this could be achieved by additions of options and outputs. However, I believe that because the basic semantics and structure of the inputs/outputs of the verify and sign is different from the verify (or sign) on its own. With the verify and sign a signature exists in the inputs, and an updated signature in the outputs, and because this the signature is both the primary input and the primary out I believe that it should appear as part of the basic structure rather than the options. Also, I believe that it would make the procedures for handling the signature clearer with a signature coming in feeding into the verify and an updated signature coming out. So like Trevor I believe verify and sign (update siganture??) operation should appear at the primary level as is it effects the basic operation of the server, not as part of the options. I do not think that the addition of time-stamps to a signature is the same thing. Nick > -----Original Message----- > From: Edward Shallow [mailto:ed.shallow@rogers.com] > Sent: 26 October 2003 18:50 > To: 'Nick Pope'; dss@lists.oasis-open.org > Subject: RE: [dss] Compound operation Verify & Sign > > > Nick and Co, > > The last suggested position I remember getting consensus on > was that the > request for the secondary or ancilliary operation should be > expressed in the > "Options" or "ProcessingOptions" structure as it was then called. > > So in your example below, the principle operation is the "Verify". The > client requestor must express their desire through use of (for example) an > "AddContentTimeStamp" option or something similar. > > This may necessitate additonal "Outputs" but the protocol is > nicely able > to handle that. > > As it pertains to the EPM, we have need for several such compound > operations, but we will use our profile extension to express them. I also > remember discussing that additional and/or optional "outputs" and > "results" > would be expressed by the requestor as "options". > > I'll dig up the references if you wish. > > Ed > > -----Original Message----- > From: Nick Pope [mailto:pope@secstan.com] > Sent: October 24, 2003 4:28 AM > To: OASIS DSS TC > Subject: [dss] Compound operation Verify & Sign > > Following the discussion on the <Status> element brings to mind the > discussion we had a few meetings ago on compound (or what Ed > called stacked) > operations and particularly the ability to support a > VerifyAndSign operation > where a counter signature is applied based on whether the > original signature > is valid. > > I believe that such an operation is important in a number of use > cases, for > example, notarisation services. > > This was brought up at the F2F meeting and was included in the > requirements > document (3.9). My recollection of the discussion on 22 Sept is that the > only compound operation that was needed would be VerifyAndSign, although I > see no record of it in the minutes. > > How do we envisage VerifyAndSign being supported in the DSS protocol? Is > there a way of combining the two request / response structures, or do we > need to define a specific structure which is this combined operation? > > Nick > > > > To unsubscribe from this mailing list (and be removed from the > roster of the > OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/dss/members/leave_wor kgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]