- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Wed, 31 Jan 2001 16:46:03 -0500
- To: Blair Dillaway <blaird@microsoft.com>, Ed Simon <ed.simon@entrust.com>, Phillip hallam-Baker <pbaker@verisign.com>
- Cc: "Public XML Encryption List" <xml-encryption@w3.org>
In a previous message I wrote: >http://lists.w3.org/Archives/Public/xml-encryption/2001Jan/0058.html >I'm also wondering if there's a middle ground between Blair/Phil/Thane's >point of view and Ed/Steve/Sanjeev's point of view so the WG could migrate >its design if need be once we start getting wider review, and I suspect >this would also serve the effort of hitting the end user sweet spot of >scope versus complexity (forcing attribute encryption implementation on >everyone versus abandoning the requirements of a part of the community.) I've been thinking some about the above with the idea that a good proto design (on something contentious) is one in which a change in requirement (supporting, or not, attributes) does not necessitate replacement of design, but migration. So I've been wondering what exactly are the differences required by Ed's proposal and wondering how complex they are compared to the alternative: Ed's proposal: 1. requires a EncryptedDataManifest (since there now can be more than one chunks of encrypted data for an element). Easy. 2. a Name attribute which identifies the resource for whom the ciphertext applies. 2.1 This could be a Name for which the processor then needs to do a match: go parse the tree for an attribute with this name. I'm unsure of the complexity but it would need more specification as attribute names themselves are not guaranteed to be unique. 2.2 This could also be an XPath which is more straightforward, but then requires XPath. 2.3 This also would be useful for "detached" encryption -- not being required to always place the EncryptedData in the document Encrypted. This could be a feature, and a source of bugs as we already have bidirectional key indirections and it could get complicated... Alternative: The one alternative that come's to mind is that if an application has heterogeneous sensitivity across elements/attributes, it should transform it into a simple XML (where everything is represented as element+content). Would this necessitate XML Encryption add the feature of Transforms? __ Joseph Reagle Jr. http://www.w3.org/People/Reagle/ W3C Policy Analyst mailto:reagle@w3.org IETF/W3C XML-Signature Co-Chair http://www.w3.org/Signature W3C XML Encryption Chair http://www.w3.org/Encryption/2001/
Received on Wednesday, 31 January 2001 16:49:48 UTC