W3C home > Mailing lists > Public > xml-encryption@w3.org > January 2001

Re: Attribute encryption

From: Sanjeev Hirve <shirve@cyberelan.com>
Date: Mon, 8 Jan 2001 15:11:16 -0500
Message-ID: <0dc101c079af$28f8de10$0800010a@cyberelan.com>
To: "Philip Hallam-Baker" <pbaker@verisign.com>, <xml-encryption@w3.org>
Cc: "Michael Sakhatsky" <msakhatsky@cyberelan.com>, "Raju Nadakaduty" <praju@cyberelan.com>, "Marcus A Cuda" <mcuda@cyberelan.com>
>I simply do not agree that Mode 1 has any real utility. XML frameworks are by design flexible. If there is a need for backwards >compatibility then XSLT can be used to paper over any inconsistency. Viz

Yes, it is always possible to use Transformations or other means to cater for any feature/function not supported directly by the encryption standard.  So the question is really whether a feature should be mandated by the standard.  If a commonly required feature is excluded we run the risk of losing inter-operability or efficiency (I assume a separate transform costs more).
   I am arguing for consistency of treatment.  Sensitive data appear as attributes as frequently as in child nodes.  Whether the standard addresses it or not, applications will have to address it one way or the other.

>Case 2:
>    Message B states only that it is in schema PQR which is the standard schema for the application and incorporates the XML 
> encryption schema. The node encryption was considered at the time the schema was created.
In this case, the schema designer, primarily an business expert, must also tale into account encryption requirements, sometimes there may be conflicting design goals.  This assumption could be fraught with pitfalls.  It may be better to keep security as "transparent" as possible.
Received on Monday, 8 January 2001 15:08:03 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:13:01 UTC