[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [bdxr] Use cases and a proposed "Connect" protocol
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 From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Roger Bass Sent: 24 July 2012 01:20 To: 'Moberg Dale'; bdxr@lists.oasis-open.org 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:
bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of
Moberg Dale 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]