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. The 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. For 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 .
There 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
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:
<!--[if !supportLists]-->1.
<!--[endif]-->Locator Service
<!--[if !supportLists]-->2.
<!--[endif]-->Connect Authorization Service (including
Authentication)
<!--[if !supportLists]-->3.
<!--[endif]-->Connect Metadata/Profile (CPP) Query
Service
<!--[if !supportLists]-->4.
<!--[endif]-->Connect Agreement (CPA) Creation
Service
I may not have stated this
quite right, but I think the basic points are:
<!--[if !supportLists]-->a)
<!--[endif]-->As
with PEPPOL now, lookup of a service remains architecturally separate from
what’s required to get details about, and connect to a
service
<!--[if !supportLists]-->b)
<!--[endif]-->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
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
<!--[if !supportLists]-->·
<!--[endif]-->Authorize an identified party
(possibly for some subset of services)
<!--[if !supportLists]-->·
<!--[endif]-->Obtain profile information from a
party (capabilities and/or delivery channels)
<!--[if !supportLists]-->·
<!--[endif]-->Provide profile information to a
party
<!--[if !supportLists]-->·
<!--[endif]-->Publish profile updates to a
party
<!--[if !supportLists]-->·
<!--[endif]-->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.