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

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

Trevor,

    I like your suggestion on optional outputs scoping. Very neat and tidy.
But for the same reason, I don't like a brand new SignatureObject
sub-element. Especially since I do not want to use it all in the scenario we
are discussing. I simply want to Verify the InputDocument (i.e. the
DocumentWithSignature). In fact it would work nicely with you new scoping
suggestion. 

    I do not think it changes the entire semantic. There are plenty of
nuances in the spec as it is, and this one is very easy to get your mind
around.

    What say you ?

Ed 

-----Original Message-----
From: Trevor Perrin [mailto:trevp@trevp.net] 
Sent: April 18, 2004 5:27 PM
To: ed.shallow@rogers.com
Cc: dss@lists.oasis-open.org
Subject: RE: [dss] "Required" Designation on SignatureObject within
VerifyRequest


At 05:23 PM 4/18/2004 -0400, Edward Shallow wrote:
>Back to the original discussion ... On the XMLDSIG support for multiple 
>signatures in a single InputDocument,

Now that we've "re-discovered" that <SignatureObject> is extensible (I'd
forgotten this until today!), I think you could add this functionality at
the profile level, without tweaking the core.

In fact, this is looking similar to Code-Signing/Async: it's functionality
that *could* be part of the core, but which we probably want to leave in a
profile for now (perhaps an abstract profile), to avoid complicating the
core for people who don't want it.



>  are you and the team willing to do
>some relaxing/tweaking in the following areas ?
>
>- the [Required] on the XPath sub-element, change to [Optional] with 
>non-normative comments pointing at the profiles

Instead of changing <SignaturePtr>, I think it would be better to introduce
a whole new <SignatureObject> sub-element.  Your suggestion would be an easy
syntax tweak, but it changes the semantics of <SignaturePtr> so much that I
think a new element is preferable.



>- some unboundedness on the ProcessingDetails optional output
>
>    The rest of the options I can simply constrain in the profile


Alternatively, instead of changing or disallowing the optional outputs, you
could add some sort of "scoping" so that the server can associate optional
outputs with different signatures, like:

<OptionalOutputs>

   <Scope whichSignature="1">
     <SigningTime>...</SigningTime>
     <SignerIdentity>...</SignerIdentity>
     <ProcessingDetails>...</ProcessingDetails>
   </Scope>

   <Scope whichSignature="2">
     <SigningTime>...</SigningTime>
     <SignerIdentity>...</SignerIdentity>
     <ProcessingDetails>...</ProcessingDetails>
   </Scope>

</OptionalOutputs>


So I would recommend leaving the core untouched, but doing "document-centric
verification" as an abstract profile, with a new type of signature object,
new result codes, and some way of scoping optional outputs.  What do you
think of this?


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
.