Expanding TPA formation discussion of F2F Meeting, Oct. 12 - 13

["Moberg, Dale" <Dale_Moberg@stercomm.com>]

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.