FW: [dss] Compound operation Verify & Sign

["Edward Shallow" <ed.shallow@rogers.com>]

FYI 

-----Original Message-----
From: Edward Shallow [mailto:ed.shallow@rogers.com] 
Sent: November 4, 2003 1:52 PM
To: 'Nick Pope'
Subject: RE: [dss] Compound operation Verify & Sign

Yes the core can be finalized. As profiles evolve, change processes can
endevor to augment the core. Adding 4 or 5 profiles to the group's work
load, even if explored only partially, may jeopardize targets.

I agree that canvasing the 1st 4 or 5 profile implementors as to whether the
DSS core will provide the foundation to create their profile protocol is
worth pursuing. I am actively cross-checking our ability to build an EPM
profile on top of DSS. I am posting specific circumstances where you are
attempting to but not helping me do that. I will not be able to use a
generic "updated signature" bucket as presently described. The best that
might happen is that a subset of my EPM scenarios may be able to use it but
not all will.

Lastly, it is not a big issue to simply leave this out and relegate specific
extensibility approaches to the profiles. Wait and see what alignment and
consistency you can achieve when the dust settles. There is little to be
gained by pursuing it now.

Ed 

-----Original Message-----
From: Nick Pope [mailto:pope@secstan.com]
Sent: November 4, 2003 1:37 PM
To: Edward Shallow; dss@lists.oasis-open.org
Subject: RE: [dss] Compound operation Verify & Sign

Ed,

I agree that we cannot finalise the core until we have progressed some way
with the profiles sufficient to identify needs to augment the core.

Nick

> -----Original Message-----
> From: Edward Shallow [mailto:ed.shallow@rogers.com]
> Sent: 04 November 2003 14:19
> To: 'Nick Pope'; dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
>
> PostScript:
>
> The other issue with pursuing a common field across all profiles, is 
> the related question you asked me to post to the list during 
> yesterday's conference call. That is should the core schema include 
> elements from profiles some of which have yet to be defined. I'll 
> context and post that series of questions in a separate post, but it 
> is safe to say that your suggestion should be parked until we get a 
> resolution on core versus profile handling.
>
> On another note, we had previously suggested that procedureal 
> mechanisms for accepting and vetting profiles before they are 
> published could be instituted. I believe trying to provide consistency 
> in advance of full profile definition and submission will be 
> fruitless. There will be more than one common element that is outside 
> of core but potentially common across a series of profiles.
>
> Alignment and consistency verification can more easily be done at 
> profile submission time. If there is enough overlap with core and/or 
> with all other profiles, we have occasion and opportunity to augment 
> the core, else it stays in the profile and is made consistent with the 
> other profiles.
>
> I'll pick up this discussion in the other thread.
>
> Ed
>
> -----Original Message-----
> From: Edward Shallow [mailto:ed.shallow@rogers.com]
> Sent: November 3, 2003 8:43 PM
> To: 'Nick Pope'; dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
> I believe that subtle difference can also work.
>
> -----Original Message-----
> From: Nick Pope [mailto:pope@secstan.com]
> Sent: November 3, 2003 10:34 AM
> To: Edward Shallow; dss@lists.oasis-open.org
> Subject: RE: [dss] Compound operation Verify & Sign
>
> Ed,
>
> My concern with just adding the signature as an output defined as part 
> of each application profile is that each profile will define its own 
> output structure for the "updated" (e.g. XAdES-L, time-stamped, 
> counter-signed
> .....) signature.
>
> What I am suggesting is to have an common field in the result of 
> verify which all profiles will use.  Thus the client need not concern 
> itself with the different ways different profiles return the updated
signature.
>
> Nick
>
> > -----Original Message-----
> > From: Edward Shallow [mailto:ed.shallow@rogers.com]
> > Sent: 03 November 2003 02:04
> > To: 'Nick Pope'; dss@lists.oasis-open.org
> > Subject: RE: [dss] Compound operation Verify & Sign
> >
> >
> > Hi Nick,
> >
> >   Actually, the "Option" in this case is very focused. There is no 
> > need to compare ins/outs across the Sign and Verify. The ancilliary 
> > operation in each case should produce only what Outputs are required 
> > above and beyond what is already in the core operation. This applies 
> > to a SignatureTimeStamp as well as to a signature "refresh".
> >
> >   Additionally as I mentioned in my previous memo, no one is 
> > considering the mess this will create for profile implementors and 
> > the hand-cuffs it places on extensibility.
> >
> >   Please walk through the cases one-by-one and I believe you will 
> > see the simplicity.
> >
> > Ed
> >
> > -----Original Message-----
> > From: Nick Pope [mailto:pope@secstan.com]
> > Sent: October 30, 2003 6:14 AM
> > To: Edward Shallow; dss@lists.oasis-open.org
> > 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
> > .
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
>
>
>
> 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
.