Hello,
PEPPOL SMP has
(1)
a Locator service (SML) using DNS that tells you where
(2) you can learn about the capabilities and endpoint configuration of a partner using a publisher protocol (SMP) that uses HTTP GET. That SMP tells you how to then
(3) send documents to the partner using a B2B protocol, currently START.
So (1), (2) and (3) all use protocols, (1) and (2) being lighter than (3).
The way that SML/SMP work, anyone can find the same set of information about a anyone once they know the PartyId. (And if that PartyId is an existing scheme, e.g. Chamber of Commerce registration number, then that PartyId is easy to find too as most Chambers of Commerce have a search page). So it is not possible for the partner to present a different set of capabilities depending on who is looking up those capabilities. Or to deny sending any information if you're only communicating with a closed community.
Since the whole point of (2) is to enable (3), the users of (2) are presumed to also support (3), so not much is gained by (2) being lighter than (3). Why not use a B2B protocol directly? Such a B2B protocol will be a more capable protocol that has security and reliability built in. T
he proposal is to not use a separate lookup protocol for (2) but more or less merge (2) and (3).
To query the capabilities ( browse a profile , in social networking terminology), or to exchange parameters and configure sender and receiver endpoints ( connect/friending/etc. in social networking), we would use the Connect
protocol.
The Connect protocol would be a business protocol, just like Ordering , Tendering , Filing Small Claims
etc. More or less like the Party Registration service in Energy Interoperation. F
or the underlying technology, Connect would reuse a regular B2B messaging protocol which provides the basic packaging, security, reliability, non-repudiation etc. features. So, no new mechanisms to invent in that area.
What this TC would need to add are definitions the basic interactions, exchange patterns, schemas for payloads, message metadata. SMP, CPP, CPA, NDD and AFDD are useful inputs.
PEPPOL metadata publisher could be recreated directly by defining some B2B request message that can be sent to a Connect endpoint, which returns an XML payload containing capability information, or a functional error if the responder does not want to share capability information with the requester. But we can also support an Agreement model, where the requester provides its own configuration information (e.g. about its sending capabilities, as in CPP) and the responder returns a structure combining information from the two, and an agreement identifier that can be used subsequently (as in ebXML CPA).
AS4 and ebMS3 exist, they need profiling for four-corner topologies but that work has mostly been addressed by the LSPs already. SMP, CPP and CPA exist, though the enhancements to support ebMS 3.0 are not finished yet. CPA formation from two input CPPs, CPA formation from templates (as in the NDD and AFDD proposals from the former CPA) are used in production for ebMS 3.0 and CPA 2.0 already, there is work to do for newer versions. Overall
, no fundamental challenges .
T here could still be an Locator service (SML or some enhancement or alternative, e.g. based on ideas you've presented), but in this scenario
it would return the address of a Connect
service.
From what I learned from you, DNS records have a service field that can be used to select among multiple versions or alternatives of Connect protocols. But hopefully we can come up with a protocol design that is sufficiently generic so that there will not be too many alternatives. Connect also does not require any other registry functionality.
What is not answered is the security model, i.e. the question how the Connection request and response messages are secured. The range of techical options is limited by the options supported by the B2B protocol. So when using ebMS 3.0, interoperable options are the UsernameToken or X509 token profile options of WS-Security / WS-I BSP. But when you're connecting, you typically haven't exchanged any passwords or certificates yet. Particular deployments could address this by assuming one or multiple root CAs that are inherently trusted, and that issue certificates that store the Party Identifier and identifier type, so the MSH can check those against the identifiers in the ebMS header. This is the PEPPOL PKI model. It has been suggested that this should be generalized using mechanisms like the ETSI TSL.
Many other options are conceivable.
Perhaps they should not be part of or selected by the Connect protocol standard but only enabled, with choice left to particular communities or jurisdictions. In four-corner topologies, the scope is limited anyway to security between the inner two nodes, which reduces complexity.
Sorry for the long reply, and hope this helps.
Pim
From: [mailto:] On Behalf Of Roger Bass Sent: 24 July 2012 01:20
To: 'Moberg Dale';
Subject: RE: [bdxr] Use cases and a proposed
Connect protocol
Dale: the text where you say “Roger writes” was actually pulled from Pim’s presentation, so I should defer to him on those questions (and also because of his greater technical expertise!)
I would, however, ask you to clarify your question as the “intent… to abandon the PEPPOL architectural separation between SML and SMP”? Rather than eroding/abandoning this separation, it seems to me that we’re proposing here to introduce one or two additional layers of separation:
1.
Locator Service
2.
Connect Authorization Service (including Authentication)
3.
Connect Metadata/Profile (CPP)
Query Service
4.
Connect Agreement (CPA)
Creation Service
I may not have stated this quite right, but I think the basic points are:
a)
As with PEPPOL now, lookup of a service remains architecturally separate from what’s required to get details about, and connect to a service
b)
As distinct from PEPPOL now, step #3, obtaining the ‘Metadata’ aka ‘Profile’ of a service is here embedded as just one step in a protocol that now also includes (#2) pairwise mutual authorization, and (#4) creation of a collaboration agreement between the parties (via a more or less flexible negotiation protocol).
It’s unclear to me to what extent the Authorization service is cleanly separated from the Metadata/Profile handshaking – or if, conversely, the requester’s Profile would be presented as part of an Authorization Request.
Roger
From:
[mailto:] On Behalf Of
Moberg Dale Sent: Monday, July 23, 2012 3:10 PM
To:
Roger Bass;
Subject: RE: [bdxr] Use cases and a proposed Connect protocol
I have a few questions concerning the functional requirements associated with the use cases that Roger is concerned with.
Roger writes” “ Connect to a business partner using a message protocol: the registry would serve only to discover the endpoint for the “connect” message, not to retrieve an SMP or CPP ”
Dale> Is the endpoint to be retrieved a URL, or something else? What message protocols are to be used? For message protocols that are “layered” over an IETF application layer protocol (such as HTTP, FTP, SMTP, POP, XMPP, MSRP, etc.) how can different endpoints for different protocols be indicated? Or is the assumption that there is a single URL for all message protocols (for a given URL scheme, such as HTTP). DDDS can provide URI endpoint information for an arbitrary service (provided that the service has an agreed upon DDDS name!); can that serve as the underlying query-response technology ? If not, why not?
Is your intention in the above to abandon the PEPPOL architectural separation between SLP and SMP modules (in saying ‘not to retrieve an SMP or CPP)? What is the structure of the query “to the registry” – or is the query protocol being identified with the “Connect” protocol?
What forms are allowed for “registries”? DNS, LDAP, RegRep, UDDI, etc. Or something new?
Roger continues: Services to be considered
·
Authorize an identified party (possibly for some subset of services)
·
Obtain profile information from a party (capabilities and/or delivery channels)
·
Provide profile information to a party
·
Publish profile updates to a party
·
Create/terminate a named agreement
Dale> (Are all of the above bulleted services to be provided by the” Connect protocol”? Or does each service use the same endpoint information that the Connect protocol finds? How does the request indicate what service is being requested? Are these services to work no matter what “message protocol” is being used?
What formats are to be supported for response information?
What authorization protocol(s) are to be supported? SAML authz request/response? OAuth? Basic Auth? Others? Something new (I hope that “something new” is out of scope for us.)
Is the general idea of the Connect protocol to invent or re-invent all these services and protocols? Or instead to “profile” how existing approaches can be applied to these probems?
Or something else? If we do something new, I hope it can somehow be meshed with what already exists somehow.
I think I need to understand a little better the scope of effort involved in creating the “Connect” protocol -- especially with respect to reuse of existing standards, customization of existing standards, or creation of new protocols and data formats.
Thanks Roger for starting this discussion.
