Re: XML decryption transform number 13

I may be missing some of the cumulative intent/state-of-mind of the current 
thread, but I think we're allowing our difficulties with the Decryption 
Transform, which is more closely linked to the Signature processing model, 
to pollute the Encryption specification. I'm thinking that, since the XML 
Encryption spec does not express any of its processing rules in terms of 
XPath node-sets (but rather in terms of XML elements and UTF-8 octets), 
neither should the implementation notes. The XPath data model may be a 
higher level of abstraction, but it doesn't map completely back to the 
conventions used in the Encryption spec. I think a good discussion of 
pitfalls/limitations/warnings for decrypt-and-replace implementations, from 
a concrete perspective (parsing context for text wrapping, XPointer issues, 
super-encryption, etc.), might be more appropriate than additional abstract 
rules intended primarily to make the Decrypt Transform easier to describe. 
Feel free to slap me down if I'm off base here. <grin/>

Ari

>On Tuesday 18 June 2002 11:39 am, Ari Kermaier wrote:
> > Frankly, I'm not sure how the text in [1] actually helps implementors.
>
>I'd agree, it doesn't help an implementor with respect to how to implement
>it. That's supposed to be a feature, though the result should be
>interoperable.
>
> > What does "copying" nodes from node-sets X and Y to node-set Z mean --
> > aren't X's and Y's nodes in different underlying documents?
>
>Yes. Create a node as defined in [a] akin to that in the existing document
>(unless decrypted).
>
>[a] http://www.w3.org/TR/xpath#data-model
>
> > It seems that
> > what we're trying to do is help implementors fix up the resulting XML
> > document, using language that remains consistent with the XPath data
> > model. This may be a futile effort.
>
>It is a difficult task, but our critical requirement is to be able to
>"decrypt-and-replace". If we can specify it abstractly and still have
>interoperable results: good.
>
>What would you like to see Ari? Do you feel the present Candidate RECs are
>approriate and we should add necessary warning/limitations text? Do you
>have more specific text in mind?

Received on Tuesday, 18 June 2002 13:43:31 UTC