Clarification of F2F minutes

["Scott Came" <scott@justiceintegration.com>]

A couple of items in the face-to-face meeting minutes were a little unclear to me, so for me (and the record), could
we clarify the following:

1.  On page 14, about 2/3 of the way down, there is a paragraph starting with
"Discussion turned to the diagram..."

The way the minutes read, we seem to be deviating a bit
from the terminology used by the WS-I and W3C web services specifications.  I think what is meant by "SOAP
Message Layer" in the strawman actually corresponds to a "SOAP Message Package" (see http://www.w3.org/TR/SOAP-attachments#SOAPMultipart). 
A SOAP Message Package contains the "primary" SOAP message, represented by the Envelope structure in the
SOAP namespace, which in turn contains a set of headers and a body.  The SOAP Message Package can then contain
additional "entities", informally referred to as "attachments," which may be XML text, some other
kind of text (including a textual encoding of binary data, such as base64), or unencoded binary octets (the type of
contents are indicated by the MIME Content-type header).  I find it confusing to include binary data (encoded or
non-encoded) in something called the "XML Data Layer."

The comment in the minutes,
"the...box labeled SOAP Body + MIME (attachments) will be eliminated as redundant," if implemented by the
TC, would I believe result in confusion.  Separating the SOAP Body (and Envelope) from any attached entities is
important, and is intended by the SOAP specification.

I would recommend that we leverage the terminology in
the web services specs, especially in the Web Services Messaging Profile.

2.  On page 15, near the top,
there are two paragraphs, the first starting with "Discussion occurred concerning the security model..."

I agree with the decision to restrict digital signatures to those compliant with FIPS 180-2, though I believe
we should further prohibit usage of SHA1, as it now has well-known vulnerabilities (other SHA algorithms are permitted
by 180-2.)

Regarding the "entity seal" issue...I believe that before this discussion goes
further, we should formally define, in the requirements document, a functional or non-functional requirement that the
entity seal implementation satisfies.  Then we can have the discussion about various implementation techniques. 
(Perhaps we need a refactoring of the non-functionals, especially message integrity and non-repudiation, since I
suspect they no longer reflect the full requirements.  I would advocate keeping the requirements up-to-date, so that
there is justification in the requirements model for everything in Blue.)

Thanks.
--Scott

Scott Came
Principal Consultant
Justice Integration Solutions, Inc.
Olympia, Washington
scott@justiceintegration.com
http://www.justiceintegration.com