Re: [dss] "Required" Designation on SignatureObject within VerifyRequest

[<ed.shallow@rogers.com>]

Folks,

     An enveloped signature in the only InputDocument presents no
implementation issue with respect to locating the signature. In fact neither
does an enveloping one. Many (most ?) toolkits allow the caller to simply
pass in the entire "DocumentWithSignature" on their resepective Verify calls
(e.g. XMLSec). As long as they can follow the cert chain, that is all they
need to perform the Verify.

     As a compromise, would you allow something like this in the spec's
documentation ...

"When only one InputDocument exists, which contains the signature to be
verified, DSS implementations MAY relieve their callers of having to
initialize the SignaturePtr elements (i.e. WhichDocument and XPath). In this
case, DSS implementations would assume the signature is contained in the
only InputDocument and verify the signature accordingly, whether it be
enveloped or enveloping".

Although it would probably be easier to just leave the schema as is, but
relax the [Required] on the SignatureObject.

Ed


----- Original Message -----
From: "Trevor Perrin" <trevp@trevp.net>
To: <ed.shallow@rogers.com>; <dss@lists.oasis-open.org>
Sent: Wednesday, April 14, 2004 3:39 PM
Subject: Re: [dss] "Required" Designation on SignatureObject within
VerifyRequest


> At 09:16 AM 4/14/2004 -0400, Edward Shallow wrote:
> >All,
> >
> >     To make things easier on clients when creating a VerifyRequest,
would it
> >be possible to relax the [Required] designation on the SignatureObject
for
> >the simplest of scenarios where there is only one InputDocument and the
> >signature is contained therein. There would be no WhichDocument ambiguity
> >and the client would be relieved of having to construct the SignaturePtr
> >element.
>
> This shifts a burden to the server though - the server has to know where
> the signature is located inside the input document, or he has to search
for
> it.
>
> This would simplify things a bit in the case where:
>   - there's 1 input document
>   - with 1 enveloped signature
>   - and the server knows where the signature will be found.
>
> Still, I don't think it's worth complexifying things by treating it as a
> special case.
>
> Requiring the client to construct a <SignaturePtr>, as we do now, doesn't
> seem that painful.
>
>
> >  This would be sort of like the DocumentWithSignature type presently
> >used as OptionalOutput. In fact, could DocumentWithSignature itself not
be
> >used as input on a VerifyRequest if both SignatureObject and
InputDocuments
> >were made optional ? This would be more semantically correct for this
> >scenario which I contend would be the most common. Thoughts ?
>
> I have the same objection - this might be more apt for this particular
> case, but adding special-cases like this complicates the protocol as a
whole.
>
>
> >      Section 5.1.2 line 1121 of the core spec Draft 18 has a typo ...
> >Ptarroduced ...
>
> Got it, thanks.
>
> Trevor
>
>
> 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
.
>