bdxr — archive

AW: [bdxr] AW: PEPPOL's support for SMEs

From: Susanne Wigard
To: [email protected]
Date: Mon, 21 May 2012 22:08:00 -0000

Roger, Obviously I don't know much about your use cases yet, since you couldn't give your presentation, but I did browse the uploaded slides. The topic seem s indeed to have some connection to the different types of use cases in e-CODEX, though my impression is rather that both my ' manual processing ' and ' application integration ' scenarios would be mapped to your fully-automated use case. When in e-Justice a human user wants to file a claim (electronically), he at the same time agrees to getting his replies through the same medium, which you might view as an invitation for the court to set up a business relationship (i.e. a communication channel). Similarly the defendant will, for legal reasons, be contacted by the court on paper first - he or she has then however the opportunity to opt in to electronic communication - thus it is always the citizen (the small party in your terminology) inviting the judicial authority. However since the court has to accept the message, establishing the communication channel can be automated, the gateway that the citizen uses acts as an agent for them. Likewise in court-to-court communication, all courts connected to the national gateway will usually accept communications from all courts connected to all partner gateways, so mutual authentication can also be fully automated through corners 2 and 3. As opposed to the social-network model where manual acceptance (by the ultimate recipient) of a communication request is required, for our use cases I would rather expect the sender's agent to filter out unwelcome messages - which will probably not be based on the user's identity, since citizens do have the right to communicate with governments. To prevent e.g. spam, other measures may have to be taken - already there are some criteria in place regarding message sizes and attachment types - this is another interesting question common to four-corner-architectures: will such rules be enforced (presumably leading to an error message sent back) at the sending gateway, at the receiving gateway or at the ultimate recipient? You also mention extending trust frameworks to encompass end entities - in fact where you have only a small number of gateways run by governments, it is not so difficult to set up some governance structures to enable trust - however much more interesting is indeed the chain of trust - my partner country's gateway tells me that their end entities have been properly authenticated, and maybe provides some additional information (attributes) about these end entities - which I will then just believe because I trust the partner gateway. This is what I would call identity federation, and in e-CODEX we do a similar thing for signatures. Establishing the gateway's authority to act as an agent for a specific end user is in our case not so difficult since at least for now we have one gateway per country that acts for all end entities in that country. This may however change in the future when e.g. lawyers' or notaries' bar associations run their own gateways, and by providing role information enable their clients to take part in specific business transactions not open to everybody. I agree it's good to see we're thinking about similar problems. Aligning on specific goals might be a little more difficult - though we have already some consensus to look more deeply into discovery, and initiated some next steps, such as collecting requirements as well as examining how SML/SMP can be generalized/extended (as in Dale's representation) and also what else is out there and how it relates to these different requirements. BTW, I like the term Connect Protocol , since it takes into account that setting up a business relationship is more than just discovering your business partner. Looking forward to your presentation, I have some questions already but don’t want to make this even longer than it already is. Best Susanne Von: Roger Bass [mailto:[email protected]] Gesendet: Montag, 21. Mai 2012 07:46 An: Wigard, Susanne (IT.NRW); [email protected]; [email protected] Betreff: RE: [bdxr] AW: PEPPOL's support for SMEs Susanne, Kenneth, I, for one, look forward to hearing you elaborate further, as you say Susanne, on your specific discovery requirements. You refer to use cases involving human processing vs direct EDI integration. You didn’t say enough for me to be sure, but I wonder if this relates to the two scenarios I will be touching on in my presentation, rescheduled from last time. I did already upload one version of that, though I may update it further. Those two use case scenarios there are for “Semi-Automated” and “Fully Automated” setup of an electronic (EDI-like) trading relationship between two parties, including the mutual authorization step. I’ll say more next time, but “semi-automated” is roughly a B2B analog of the social network “invitation” scenario. “Fully automated” but anticipates two previously-authorized gateway systems (i.e. corners 2 and 3) automatically detecting that their respective users (corners 1 and 4) have a business relationship, and then performing the required setup steps without any human intervention being required at all. This also relates, I think, to the discussion about SME support in this broad sense: making users’ experiences as simple as possible matters for adoption everywhere, but most especially for SMEs. And in this context, I think that means defining a model for setting up relationships that’s as easy as possible, including extensibility to relationships #2, 3… etc. In this specific sense, I think we do care about standardizing interactions beyond just those between the gateways (corners 2 and 3), although I agree with your point as regards the flow of the business documents themselves. I do also agree about the importance of “Circles of Trust” as you call them (or “Trust Frameworks”, in the more commonly used industry term), i.e. the legal governance structures that link the connected entities/gateways. However, many of the required features effectively require a “Chain of Trust” between the end user parties. That being so, it’s also important that one gateway be able to trust another SPECIFICALLY AS THE AUTHORIZED AGENT FOR A SPECIFIED END USER, so the process by which that authority gets established also matters. At the technical level, I think this relates very much to the material Dale presented last time. Pim has also referred to a notion of a “Connect” protocol that also seems closely related to these ideas. I expect all this will be presented to the TC in due course, even with it probably being in a “work in progress” state. Overall, I’m gratified by the rough alignment I see between the ideas and requirements that we’re each seeing, albeit coming from rather different perspectives. I’m hopeful that the discussions over our next few meetings will help us to further converge the TCs thinking about more specific goals/requirements and technical deliverables. I hope this email may perhaps have helped point out some of the points of commonality. Best, Roger From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Sunday, May 20, 2012 3:25 PM To: [email protected]; [email protected] Subject: [bdxr] AW: PEPPOL's support for SMEs Dear Kenneth, Good to hear the e-CODEX presentation was useful, I felt somewhat insecure about what is interesting to this group and what isn't. What I'd like to do at some later point in time, maybe in a few weeks, is elaborate a bit more on the particulars of our discovery requirements. Also if ever it fits, I would find it interesting to discuss the differences between uses cases that involve some human processing vs. direct EDI application integration. The 4-corner-drawing I've not only seen but also quoted in our own e-Delivery document ;) Thank you for your clarification on SME support - if that's basically about not assuming any specific capabilities on the 1st and 4th corner, that would in e-CODEX again map to subsidiarity - existing national systems remain untouched, whatever they may be (and whatever their technical maturity). However, there seems to be some small difference: where in PEPPOL SMEs can rely on a (commercial) service provider, e-CODEX gateways will be run by governments (ministries of justice), and so they will for their own country define minimum requirements to connect to that gateway. In some countries as far as I know the national Registered Email solutions are in fact commercial, but these service providers don't run their own e-CODEX gateways, but will be connected to the one of their country. Somewhat confusingly, what we call service providers are the technical systems connected to the gateways, so these sit rather on the 1st and 4th corner. The agreements between the entities running the gateways (that correspond to the PEPPOL agreements) are the basis of what we call the Circle of Trust (the legal details of which are still in the making). Similar to PEPPOL, we also standardize only what's between the 2nd and 3rd corner; how end entities communicate with the gateways is up to the Member States. (We do have defined a backend interface for the default implementation we provide for our partners, however in principle countries can change / replace that backend interface or use an altogether different implementation, as long as it communicates with the other e-CODEX gateways via the standardized (ebMS) protocol.) In fact, we can probably learn a lot from PEPPOL in terms of interoperability agreements. What corresponds to PEPPOL's service providers, catering for different needs of different user groups, are for e-CODEX the ministries, catering for the needs of their judicial IT infrastructures. We're not so much concerned about demand and supply - it's governments that decide they have a demand for cross-border e-Justice, and who then decide to run an e-CODEX gateway (and by joining the project as a piloting country, they have already implicitly made that decision). So in sum you are right that this requirement maps not so much to ours of avoiding proprietary infrastructures, but to the one already mentioned, that (where you have no requirements for SMEs) we have no requirements for the national systems (e.g. case management systems) nor to how they are connected to the e-CODEX gateways (e.g. .some secure national transport infrastructure, or, in the extreme case, gmail). Thank you for pointing this out. Regarding your last remark, that you see that a similar structure can support your use case for connecting judicial authorities let me just mention that we view the citizens’ communication via the European e-Justice portal just as a special case of this - in fact the e-Justice portal wants to connect to the e-CODEX infrastructure through e-Trustex, very much like e-Trustex is connected to PEPPOL. Best regards Susanne Von: [email protected] [mailto:[email protected]] Im Auftrag von Kenneth Bengtsson Gesendet: Donnerstag, 17. Mai 2012 02:07 An: [email protected] Betreff: [bdxr] PEPPOL's support for SMEs Dear Susanne Thank you very much for your interesting presentation today. I actually learned something and now understands e-CODEX somewhat better (I think) :-) I'm attaching the PEPPOL 4-corner drawing that I know you've already seen a million times, but just as a visual aid to help me elaborate on how PEPPOL supports SMEs: The private company in the drawing can be any company who supplies to public sector in Europe. It may be a medium sized or a large company who already does EDI and is well-equipped to implement new standards and procedures, but it may also be a one-man company whose technical capabilities are limited to the use of Gmail. The last example may be a bit extreme, but the point is that PEPPOL cannot assume any capabilities or assign any technical responsibilities to the 1st and 4th corner of the infrastructure. Instead the responsibilities are placed on the shoulders of the 2nd and 3rd corners - the service providers (acting as intermediaries): First of all, service providers required to comply with a set of technical standards and specifications, assuring that every service provider connecting to PEPPOL is able to exchange documents with every other service provider connecting to PEPPOL. Secondly, the service provider is required to sign an agreement with PEPPOL that obligates him to perform certain functions and to provide a certain level of service. This agreement covers (among other things) an obligation to receive messages to his end-users sent through any other service provider in the PEPPOL infrastructure, and to make sure these messages (if compliant with PEPPOL requirements) are delivered all the way to the end-user. The agreement also covers that the service provider must accept messages from his end-users intended for any other end-user of the infrastructure, and that he must deliver these message to the service provider of the recipient in a manner compliant with PEPPOL requirements and specifications. The PEPPOL service provider agreement does not cover how service providers must interact with their end-users, only that they must relay message to and from their end-users. In other words, it is only the message exchange between the 2nd and the 3rd corner that is standardized in PEPPOL. The theory here is that where there is a demand there will also be a supply. Where there are companies who want to fully integrate their ERP systems there will also be service providers offering to connect them, and where there are companies who think that Gmail is already a mouthful there will also be service providers who can cater for their needs. Because service providers are obligated to always relay messages between their end-users and other providers in the PEPPOL infrastructure, then every SME (as well as every large organization) has the freedom to choose the service provider that best matches their needs and capabilities, completely independent from what service is used by their trading partner. In a way you can say that for PEPPOL, the technical requirement derived from SME support is that there are no technical requirements for SMEs. Only for their service providers. My take is that this differs a bit from the e-CODEX requirement of avoiding expensive and proprietary infrastructures - at least to my understanding but please put me back in my place if I am wrong. I can also see that a similar structure can support your use case for connecting judicial authorities. Best regards, Kenneth From: < [email protected] > Date: Monday, May 14, 2012 5:11 AM To: < [email protected] > Cc: < [email protected] >, < [email protected] > Subject: [bdxr] e-CODEX use cases and requirements Dear TC, Please find attached a first impression of the use cases and requirements from the e-CODEX project ( www.e-codex.eu ). Since the requirements are, at this level, very similar to the ones from PEPPOL, I have referenced Kenneth's presentation and added the e-CODEX viewpoint for better comparability. Best regards Susanne --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]