[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [dss] Compound operation Verify & Sign
I hope this can be handled without special provisioning. See my related post a few minutes ago. Ed -----Original Message----- From: Nick Pope [mailto:pope@secstan.com] Sent: October 24, 2003 5:12 AM To: Trevor Perrin; OASIS DSS TC Subject: RE: [dss] Compound operation Verify & Sign Can this be added as another operation to the spec once we have the sign & verify sorted? Is there agreement that this should be part of the core spec? Nick > -----Original Message----- > From: Trevor Perrin [mailto:trevp@trevp.net] > Sent: 24 October 2003 10:44 > To: Nick Pope; OASIS DSS TC > Subject: Re: [dss] Compound operation Verify & Sign > > > At 10:28 AM 10/24/2003 +0100, Nick Pope wrote: > >Content-Transfer-Encoding: 7bit > > > >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? > > > One idea: a combined, verify-and-sign operation might just have a > request message identical to VerifyRequest and a response message > identical to SignResponse (see below) - in other words, a signature is > *both* sent (like in VerifyRequest) and retrieved (like in > SignResponse). > > I'm sure it's more complicated than that, in terms of options, but the > basic framework might be pretty simple.. > > > Trevor > > > <xs:element name="SignRequest"> > <xs:complexType> > <xs:sequence> > <xs:element ref="dss:Options" > minOccurs="0"/> > <xs:element ref="dss:InputDocuments"/> > </xs:sequence> > </xs:complexType> > </xs:element> > > <xs:element name="SignResponse"> > <xs:complexType> > <xs:sequence> > <xs:element ref="dss:Status"/> > <xs:element ref="dss:Signature" > minOccurs="0"/> > <xs:element ref="dss:Outputs" > minOccurs="0"/> > </xs:sequence> > </xs:complexType> > </xs:element> > > <xs:element name="VerifyRequest"> > <xs:complexType> > <xs:sequence> > <xs:element ref="dss:Options" > minOccurs="0"/> > <xs:element ref="dss:Signature" > minOccurs="0"/> > <xs:element ref="dss:InputDocuments"/> > </xs:sequence> > </xs:complexType> > </xs:element> > > <xs:element name="VerifyResponse"> > <xs:complexType> > <xs:sequence> > <xs:element ref="dss:Status"/> > <xs:element ref="dss:Outputs" > minOccurs="0"/> > </xs:sequence> > </xs:complexType> > </xs:element> > > > 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_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]