Re: [dss] Way Forward on Basic Processing in terms of EnvelopedSignatures,ds:Objects (EnvelopingSignatures), client-side splicing plus client-sidetransforms.

[Trevor Perrin <trevp@trevp.net>]

Konrad Lanz wrote:
> Hi Trevor and all,
> 
> Trevor Perrin wrote:
> 
>> [...]
>>  a) making this a typical optional input, i.e. not part of basic 
>> processing
>>  b) making this a fundamental part of the protocol, i.e. not an 
>> optional input
>>
>> Since you intend profiles to choose it or not, I suggest (a).
> 
> 
> Thanks for bringing this up, this is a crucial point however we have to 
> think this through and I think the right answer might be somewhere in 
> between.
> 
> Executive Summary:
> Please read Question I (QI ) and Answer III (QI AIII), (QII) (QII AII), 
> (QIII AII) and (QIV) (QIV AI) to see my suggestion.

Okay, my suggestions below.

Basically, I think the changes to <EnvelopingSignature> are fine 
(renaming it to <IncludeObject>, adding 'hashObjectTagsAndAttributesSet').

However, I don't see the problem with client splicing that necessitates 
making <IncludeObject> part of basic processing, or demoting client 
splicing to a profile.

As I understand it, the "problem" is that servers might rewrite the 
client's XML before signing (without recording a <ds:Transformation>), 
thus clients would not be splicing with the correct XML.

However, that is bad server behavior.  So I think we should just add 
text to clarify that and leave things as-is.


> (Q I)
> The interesting question now is: Does the same-document Uri imply that 
> there also has to be a <dss:IncludeObject>( or a 
> <dss:SignaturePlacement>) and hence a <ds:Object> has to be 
> embedded/spliced (or an EnvelopedSignature has to be created)?

No.


> (QII)
> Another question is about one special case we also should not forget 
> about: What if a client wishes to have a document with a signature in 
> it, having one ore more references with same-document Uris pointing to 
> some arbitrary NodeSets within this very same document? How do we 
> communicate these RefURIs.

I don't understand this question.


> (QIII)
> How does client-side splicing now fit in?

Leave it where it is, with qualifications (that it can be used for 
<DocumentHash>; that it should not be used with profiles that rewrite 
inputs).


Trevor