Re: Attribute encryption

>Can you be more concrete, with an XML + schema example, to demonstrate why Attribute encryption is required for this application?
I apologize for sticking to generalities, but the particulars of the scenario are as follows:
- the system is "legacy", ie, there is a big installed base, so it is impractical to change the XML Schema
> Sounds pretty much like straightforward separation of information into header and body sections.
- the schema was not designed originally for a straightforward separation.
Thus lets say the XML is as follows:
   <receiverInfo SocSecNum="secret stuff>
         <receiversHostname>
                abcd
         </receiversHostname>
   </receiverInfo>
As we all know SocSecNum are very private data, and B may not see it, but B needs to access receiverInfo/receiverHostname.

After encryption, this becomes
   <receiverInfo >
         <.... encrypted attribute...>
         <receiversHostname>
                abcd
         </receiversHostname>
   </receiverInfo>
The doc is no longer valid against the original schema, but B can still resolve the Xpath (receiverInfo/receiverHostname) properly.
As you pointed out, the choice is still between encrypting the attribute, and pre-transforming it.  Philip Hallam-Baker has already expressed his preference on that.

However, my argument is still mainly one for consistency: attribute values should get the same treatment as element content - if one can encrypt children of an element, then one should be able to encrypt its attributes.
>The argument in favor of attribute encryption seems to based on the notion that a receipient can take advantage of the existance of a >known Element in some legacy schema, even if its attribute values are opaque. I have trouble with this argument.

I did not understand this.  Can you please clarify?

I also now realize that my original proposal does not address the example I have cited above.

regards

SSH