[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [bdxr] AW: PEPPOL's support for SMEs
The way PEPPOL works is that all gateways (corners 2 and 3) have to be previously "authorized" in order to access the network. The authorization is both a technical as well as a formal process. Once a gateway has been authorized to access PEPPOL, then all other gateways on the network can trust that they can connect their users (corners 1 and 4, or in "PEPPOLish": participants) to the users of that gateway. In essence: any user of any gateway can connect to any other user of any other gateway solely based on their formal business relation and without any technical intervention. This is also more or less how I understood your "fully automated" scenario. We definitely need a common vocabulary/terminology section as Dale suggested. I will ask OASIS to setup a Wiki for us and will initiate the a "glossary" entry. I hope everyone will contribute. Best regards, Kenneth From: Roger Bass <robass1@earthlink.net> Date: Thursday, May 24, 2012 12:11 PM To: <bdxr@lists.oasis-open.org> Subject: RE: [bdxr] AW: PEPPOL's support for SMEs Kenneth, Susanne, From your last emails, I’m not sure we’re yet 100% aligned on our definitions of “Semi-automated” and “Fully automated” setup processes. Of course, my presentation is this scheduled for next week’s meeting, and we’ll have an opportunity to discuss then. That said, I’ll share a couple of thoughts here on defining these terms. It seems to me that both PEPPOL and (from Susanne’s email) e-CODEX currently have an essentially open, email-like model, without explicit authorization of relationships. As you said, there might be ‘spam filter’ like mechanisms on top of that, but up to now, I’ve not heard that those mechanisms formed part of the formal requirements. Nor have I yet heard if there’s a use case for you where an email invitation is the trigger for setup of an access point/mailbox. The question of possible future requirements in those LSPs for explicit relationship authorization is really your domain rather than mine. However, in procurement/supplier network systems other than PEPPOL, I would observe that explicit relationship setup processes are the norm rather than the exception. In both these cases, the user may indeed have nothing to do to get connected (beyond publishing their ‘address’ in some form). However, as a matter of definitions, it’s perhaps not helpful to think of this as a “Fully automated relationship setup process”. The “relationship” this is intended to refer to is more like the social network scenario where that the relationship is explicit for both parties. (Email whitelisting scenarios can be similar, though that setup process is not necessarily conversational). “Semi-automated” was intended to refer to the scenario where one entity (typically the large/enterprise) has an automated process for inviting partners (e.g. SMB suppliers) to get connected, but where the initial steps on the partner end are at least partially manual, i.e. clicking on an email link. This is still different from typical supplier on-boarding processes today, however, in that the human actions would include identification of a system that they designate as their proxy or gateway (corner 3), followed by some automated setup dialog between the gateways (corners 2 and 3 out of 4). (We may need a better term than “semi-automated” to express this). Susanne, I understood from your email that the e-CODEX model is actually really more of a 6-corner model, in that the access point for the end user is separate from the gateway. The extent to which any of this matters to the e-CODEX use case may depend partly on whether an end-user is simply assigned a mailbox/access point/service provider in a given national/local domain, or whether they have some ability to select. In particular, for scenarios where full, machine-to-machine automation is desired, it’s generally going to be up to each user to say which ‘machine’ (i.e. software application) they actually use. The access point/service provider that gets set up for them would then be determined (or at least constrained) by that choice. Best regards, Roger From: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Kenneth Bengtsson Susanne, Roger et.al. I very much like what you are describing here. The "fully automated" process is roughly what PEPPOL aims at, and both scenarios are very very interesting. I very much look forward to the coming presentations and discussions. We have quite a lot for the agenda for the coming meetings. Last week, one hour was hardly enough for two presentations and we didn't have any time for discussions and questions. I propose that next week, and while we are in this "requirements discovery phase" we instead schedule two hours for the meetings. Any strong objections? Best regards, Kenneth From: Roger Bass <robass1@earthlink.net> 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: bdxr@lists.oasis-open.org [mailto:bdxr@lists.oasis-open.org] On Behalf Of Susanne.Wigard@it.nrw.de 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
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]