Superannuation Profiles

["Pim van der Eijk" <pvde@sonnenglanz.net>]

 

Hello,

 

In the last call we discussed a few questions of the Australian Tax Office on their profiling of ebMS3/AS4.  Since I am working on similar topics,  I've had another look at them, here is some more detailed feedback:

 

1) use of Pmode.ID and AgreementRef.

 

As it was explained to us,  ATO have identified several sub-profiles and want parties to be able to select,  in a message, which specific sub-profile a message initiator is using.    To do this,  they define default agreements (chapter 5 of their "Message Orchestration and Profiles" document http://www.ato.gov.au/download.asp?file=/content/downloads/SPR_00335171_Attach7.pdf) with specification values for several PMode parameters (Appendix in same document).  Two values they are setting in this way are the AgreementRef and PMode.ID values.  In their "Ultra Light Profile", they are setting the value for PMode.ID to "Push".     An MSH will have different PModes for different business partners, services and actions.  In the ebMS 3.0 Core Specification, the PMode.ID value is required to be unique within an MSH and to uniquely identify a specific PMode (see definition in D.3.5.1.).  This seems to preclude the use of a single generic value for PMode.ID with almost any real-life deployment.  The superannuation profiles rely on UsernameToken security,  which implies a bilateral agreement between sender and recipient.  As there is a bilateral agreement step anyway,  selecting a specific sub-profile could be part of that process. 

 

The OASIS BDXR TC is looking at supporting requirements of large and dynamic communities and might have some solutions over time.

 

2)  PartID 

 

The profiles mandate a PartID property.   We commented that MIME parts already have a unique identifier (the MIME Content ID) defined in 5.2.2.13 of ebMS 3 Core, which has a globally unique (not just in the message) identifier. Neither ebMS3 nor AS4 say whether it is expected that a submitting application can set the value for a MIME part, but Appendix C of the Core Specification shows an example where an XML business document (not the the ebMS3 header) has a reference to a named part.   MIME libraries and the few ebMS3 implementations I have worked with all support this.  So instead of the PartID property the href value could be used. 

 

In the teleconference it was explained that this property is used to be able to reference specific parts in error messages.  If those errors relate to business processing,  then another option could be to design the relevant XBRL business document schemas to have internal identifiers and address the correlation only at the business level.

 

3)  MPCs and pull with AS4 light client

 

The AS4 light client profile does not require support for additional message partitions (other than the default one) per 2.2.1 of the spec.  The way pulling works with MPCs (see v3 Core section 3.2), an MPC is like a FIFO queue where any client authorized to pull from an MPC has access to messages submitted to that MPC.  So if an AS4 MSH has more than one partner that gets messages by pulling, different MPCs would be needed to make sure one partner does not pull a message intended for another partner. (There are some enhancements for this defined in part 2: subchannels and selective pulling, but AS4 does not use them) Analogously to Push mode,  where the sender would post message to different HTTP addresses, with Pull the sender could assign them to different MPCs.  A profile could adopt a naming convention for MPCs,  e.g. include the partner party ID ABN or party name in the MPC URI string value.  

 

If we ever revisit AS4, we may want to require support for multiple MPCs with the light client as this is a common requirement, and support for more than one MPC is not a "heavy" feature.

 

Pim