Subject: Expanding TPA formation discussion of F2F Meeting, Oct. 12 - 13
At the Oct 12 and 13 TPA WG f2f, one agenda item involved discussion of the agreement formation process. Because of the limited time we had to discuss proposals, I want to continue to point out some options for understanding this process. I assume that the consensus now supports Scott's proposed view of the party profile (PP) as minimally a set of party capabilities, with rankings be added in eventually. Each capability bundle consists of n-tuples of identity, role, service-type, security policy, communication parameters (that can be publically revealed), and whatever else we need to have included. I think we can work out whether this tuple is a by-value tuple (so actual XML subtrees are included within it), by-reference to other elements, or some mix. I think that is a fine tuning issue, but it will impact some detailed features of the party agreement formation. (E.g, will n-tuple identity be a "deep" structural identity or just an identity by reference (assuming the refs are like URIs)? My impression is that we will try to build on tpaML 1.0.6 in arriving at the structure of the bundle of these capabilities. I think the very interesting idea of DeliveryChannelSet can evolve into a precise specification for this bundle and I hope the clarification of how this can be done can continue in Tokyo. With this background, the f2f discussion showed that there are at least two ways of thinking about the process of forming a party agreement (PA) from party profiles. The "asymmetric" method (or SME-method) assumes that only one PP is available for the trading partner pair trying to reach an agreement. The symmetric method (or peer-to-peer) assumes that the input is at least two PPs, one from each party. The asymmetric method mainly views PA formation as a variety of macro subsitution. That is, a PA is formed from one PP by "picking and choosing" to replace placeholders by values. The symmetric method will also have placeholder replacement as part of the method. But before replacements occur, the two PPs are "merged" to form a proto-PA. The merge process would be identical, whichever party initiated it (and in fact even a third party, having the two PPs as input, could precompute the merge). I proposed that the PP merge process be understood as an intersection of the capabilities in the PP bundles. The resulting proto-PA would then have the maximal overlap of delivery channel capabilities. Negotiation or other processes might be used to select a minimal subset to be used in practice (or at least a smaller subset). At this point, I want to mention some options that time did not permit us to get to. First, while the proto-PA might be formed by message exchanges between parties, it is important to realize that the proto-PA could be retrieved from a registry, at least a registry that was willing to do some work. In other words, for any pair of PPs submitted to a registry, the registry could precompute the proto-PAs for that pair. For that situation, a party could retrieve the proto-PA from a registry and proceed to bind it for the details concerning things like authorization ids, realms, passwords, and the like that can only be replaced privately on each side. As I mentioned a secure exchange process for the filled-out PA would need to be present within the PPs (to permit a secure bootstrap message exchange). The other side receiving this partially bound proto-PA, could then bind its own private values and securely return the completely bound PA. Notice that this proposal still gives the registry a role (in fact it now really has something to do !), and avoids the dicey security situation of leaving authorization tokens inside a registry. And support for the secure automated exchange (peer to peer) of the authorization tokens occurs at the final stage of the process. Also, if token-based authorization is not required, the proto-PA in the registry is basically complete at an operational level (roles assigned, identity, security policy, communication, and BPs to be conducted.) I still think an explicit "handshake" would be needed between the parties to indicate that they will carry out the BP using the proto-PA channels. But there may be a way to have a registry mediate that agreement process also if that option is wanted (an agreement acceptance "checkbox") The peer to peer process may seem a little complicated initially but it seems to be one that permits a greater level of automation than the SME process. Given that SMEs might be able to purchase software that could automatically produce a PP based on install information and send it off to a registry, there is no need to think that only the big companies could make use of the peer to peer process.
Powered by eList eXpress LLC