RE: [bdx] SMP and CPP

Pim, Dale, Mike et al,

In addition to the CPP/SMP differences you mention, Pim, it seems to me there some more significant differences as regards security, trust and authentication mechanisms that are specified in CPP but not (I think) in SMP. In broad terms at least, these seem to cover the business problems that I was pointing to as regards BDX support of current B2B identity and security practices.

There are a few remaining use case gaps I’m still seeing. Is there a way of handling or profiling these within the existing standards? I’d be very interested to hear from you whose technical expertise so vastly exceeds my own. If so, that might allay Mike’s concerns about focus/scope creep, since we seem to be already headed down an SMP/CPP convergence path.

I realize now may not be the time to address this in detail. However, deciding if these issues are within scope or not seems to me very material to the interoperability and ultimate value of BDX-defined mechanisms.

So, would it be possible to profile the following within the CPP/CPA framework?

1. OAuth profiling within CPP/CPA for API access setup. OAuth is increasingly prevalent as an authentication mechanism for API access. Providing such API access for an existing (supplier/partner) identity would be a relatively modest change for a network. A particular network might or might not combine this with…

2. OAuth/OpenID/OpenSocial/SAML profiling for new identity setup/handshake/token exchange. These standards define handshake protocols for establishing a new identity on a target system.

An additional use case that might be out of scope (since it concerns business document collaboration rather than exchange) would be:

3. OpenID/SAML profiling for Single Sign-On (SSO). This concerns cases where a document sender might log on to a target system in cases such as (a) a submitted invoice is invalidated, but can be fixed via a web interface, rather than requiring resubmission from the source system, or (b) is rejected/disputed for business reasons.

Best regards,

Roger Bass

From: Pim van der Eijk [mailto:pvde@sonnenglanz.net]
Sent: Monday, March 28, 2011 11:53 AM
To: bdx@lists.oasis-open.org
Subject: [bdx] SMP and CPP

To follow up the presentations of some time ago, here is some information on the SML/SMP concept and the ebXML Collaboration Protocol Profile (CPP) concept.

Mike's employer developed precursors of CPP/CPA and submitted these concepts to OASIS during the ebXML project.

CPP references below are to the version 2.0 OASIS Standard: http://www.oasis-open.org/specs/#cppav2

(There is a newer version 3.0 in progress, which has many potentially relevant extensions, but it is still in draft).

First of all similarities: there is very much overlap:

party info, services, business processes, messages exchanged, schemas of those messages, endpoints and protocols supported.

There are some differences.

1) SMP has metadata for a particular document type that a partner can receive, in the context of specific business processes.

A CPP defines which messages a partner can receive or send, in one or more specific business processes, and associated business documents or composites.

2) In a CPP, the nesting hierachy is PartyInfo > CollaborationRole > ServiceBinding > (CanSend | CanReceive) > Channel > Packaging, Endpoint information etc.

In SMP the hierarchy seems to be Party > Document > ServiceInformation > Process > Endpoint.

CPP seems to be a bit more service-oriented (you interact with a service by invoking actions on it), whereas SMP is more resource-oriented (where somehow the resources are documents), but the differences are minor. It may even be possible to write an XSLT that transforms an SMP to a CPP or the other way round ..

Below is a visual representation of the version 2.0 CollaborationProtocolProfile XML scheme element, and attached is a(n ancient) example CPP.

bdx message