RE: [ebxml-msg] Pull, MPC, authorization

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

Hi Theo,

Yes partly triggered by your emails and also because we
touched on it in a previous call (but postponed discussion).
My goal was to provide some context for discussion at an
upcoming call.

By "simple dequeue",  I mean: the MPC pull service provider
should only have to check whether the puller is authorized
to pull the MPC.   Not to also have to sub-partition
messages on the MPC based on "user" and to return different
messages depending on who pulls rather than e.g. the first
or an arbitrary one.  But perhaps this can be viewed as an
implementation choice (for the pull provider), as it only
constrains configurations and does not affect
interoperability.

Pim 

-----Original Message-----
From: Theo Kramer [mailto:theo@flame.co.za] 
Sent: 05 August 2013 16:46
To: Pim van der Eijk
Cc: ebxml-msg@lists.oasis-open.org
Subject: Re: [ebxml-msg] Pull, MPC, authorization

Hi Pim

I've been following this thread with some interest and was
wondering if this was triggered by the conversation on the
list between Rong and myself on this ?

Some of my thoughts and views on pull authorisation from a
practical point of view and within the scope of the question
(ie. interpretation of behavior of an MSH implementing Core
Spec pulling' for the AS4 profile are as follows.

Sub-channels are an optional feature for the AS4 profile
particularly for use in multi-hop cases and my view being
that these need only be considered in cases where multi-hop
is a requirement.

There are use cases for 'broadcasting' the same message to
multiple pulling partners eg. RFQs.

Authorisation, either by UT or by Signature, on pulling from
MPCs is a practical requirement in that pulling partners
should not be able to pull messages (and in the process
delete these from an MPC) if the message is not intended for
them.

Configuring multiple separate P-Modes, each with a separate
MPC, for cases where a large number of pulling partners
exists is not practical.

Chapter 3 of the core spec does not mention the ability of
partitioning messages on a single MPC based on the "user" in
the user token as per your email below. 

Chapter 3 does state 'organizing the inflow of messages on
receiving side, so that each flow can be consumed in a
distinct way, yet without having to filter messages based on
various header elements or payload content', but does
inflow, and organisation of received messages, not indicate
the context of the receiving (pulling) msh once pulled
messages have been received ?

Chapter 3 also states the following ... 'It does not
prescribe a particular way to implement MPCs or [how] to use
them.' and 'There is no specific quality of service
associated with an MPC. Security and reliability remain
associated with parties or with MSHs, in a way that is
orthogonal to MPCs; although an implementation is free to
associate QoS with MPCs as long as this conforms to an
agreement between parties."

 . so in reading Chapter 3, and the AS4 profile, I see
nothing that prohibits or recommends against partitioning
messages within an MPC by user .

Also pull requests without credentials (UTs and/or unsigned
pull requests) or with shared UTs should be able to pull
messages for basic pull functionality as you mention below.

For the question asked in EBXMLMSG-20 I see the following
possibilities

a - return P1.
b - return empty MPC (EBMS:0006)  if only P2 messages are
available.

I don't think that (a) goes against the notion of 'simple
dequeue' surely. ?

On 04 Aug 2013, at 11:58 , Pim van der Eijk
<pvde@sonnenglanz.net> wrote:

> Hello Jacques,
>  
> Sub-channels and the Part 2 selective pulling are useful
features.   But the question is about correct interpretation
of behaviour of an MSH implementing the Core Spec pulling.
Also see
https://tools.oasis-open.org/issues/browse/EBXMLMSG-20.   It
seems at least one product is implementing a kind of
sub-channels by sub-partitioning messages within an MPC
based on the "user" in the user token.   Chapters 3 and 7 of
the Core Spec do not seem to be fully aligned on this, with
chapter 3 not mentioning it at all.
>  
> If we want basic Pull functionality to be simple and
implementable using simple mechanisms like FIFO queues,  any
pull client authorized to pull from an MPC should be
authorized to pull all messages in that MPC.  
>  
> It would be great if we can discuss this at an upcoming TC
call.
>  
> Pim

--
Regards
Theo