Re: [dss] Namespace inheritance, other approach

[Konrad Lanz <Konrad.Lanz@labs.cio.gv.at>]

Trevor Perrin schrieb:

> I understand now, thanks - you're saying subverted client software 
> could produce a DSS request that wasn't what the user of the software 
> wanted.   The user might not notice this misbehavior if he inspects 
> the request.
>
> I'm not too worried about that.  However, I agree we should require 
> the server to disallow Input Documents that don't redeclare the 
> namespaces they use.  That should take care of the problem.

True.

>> Assuming that also other client side transforms have been applied 
>> previously on the input document which
>> removed namespace nodes from the output node set, I would say 
>> something has to be done.
>>
>> I suppose but I'm not entirely sure that exclusive canonicalization 
>> would render the removed namespace nodes
>> if they are still needed even though they might not be in the output 
>> node set.
>
> I believe Exclusive canonicalization on the server-side would render 
> the removed namespace nodes 

I don't think it can do that, due to the fact that the removed nodes are 
not transmitted and hence the namespace uri is unknown.

So I would say as soon as client side applies transforms the client 
should also canonicalize exclusively, then the server can apply
further transforms without a problem.

> if they were declared and used in the Input Document,or if they were 
> passed as inputs to the canonicalization algorithm (see the 
> InclusiveNamespacesPrefixList):

> Trevor wrote:
>
>>>  - Are you thinking the client would need to add exclusive 
>>> canonicalization to the list of ds:Transforms, and this would appear 
>>> in the output signature?
>>
>> To cover the general case, yes.
>>
>> Because if I'm not wrong XPath transformations do operate on the 
>> complete document and
>> while they reduce the output node set more and more, later XPath 
>> expressions can still depend
>> on all nodes of the document.
>>
>> However as soon as one embedded the output node set into dss protocol 
>> and then transmits (canonicalizes/serializes) it
>> and then parses it at the server side the whole document is not 
>> available any more.
>
> From the above, it sounds like the problem is that server-side XPath 
> transforms could depend on the entire document, so any method we use 
> to transmit a fragment of a document (regardless of whether we encode 
> or canonicalize it) will have problems.
>
> How does client-side exclusive canonicalization fix that?

It does not fix the fact that someone(some user) might apply server side 
transforms expecting some nodes still to be available.

However it assures that the nodes removed by some xpath transform on 
client side would be always be removed, even
if the signature was made in a non dss application.

This is necessary because

 Input Doc --> client side transforms --> client side excl canon --->  
server side trans --> excl canon  --> digest
 DOM-A                DOM-A                                           
                     DOM-B            DOM-B

is different from

Input Doc --> client side transforms --> server side transforms --> 
exclusive canonicalization  --> digest
 DOM-A                DOM-A                         DOM-A               
             DOM-A

best regards
Konrad