bdxr — archive

Use cases and a proposed "Connect" protocol

From: Pim van der Eijk <[email protected]>
To: [email protected]
Date: Tue, 24 Jul 2012 14:49:00 -0000

Hi Susanne, The version 2.0 of ebMS and CPA were developed in close coordination, and you are right that some ebMS 2.0 products only support ebMS in combination with CPA, effectively having a whitelist of allowed partners, services etc., but I've worked with some ebMS 2.0 products in the past that did not have this requirement. For Connect to use ebMS 3.0 we would need a way to have the ebMS 3.0 MSH allow messages that have constrained values for some headers (Service, Action) but not for others (From/PartyId). I think that is possible with some ebMS 3.0 implementations already. Pim From: [email protected] [mailto:[email protected]] Sent: 24 July 2012 15:42 To: [email protected]; [email protected] Subject: AW: [bdxr] Use cases and a proposed Connect protocol Importance: High Hi Pim, Yes I see how the Connect protocol would enable the Metatdata Service to selectively refuse requests. Still, at least for ebMS it would look to me like the problem is a more general one: I believe you explained that it is not possible to exchange messages with anyone you don't have a CPA with - so if CPA data (certificates being just one particular example of that) is what you want to discover through business document exchange there's something circular about it. But indeed that can be discussed in the call... Susanne Von: Pim van der Eijk [mailto:[email protected]] Gesendet: Dienstag, 24. Juli 2012 14:56 An: Wigard, Susanne (IT.NRW); [email protected] Betreff: RE: [bdxr] Use cases and a proposed Connect protocol Hello, No, I don't think SMP is any better. In the Connect model, B (or a service provider that B outsources its Connect service to) will receive some Connect request. B will be able to see who the request came from, minimally by looking at the From/PartyId (or equivalent) structure in the request message header. B can then decide to decline the invitation if B doesn't want to connect to A or does not want to let A know the URL of its B2B endpoint. B can also send some personalized response. For example, perhaps B offers some service, but does not want A to use that service or even let A know about its existence. Connect messages could be asynchronous, allow B time to evaluate or otherwise process the request. As far as I understand SMP, if A wants to look up the SMP information from B, there is no way B can prevent this, or somehow customize the XML structure that A will get. A does not have to authenticate itself to the SMP server, there is no log other than the Web server log of who retrieved the SMP record. The SMP XML has the URL for B's business endpoint in clear text. This probably reflects PEPPOL's assumptions that in their domain this information can be shared freely. But some TC members know a lot more about SMP that I do, so I'll let them comment, we can also discuss this on the TC call tomorrow .. Pim From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: 24 July 2012 13:52 To: [email protected]; [email protected] Subject: AW: [bdxr] Use cases and a proposed Connect protocol Hello, Just a short question on the security model: is that any better with SMP ? You seem to suggest that knowing a PartyId anyone can do the lookup. Susanne Von: [email protected] [mailto:[email protected]] Im Auftrag von Pim van der Eijk Gesendet: Dienstag, 24. Juli 2012 12:50 An: 'Roger Bass'; 'Moberg Dale'; [email protected] Betreff: 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. 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: [email protected] [mailto:[email protected]] On Behalf Of Roger Bass Sent: 24 July 2012 01:20 To: 'Moberg Dale'; [email protected] 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: [email protected] [mailto:[email protected]] On Behalf Of Moberg Dale Sent: Monday, July 23, 2012 3:10 PM To: Roger Bass; [email protected] 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.