Send SOAP messages via WCF with MTOM and Content-Transfer-Encoding: 7-bit

Question

I am trying to send a SOAP message via WCF to the IRS, and it keeps getting rejected because my MTOM attachment is formatted incorrectly.

I've narrowed down the issue to my Content-Transfer-Encoding value. It is set to Binary (shorthand for 8-bit).

The IRS service wants me to use 7-bit, with an 8-bit-encoded attachment (in other words, encode with UTF-8 and then guarantee that I'm not using any non-ASCII characters).

I'm already using a custom message encoder in order to gzip my requests (responses come back plain-text, ugh). This is what my WriteMessage looks like right now.

public override ArraySegment<byte> WriteMessage(Message message, int maxMessageSize, BufferManager bufferManager, int messageOffset) {
    // get an instance of the underlying encoder
    var encoder = new MtomMessageEncodingBindingElement() {
            MessageVersion = MessageVersion.Soap11WSAddressing10,
            WriteEncoding = System.Text.Encoding.UTF8
        }.CreateMessageEncoderFactory().Encoder;

    // write the message contents
    var uncompressed = encoder.WriteMessage(message, maxMessageSize, bufferManager, messageOffset);

    // compresses the resulting byte array
    return CompressBuffer(uncompressed, bufferManager, messageOffset);
}

Any ideas? When I change the WriteEncoding property to ASCII or UTF7 .NET throws an ArgumentException and tells me the format is not supported.

Flannel

I think that the 8-bit encoding is less of an issue after some more research than is the fact that MTOM is trying to encode the WSS security header (which is causing the certificate to get optimized into an MTOM attachment). This is being done by WCF out of my control, so I'm looking into writing a custom message encoder to overcome it. Hopefully someone here can give me a better answer, if it exists, before I get too far in :) – Flannel

Answer 1

I am using Java Apache CXF and WSS4J for the IRS solution, but if you are getting this error "The message was not formatted properly and/or cannot be interpreted. Please review the XML standards outlined in Section 3 of the AIR Submission Composition and Reference Guide located at https://www.irs.gov/for-Tax-Pros/Software-Developers/Information-Returns/Affordable-Care-Act-Information-Return-AIR-Program, correct any issues, and try again." it is because the IRS is expecting this:

Content-Type: application/xml
Content-Transfer-Encoding: 7bit
Content-ID: <6920edd2-a3c7-463b-b336-323a422041d4-1@blahurn:us:gov:treasury:irs:common>
Content-Disposition: attachment;name="1094B_Request_BBBBB_20151019T121002000Z.xml" 

Forequarter

After what we've been through via .NET and WCF, this is probably by far the simpler approach. I've heard about people using Java having issues signing, but more than likely they just don't understand SOAP security. – Flannel

Answer 2

It appears the built in MTOM encoder in WCF will not encode a request compatible with the IRS service. It encodes whatever it finds in the request that's base64 encoded including the BinarySecurityToken in the signed request. I was able to get a request closer to IRS requirements by creating a custom encoder. Within WriteMessage, you can append and prepend MIME separators and reencode the file as an attachment. An outgoing message inspector is required to properly set the headers: https://blogs.msdn.microsoft.com/carlosfigueira/2011/04/18/wcf-extensibility-message-inspectors/

Crossbow

I believe you are correct. I took a slightly different approach and just reversed the parts of the result of MTOM encoding that I didn't want. I'm still working to get the request accepted at present, but the error I'm now receiving isn't reproducible by the IRS using my raw request on their end. I've got a call scheduled with them today to find out what the problem is (hopefully). Thanks for chiming in! If the current solution I'm using doesn't work I'll try your method. – Flannel

Very interested to know if you got this working with C#. I got very close with the custom mtom encoding approach, but now receiving an error message when they parse the request:<errorcode>TPE1106</errorcode> <faultdetails> Invalid content was found starting with element 'Signature'. No child element is expected at this point</faultdetails>... Since the only signature element is within the security token and security has already been validated, I assume the IRS starts parsing thru the envelope headers. Perhaps because the .NET security headers don't have wsse namespace, its throwing this error. – Crossbow

I got MTOM working (had to really hack apart WCF to get it working), and now my security header is invalid because of what I did to the message after MTOM encoding. I will report back in a couple hours after I (re)implement manual signing of the message. – Flannel

Seems the entire .Net community is starting to converge on these solutions around the same time. Very interesting to see these updates :) – Eggbeater