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

Fwd: soap-enc scenario

From: Joseph Reagle <reagle@w3.org>
Date: Fri, 21 Dec 2001 11:57:27 -0500
Message-Id: <200112211700.MAA29474@tux.w3.org>
To: www-xenc-xmlp-tf@w3.org
Yves comments (forwarded with his permission):

----------  Forwarded Message  ----------

Subject: soap-enc scenario
Date: Thu, 4 Oct 2001 23:13:58 +0200 (MET DST)
From: Yves Lafon <ylafon@w3.org>
To: <reagle@w3.org>
Cc: <hugo@w3.org>

First the answers:

2/ A node can be multiple actors, and an actor identify one node,
multiple ones, or none. Some "generic" actors are defined, like "next",
when receiving  "next". the SOAP node must act in the role of this actor.
On the opposite,"none" is also defined. [2]
"next" is "http://www.w3.org/2001/09/soap-envelope/actor/next"
"none" is "http://www.w3.org/2001/09/soap-envelope/actor/none"

1/ You can have only one body.
You can either have one body containing the whole thing, targeted at one
recipient, it will process the request as the ultimate recipient, then
will issue another soap request to another one, this way you can do
whatever you want in the body provided the recipient knows how to handle
it.
Another way it to have multiple headers, each one representing one node on
the path, with a header to decipher the body and forward to a specific
next node. In this one, there are multiple ways to encode the body, either
only as a blurb and the intermediary will know how to process that in
order,

<env:Header env:actor="http://example.org/xmlsec/Alice">
  <ds:keyname>Alice</ds:keyname>
  <ds:forward>http://example.org/xmlsec/John</ds:forward>
</env:Header>
<env:Header env:actor="http://example.org/xmlsec/John">
  <ds:keyname>Alice</ds:keyname>
</env:Header>
<env:Body>
       <CipherData><CipherValue>1DEADBEEF</CipherValue></CipherData>
</env:Body>

or have a nested body, like
<enc:encrypted>
  <ds:keyname>Alice</ds:keyname>
  <enc:encrypted>
     <ds:keyname>John</ds:keyname>
       <CipherData><CipherValue>1DEADBEEF</CipherValue></CipherData>
  <enc:encrypted>
</enc:encrypted>

The two options seems to be open, we may ask the soon-to-be-formed
Encoding task force.
The main problem with body processing is that the body is targeted only at
the ultimate recipient. Hugo, what is your pick on this?

My preference would be for the structured body, as it allows also
processing like compression of the body while providing ordering to get
the actual bits to work on.

The correspondance may be done from the header to the body using ids, or
simpy by the implicit ordering done via the actor path (so no strict
correspondance). As an intermediary can remove a header targeted to it, I
would advise against doing inter header references or body->header ones.


[1]
 http://lists.w3.org/Archives/Public/www-xenc-xmlp-tf/2001Sep/att-0000/01-s
oap-sec-scenarios.html [2] http://www.w3.org/TR/soap12-part1/#N40028A

--
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."

-------------------------------------------------------

-- 

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 Friday, 21 December 2001 12:00:06 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:21:54 GMT