W3C home > Mailing lists > Public > xml-encryption@w3.org > September 2002

Re: Decryption transform interop samples

From: Joseph Reagle <reagle@w3.org>
Date: Wed, 11 Sep 2002 16:07:13 -0400
To: merlin <merlin@baltimore.ie>
Cc: "Takeshi Imamura" <IMAMU@jp.ibm.com>, xml-encryption@w3.org
Message-Id: <200209111607.13738.reagle@w3.org>

On Wednesday 11 September 2002 02:44 pm, merlin wrote:
> I'm inclined to stick with what we have: Our processing
> basically mirrors xmldsig (some customers do indeed need
> XPointers), and we leave implementors the option of going
> to great lengths to dereference XPointers into replacement
> node sets if they want. 

I'm going to agree. The implementation requirement is to ensure the text is 
well written and to show some evidence of support for the feature. I can't 
forsee any interop problems arising from this (we're just borrowing from 
xmldsig) and the fact that there were enough (optional) full XPointers 
implementations in xmldsig is more relevant to whether we include them here 
than whether we get more implementations in the XENC WG.

> This need will only arise in the case
> that a decryption transform uses a full XPointer and partial
> encryption subsequently occurs to break the exception. I
> don't see this being a common problem. There are many ways
> that partial encryption may break a signature, and this is
> just another of those cases; we provide a warning about the
> use of XPointers in such cases.

The processing text in the edtiors' draft now includes a forward reference 
to the warning.

> In XMLDSIG, the URI #foo is always evaluated in the context of
> the signature document. 

What is confusing me here is the term "signature document". Do we mean the 
document identified by the Reference URI? Or the document that the 
signature occurs in?

Presuming we mean the Reference URI, I've tweaked the text to read, " the 
exception URI may be evaluated against a different document than that 
identified by the ancestor Reference URI."
Received on Wednesday, 11 September 2002 16:07:48 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 27 October 2009 08:42:21 GMT