Notes from 1/27, F2F Day 2

[Pete Wenzel <pete@seebeyond.com>]

Notes from 1/27, Day 2 of F2F
-----------------------------
Guests Present:
  Alan Weissberger, NEC
  Hamid Ben Malek, Fujitsu

> 2. Review and completion of WS-Security inclusion

** Issue: Do we want to require support for complete attachment signing,
  or attachment content only?
** Issue: Do we want to require support for encrypting attachment content
  only, or content and headers?

Jeff recommends that in both cases, we require a minimum of content-only,
for interoperability purposes.  General agreement.

** What, if anything, do we need to say about SOAP intermediaries?
  WS-Reliability does not address them (its headers are end-to-end only).
  Any other intermediary header processing will be transparent, as far
  as the MSH is concerned.

If we no longer have a need for ebMS intermediaries, NextMSH actor can
be removed; this also simplifies the XPath transform used for enveloped
signing of the SOAP envelope.

What about actor=next?  Do we need a second signature to protect those?
Maybe, but it would be the responsibility of whoever added the such
elements also to add a separate signature targeted at next, which is
verified by intermediary.

The enveloped transform is easy to use and specify, but WS-Security
advises against it (SHOULD NOT).  An alternative is to include a Reference
for each element to be signed in the Signature block.  (This includes
the path and hash of each element.)

** Issue: This allows insertion of headers by a man-in-the-middle,
although they would be unsigned.  Is this a security risk that we wish
to disallow?  Should we require that receiver only honor headers that
are signed and trusted?  (This is a change from the 2.0 signature
functionality, which would fail completely if headers were inserted.)

** Which headers do we encrypt?  Include WS-R headers?  Consider SOAP
  Intermediaries, and access to headers that they require.

Is it true that we cannot encrypt eb:To and eb:From, needed for routing
purposes?

Do we need to have an exposed header to identify a message as being ebMS?
Probably not, as long as we mandate that Security headers are processed
(and relevant decryptions occur) prior to ebMS headers.

In other words, Reliability headers need to be exposed/made available to
the Reliability processor.  And ebMS headers need to be made available
to the ebMS processor.  We need to be careful that our wording does not
dictate any specific implementation model.

Can we say anything more specific than, "encrypt whichever elements
(and/or attachments) you wish"?

Hamid would like to enable a processing model in which selective,
"just-in-time" decryption can be performed in stages.  So encrypted
elements need to be identified in some manner, in order to decide which
ones a particular processing stage wishes to decrypt.

** Conformance: What do we want to require, as far as a base level of
security functionality?  We've already agreed that Reliability is a
required core feature; in 2.0, it was optional, but has conformance
requirements for those who choose to implement it.

We could state that all headers that exist at the time our security
mechanisms are applied MUST be signed, for example.  Or leave it up to
a policy / service agreement?  CPA issue; can CPA express this?

Proposal: State that if signing is done, sending MSH SHOULD sign all
elements and attachments.  Same for encryption.

** Possibly need to recommend method(s) of key identification.
Embed or reference certificate/BinarySecurityToken?

** Issue of determining whether or not policy has been adhered to.
(In other words, will we require that conformance to CPA be validated
on the receiving side?)  We did in 2.0.

** Need to discuss composability of WS-Security & WS-Reliability further?


> 3. Completion of Payload services

Email from Doug includes a question about complexity of PayloadInfo
and Processing.

Agreed to remove the PayloadInfo container element and move Payload to our
top level.  Keep the name PayloadInfo for the element, however, instead
of Payload.  Similarly, collapse Processing and Step elements into
ProcessingStep.

Jacques wonders whether we need to specify that some steps may be done
in parallel.  Agreed to keep it sequential; no need to introduce this
level of workflow complexity.

** Is there a need for overall payload processing steps, or do we only
need them per payload, as in the current schema draft?  If we need to
add overall steps, how do we specify sequencing constraints between these
and the payload-specific steps?

Agreed to remove sequence attribute; rely on element order to specify
processing step order (as well as payload processing order).
Specify that element order dictates processing sequence.


Agreed to specify Payload Services module in the main spec; concretize
examples and move them to an appendix.

PreProcessing/PostProcessing have been removed.  Sender needs to obtain
its processing instructions from somewhere (e.g. CPA); message contains
only the receiver's processing instructions so that the necessary message
self-describes its processing requirements.

Potential user requirements for Payload Services:

Jacques believes we have a requirement for handling "batched", unrelated
payloads within a single message.  One use case is to apply encryption
or compression to the entire batch as a whole, rather than to each
payload individually, which can be much more expensive.  To accomplish
this, we could either predefine a Service/Action that recursively
unbundles multiple payloads and submits them as individual messages,
or specify a payload service that does this.

Doug wonders whether there is really a need for such EDI-style batch
processing.

Jacques wonders about chunking/packetizing very large messages, and
defining a reassembly service.
Also notes requirement for flow control, or store-and-forward signaling
with occasionally connected parties.

As long as we're discussing potential requirements, Doug reads through
our 10/2002 requirement list to see if we've missed anything.


Discussion about status of WS-Addressing, and potential for using it
for our addressing & routing needs.

** Issue:  When an MSH receives a message, how does it know whether it is
participating in a simple push MEP (in which case there is no response),
or a sync req/resp MEP (in which case it maintains the connection until
the response is available to be transmitted)?  (There is no indication
in the message header.)  Possibly need to re-add the SyncReply element.

** Corollary: When a message is Submitted to MSH and it contains a
RefToMessageId, how is/was it determined what the callback address is
to deliver this response?  CPA?  WS-Addressing ReplyTo element?


> 4. Complete review of specification identify outstanding work
>    Examples
>    Bindings
>    Appendices

** Rename 5.4 "Modes of Operation" to something more accurate.

> 5. Requirements for future work and F2F

> 6. BPSS alignment & CPA version control / identification

-- 
Pete Wenzel <pete@seebeyond.com>
Senior Architect, SeeBeyond
Standards & Product Strategy
+1-626-471-6311 (US-Pacific)