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

complement to Dale, inline.

-Jacques

From: Dale Moberg [mailto:] 

Sent: Friday, July 13, 2007 8:33 AM
To: Pim van der Eijk; 
OASIS ebXML CPPA TC
Cc: 

Subject: [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