I think we can distinguish two authorization issues,
the second one being more a way to prevent errors:
- the general issue of authorizing
the processing of a received message according to a P-mode. As
established, it is not something a WSS module can do by itself without knowledge
about P-modes (or mpfs) as resources to control. Reuse of existing
WSS packages may be tricky or underperforming, as the ebms header processor
will have to access a security token to do this authorization (even when using
UTP or some token reference scheme). But we can consider this an implementation
issue, and assume some access to security credentials by the ebms header processor.
- the specific issue of making
the PullRequest “robust” in the sense that we need to do more
to prevent “inadvertent pulling”. We can’t just rely on
flawless MPF management. A mix-up in allocating MPF ids to different
partners will have serious consequences, e.g. pulling a message that was
not intended to you (and depriving the legitimate receiver), and unlike a
pushed message, there is no additional info in header you can double-check
with. There should be a solution that does not involve WSS when security is
not otherwise needed (given the issues posed by (1))
Proposal for (2):
Associate the claimed MPF with “readable”
information in a Pull signal, that can be used for a consistency check:
- P-mode associated with a PullRequest may contain –
in addition to the MPF - the eb:From that is also associated with this Pull MEP
(i.e. generally matching the eb:To of the pulled message).
- a Pull signal claiming this MPF must then also insert an
eb:PartyInfo that matches the eb:From associated with this MPF.
- corner case: several eb:From share same receiving
MSH (i.e. different eb:To values in messages to be pulled from the same MPF). Because
the role of the eb:From in the pull is just authorization of the MPF –
not selection within the MPF - , no need to use all the possible eb:From values
– just one that is authorized.
-Jacques