Superannuation Profiles

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