W3C home > Mailing lists > Public > www-xenc-xmlp-tf@w3.org > December 2001

Re: XMLP Comments to XMLE LC

From: Hiroshi Maruyama <MARUYAMA@jp.ibm.com>
Date: Wed, 19 Dec 2001 18:32:15 +0900
To: reagle@w3.org
Cc: "David Orchard" <dorchard@bea.com>, <w3c-xml-protocol-wg@w3.org>, "'xenc'" <xml-encryption@w3.org>, www-xenc-xmlp-tf@w3.org, "Satoshi Hada" <SATOSHIH@jp.ibm.com>, "Takeshi Imamura" <IMAMU@jp.ibm.com>, "Maryann Hondo" <mhondo@us.ibm.com>
Message-ID: <OF0E6C9F4E.884105CC-ON49256B27.0032AD0D@LocalDomain>


>We need people from communities with their applications
>requirements/scenarios in mind to then test those requirements/scenarios
>with our specified functionality.
>If anyone has scenarios or questions in mind please join and contribute
>www-xenc-xmlp-tf@w3.org .

We have been looking at applying XML Encryption to SOAP envelope.  The
following is an example of SOAP header for XML encryption that we are
considering.  The point here is that the receiving SOAP application knows
what <xenc:EncryptedData> elements are to be decrypted.  When the
<SOAP-SEC:Encryption> element is combined with <SOAP-SEC:Signature>, the
use of the decryption transform solve the interdependency problem.  Also
our scenario includes encrypting SOAP attachments through a "cid: ..." URI.
(such as cid:image.jpg).

        <SOAP-SEC:EncryptedDataReference URI="#encrypted-body-entry"/>
      <xenc:EncryptedKey>  ...  </xenc:EncryptedKey>

  <SOAP-ENV:Body >

We have (somewhat older versions of) draft spec and implementation in Web
Services Toolkit available from IBM alphaWorks.  See the following link.




Hiroshi Maruyama
Manager, Internet Technology, Tokyo Research Laboratory

From: Joseph Reagle <reagle@w3.org>@w3.org on 2001/12/19 07:24

Please respond to reagle@w3.org

Sent by:  xml-encryption-request@w3.org

To:   "David Orchard" <dorchard@bea.com>
cc:   <w3c-xml-protocol-wg@w3.org>, "'xenc'" <xml-encryption@w3.org>,
Subject:  Re: XMLP Comments to XMLE LC

On Friday 14 December 2001 19:01, David Orchard wrote:
> Can you repost the scenarios, and I at least guarantee that I will
> respond?

My "anonymous forwarder" contribution is

I welcome comments, modifications, and other scenarios. If folks pitch in
and we get a couple scenarios with some discussion on each from folks
familiar with xenc and xp, we can pull them together into a document.

> I understand why you would consider usage scenarios optional.  But
> another perspective is that if you ask me (speaking for myself, not xmlp)
> to review a doc and I say I don't understand how it works

The XML Encryption specification should explain how XML Encryption works.
It has an Overview with simple examples/scenarios:
  [2] http://www.w3.org/TR/xmlenc-core/#sec-Overview
If it doesn't sufficiently explain how to encrypt an element or element
content then we need to improve the spec.

Protocol requirements and scenarios are best known by XP folks. (I expect
my old cypherpunk imaginings are quite far removed from what people are
doing with SOAP today!) For instance, from [1] does anyone in your
community care about an anonymous remailer type service? From your
understanding of the XP domain will people want to encrypt payloads only,
headers, both? Do people want to recursively encrypt/process encrypted SOAP

blobs? (For instance, a SOAP payload is an EncrypedData, after you decrypt
it you have a complete SOAP message again in hand with its own header and

We need people from communities with their applications
requirements/scenarios in mind to then test those requirements/scenarios
with our specified functionality.

If anyone has scenarios or questions in mind please join and contribute to:

www-xenc-xmlp-tf@w3.org .

Subscribe: www-xenc-xmlp-tf-request@w3.org
  In Subject: (un)subscribe


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, 19 December 2001 04:32:56 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:07:14 UTC