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

[Trevor Perrin <trevp@trevp.net>]

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