- From: Joseph Reagle <reagle@w3.org>
- Date: Fri, 2 Aug 2002 12:39:38 -0400
- To: XML Encryption <xml-encryption@w3.org>
http://www.w3.org/TR/2002/CR-xmlenc-core-20020802/ ... This version now includes (1) clarifications resulting from current implementations, see Interoperability Report, (2) a media type registry application, and (3) non-normative changes resulting from work on the XML Signature Decryption Transform [XML-DSIG-Decrypt]. In particular, informational (non-normative) text for implementing decrypt and decrypt-and-replace operations were moved to this specification's Encrypting XML (section 4.3). The exit criteria for this phase continues to be at least two interoperable implementations over every feature, one implementation of all features, and one report of satisfaction in an application context (e.g., SOAP, SAML, etc.) Present implementations must update their implementation of [XML-DSIG-Decrypt]; we will continue to solicit new implementations. We expect to meet the exit criteria within 6 weeks (closing 13 September 2002). Specific areas where we would appreciate further experience are: * Do implementations achieve satisfactory performance? * Does the specification satisfy application scenario requirements for encrypting portions of XML, particularly as they relate to document validity? http://www.w3.org/TR/2002/CR-xmlenc-decrypt-20020802 ... This version is a signficiant revision: the processing steps have been rewriten, a binary mode has been added, and many more examples and explainations have been included. Consequently, this specification uses a new namespace/identifier for the transform. ... Specific areas where we would appreciate further experience are: * Do implementations achieve satisfactory performance? * Does the specification satisfy application scenario requirements for encrypting and signing portions of XML? * Do implementors plan on supporting full XPointer expressions in the Except URI, particularly when they identify nodes resulting from super-decryption (i.e. the replacement node-set)? * Presently the specification states signature processing must fail if decryption fails; should this be relaxed such that in some cases processing can continue?
Received on Friday, 2 August 2002 12:39:59 UTC