RE: [ebxml-msg] RE: [ebxml-cppa] ebMS 3.0 draft configuration examples.

.....

- If an organization wants to use CPA to configure MPC channels to be polled by partners, do we need a restriction that a specific channel can only be pulled by one organization, or more precisely, can only be defined by one (active) CPA? Otherwise the server from which messages are polled would need to inspect all active CPAs for the MPCs they define, to build an access list (e.g. usernames and passwords ) for each of the MPCs.

Dale>> I recall that the ability for several parties to pull from a given MPC queue, er, channel was requested and was justified by end user requirements having been given.

I think that authorization is the main gatekeeper to access on a MPC. Looking up CPAs would probably have to be keyed off of the authorization credentials. So I think that the use cases actually would mean that multiple CPAs may be associated with a given MPC. I understand your concern about checking CPAs but normally CPAs are stored in a RDB and various indices over the information support rapid access as needed (often with a runtime cache!)

Jacques>>The TC thought about possible pulling options and decided to not open the pandora box of query expressions (if pulling based on eb:Party/From, why not then based on Service & Action? message properties? etc.) It then opted for the simplest solution - requiring all selective pulling to be done on the basis of distinct MPCs. So yes, per party pulling would require to use an MPC per Party/From. This can be implementation-configured (P-mode) so that a sender only needs to ifentify itself as a Party/From to its MSH so that the latter can determine which MPC must be assigned.

On the other hand, there is the use case where an MSH may pull from teh same MPC on behalf of several parties, and even the case where several distinct MSHs will pull from the same MPC (e.g. a distributed support center processing trouble tickets).

Authorization at MPC level is the mechanism to use (see section 7.10 "message authorization") : an MSH is required to support enforcing some access control to its MPCs. This can be based on credentials different than those used on a per-Party (per-CPA) basis, meaning access control credentials in addition to their own used for general authentication. For example, a shared password will allow access to the same MPC, in addition to each party signing/encrypting their messages differently. Some practical considerations led to this 2-tiered security processing.

- More an ebMS3 question perhaps: Thinking about this further, shouldn't the default ebMS3 MPC a partner pulls from be something like

"http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/PartyType/PartyId" rather than "http://docs.oasis-open.org/ebxml-msg/ebms/v3.0/ns/core/200704/defaultMPC"?

The specification currently has the value in the samples as the default MPC value. I will copy this response to the ebMS TC list to let them be aware of this comment. Certainly a community can organize itself around the convention you suggest.

Jacques>> the meaning of default MPC, is just that if you do not mention it at all in the message header (either for pulling, or for pushing) then the one being automatically used is the default. Because an MPC is not restricted to a pair of partyIDs, we can't be more specific in the default name... also we need keep in mind that pulling is usually on the initiative of an MSH, not a partner (might be several partners behind the same MSH). Many partners will remain unaware whether the messages delivered to them have been pushed or pulled.

-Jacques

ebxml-msg message