OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

ebxml-tp message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

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


This is a good writeup.  I have some comments/responses.

See replies embedded in the appended copy.



Martin W. Sachs
IBM T. J. Watson Research Center
P. O. B. 704
Yorktown Hts, NY 10598
914-784-7287;  IBM tie line 863-7287
Notes address:  Martin W Sachs/Watson/IBM
Internet address:  mwsachs @ us.ibm.com

"Moberg, Dale" <Dale_Moberg@stercomm.com> on 10/14/2000 12:03:59 PM

To:   ebxml-tp@lists.ebxml.org
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

MWS:  I agree.

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.

MWS:  The above seems to suggest that the registry
compute proto-PAs for all combinations of PPs in
the registry that have non-zero intersections.  That's
a substantial amount of computation and storage for proto-PAs,
most of which would never be used.  The number grows
considerably when you consider that a PP may include
several sets of capabilities that would never be used
together. Do you have something much
narrower in mind?

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.

MWS:  In tpaML, there are no authorization
tokens of any kind in the TPA, hence none
would be in the registry.  What is in tpaML
is URLs of certificates, URLs of certificate
authorities' certificates, and and indication
of whether passwords are to be used.  (In fact,
tpaML has the option to include starting passwords
but there is a strong warning not to use this

And support for the secure
automated exchange (peer to peer)
of the authorization tokens occurs
at the final stage of the process.

MWS: I assume that the above refers to authorization
tokens used for the negotiation process, not the tokens
to be used to conduct business.  We will need to think
about what kind of security is necessary for the
negotiation 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.

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [Elist Home]

Search: Match: Sort by:
Words: | Help

Powered by eList eXpress LLC