- From: Joseph M. Reagle Jr. <reagle@w3.org>
- Date: Thu, 01 Feb 2001 14:09:47 -0500
- To: Philip Hallam-Baker <pbaker@verisign.com>
- Cc: "'Ed Simon'" <ed.simon@entrust.com>, xml-encryption@w3.org, eric@w3.org
At 08:53 1/9/2001 -0800, Philip Hallam-Baker wrote: >> I am in agreement with following provisos: >> >>1. I definitely agree we should allow the use of XSLT to allow >> encryption or arbitrary fragments, such as attributes, >> but I don't think we should make it >> required for encrypting attributes (if indeed the WG >> decides encrypting attributes is a good idea). Though >> I'm a big fan of XSLT, I'm not convinced it is the best >> approach for supporting attribute encryption. > >No, in mode 2 you design your schema to the constraints of the XML >encryption standard so that it will work without XSLT transforms. The >choice of attribute or element with attribute is an arbitrary one. The >choice of element data over attributes appears to have fewer constraints. This really isn't to the points addressed by you and Ed, but I was thinking that if attribute encryption is not supported and we recommend a transform approach for XML with sensitive data in attribute values being transformed into SimpleXML (no attributes, everything is an element or content) before encryption: original -> SXML -> Encrypted SXML ||| -> Decrypted SXML -> original 1. Does this necessitate the use of transforms in Encryption? Or would the namespace of the SXML instance "mean" (be associated with) the requirement to use a particular XSLT to reverse the process? 2. Since the goal of partial encryption is to keep some information available to intermediary processors who can't (or don't need to) get at the encrypted data, won't the XSML form confuse them -- and defeat this requirement? __ 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 Thursday, 1 February 2001 14:10:21 UTC