MTG Management Consultants, L.L.C.
www.mtgmc.com
(206) 442-5010 Phone
(502) 509-4532 Mobile
Helping our clients make a difference in the lives of the people they serve.
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. If you received this in error, please contact the sender and delete the material from any computer.
Sent: Wednesday, January 29, 2014 8:05 AM
To: James E Cabral, Jim Harris
Cc: Bob Slaski
Jim & Jim – The Springboard ECF “Test Harness team” has completed its review of the ECF spec and only has two additional items to add to the 17 that were included in the original QA Review document. I’ve included descriptions of them below (scroll down) so you can distribute them as needed to the ECF TC.
As promised in an earlier email, we have provided additional details describing the WSDL “empty Operation” issue. Resolution of this issue will have an impact on Springboard ECF conformance testing, and we are assuming that the recommendation will be adopted as stated. But it’s not blocking progress, and if the ECF TC chooses to go another direction, it wouldn’t be too much of a burden to switch back.
This completes the formal QA work of the initiative team, and no additional items are anticipated from the initiative. If any additional items are discovered as the program moves into steady-state conformance testing, I’ll be sure to share those at that time.
I’ll add these two new items to a new version of the QA Review document in the coming weeks, bringing the total to 19. I’m modifying the language at bit, though, to try to be more consistent with the mainstream IT interoperability certification lexicon. But this may take a while… finding authoritative dictionaries is proving to be more of a challenge than I had hoped.
Let me know if you have any questions in the meantime. Thanks.
===
Issue
WSDL soapAction=””
Issue Details:
·
The ECF v4.0 WSDL specifies an
empty Operation soapAction
· The empty WSDL “soapAction” is acceptable when the web service relies on simple url-based addressing. If the web service leverages WS-Addressing (WSA), however, an empty “soapAction” will cause web service communication issues because the “wsa:Action” element is required and cannot be empty.
Suggestion:
· Update the ECF v4.0 WSDL to include a soapAction value that is unique across the service definition.
o Consider using a <namespace>\<port>\<operation> naming syntax:
· “urn:oasis:names:tc:legalxml-courtfiling:wsdl:WebServicesProfile-Definitions-4.0\FilingReviewMDEPort\ReviewFiling”
· Since the ECF v4.0 WS SIP references specifications, such as Reliable Messaging, that include WS-Addressing, we recommend updating the WS-I Basic Profile reference from 1.1 to a newer version (1.2 or 2.0), which includes WS-Addressing.
· If the soapAction is added to the WSDL, existing sites will need to update their service definition to use the new WSDL.
Future Consideration
Signature References
Comments:
· The ECF Core Specification Section 1.3.3 “W3C XML-Signature Syntax and Processing” references the W3C XML Signature Syntax and Processing ([XMLSIG]) specification along with the “ECF 4.0 XML Document Signature Profile”.
The W3C XML Signature Syntax and Processing ([XMLSIG]) specification describes a mechanism for signing electronic documents. This mechanism allows recipients of electronic documents to identify the sender and be assured of the validity of the electronically transmitted data. [XMLSIG] defines standard means for specifying information content that is to be digitally signed.[1]
ECF 4.0 employs the [XMLSIG] specification to describe digital signatures applied to the entire ECF 4.0 message transmission in order to provide authentication, encryption and message integrity. [XMLSIG] is also used in the ECF 4.0 XML Document Signature Profile.
· The section poses two issues that merit consideration:
o The ECF Core Specification does not have a definitive reference/link to the “ECF 4.0 XML Document Signature Profile”.
o The section commingles the signing of SOAP-based message transports with the signing of an individual document component. Since the two signature concepts are implemented for different purposes, combining the discussion into a single paragraph is confusing for the reader.
· The ECF Core Specification would be more straightforward and easier for a reader to read/developer to implement, if the document:
o provided a definitive reference to the ECF XML Signature Document Signature Profile with the correct version (3.0).
o clarified the intent, purpose and role(s) of the two digital signature conventions: W3C XML Signature Syntax and Processing and the ECF XML Signature Document Signature Profile.
=====
Scott Serich, PhD, JD
Lead Technical Architect, IJIS Institute
44983 Knoll Square, Ashburn, VA 20147-2692
703.283.3432 -- scott.serich@ijis.org -- www.ijis.org
=====