OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-msg message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: [OASIS Issue Tracker] Commented: (EBXMLMSG-20) 7.10 Message Authoritzation

    [ http://tools.oasis-open.org/issues/browse/EBXMLMSG-20?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=34346#action_34346 ] 

Jacques Durand  commented on EBXMLMSG-20:

Associating authorization with a particular MPC is convenient from a P-mode definition viewpoint. But it is restrictive in the case a Sending MSH needs to broadcast to a large number of recipients without having to define a different MPC and P-mode for each one.
This issue has been addressed in Part 2 and AS4 with "sub-channels" that allow the pulling to still be authorized per-MPC (i.e. per MPC-subchannel) while the sender doe snot have to worry about all these channels.
This said, the core specification does NOT prevent to selectively authorize the Pulling on the same MPC for different Receiving MSHs then pulling different messages (option (a) in issue text). Indeed the MPC has never been described as a "queue" or FIFO device.

Proposal for errata:

1. In Section 3.4.2, when illustrating the use of MPC4 in example: Add a sentence after:
"Or, two Receiving MSHs (J and K) that are remote from each other but used by equivalent applications may split the processing of messages submitted to the same Sending MSH G."
"The splitting of the message flow may be random in case the two Receiving MSHs (J and K) are equally authorized for pulling any message over MPC4, but it may be pre-determined in case J and K are authorized more selectively to pull different messages from this same MPC."

2.  at the end of 7.10: add: "It must be noted that Pull authorization can be defined on a per-message basis even over a same MPC. As illustrated in Section 3.4.2, the same MPC may be used to send messages selectively to different Receiving MSHs. This applies for pushing as well as for pulling:  two different MSHs with different authorization credentials may pull from the same MPC and get different messages. Pull authorization is ultimately matched to a message profile (e.g. a particular Service , Action or PartyId) as defined in a P-mode. Although in many cases this message profile is reduced to a particular MPC for convenience,  in some cases it may be more fine-grain and allows for selecting only a subset of messages over an MPC."

3. Clarify the definition of error message EBMS:0006 in section 6.7.1: Replace: "There is no message available for pulling from this MPC at this moment." with "There is no message available for pulling from this MPC at this moment, that is authorized for this pulling."

> 7.10 Message Authoritzation
> ---------------------------
>                 Key: EBXMLMSG-20
>                 URL: http://tools.oasis-open.org/issues/browse/EBXMLMSG-20
>             Project: OASIS ebXML Messaging Services TC
>          Issue Type: Improvement
>          Components: Core Spec
>            Reporter: Pim van der Eijk
> This section describes message authorization and states:
> "This Pull signal can effect message delivery from MPC "http://msh.example.com/mpc123"; only if its credentials match the authorization parameters of at least one P-Mode associated with pulling messages on this MPC"
> This raises the following question:   if a pulling MSH1 uses credentials that are valid for messages of Pmode P1 but not for messages of Pmode P2,  but both P2 and P2 are sent on MSH2 on MPC "http://msh.example.com/mpc123";,  and if both a P1 message and a P2 message have been submitted to this MPC (and queued for pulling),  will the pull request (or a series of repeated pull requests) from MSH1:
> (a) return P1 but not P2?    In that case the pulling is not a simple "dequeue" but assumes some filtering of messages on an MPC,  which is 
> (b) return P1 and P2?   In that case the server MSH2 will return P2 messages to MSH1 that violate its Pmode configuration only because MSH1 is allowed to pull P1 messages.
> The simpler option would be to have a one-to-one authorization of pullings MSHs to MPCs,  meaning the authorization is on MPC rather than on PMode.  This can be viewed as a constraint on PMode configurations.

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators: http://tools.oasis-open.org/issues/secure/Administrators.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]