RE: interposition requirements

[Bill Pope <bpope@bowstreet.com>]

Hello Alastair,
You seem to have caught up quickly.

I agree, some of the points are a bit dissonant :^).  I believe that we
are coming to the conclusion you would prefer but will rise to your
bait on some of the points below because I think they will frame 
subsequent discussion and direction.

Let me preface this with my assumption that interoperability of
implemenations is a requirement.

A standard that does not define how the components being addressed
interact is not a standard, or is at best a poorly specified
standard. What is being discussed here is not an implementation
optimization but a part of the standard which directly addresses
permitted and expected communications between two of the constituent
pieces.  If a coordinator state machine is written to the expectation
that sub-participants will not register with the coordinator it will 
not work with sub-participants that exhibit this behaviour.

The point made during the face-to-face was that even with a Trust 3
model the coordinator has no previous context with the registering
sub-participant and so has no basis for establishing trust.  There
is a relationship between the participant provider and the
sub-participant but this relationship is not known by the root
coordinator.  This type of intermediated relationship leads to what is
referred to as transitive trust, in which A trusts B and B referred C
to A so C is alright with A too.  There has been little work done on
how much of the relationship between B and C is expressable and so
knowable back at A. 

Agreed that for Trust 1 relationships registration of a
sub-participant with a higher level coordinator works perfectly well.   
What I would like to see in the spec is some indications and
counter-indications for use of both registration models.

Some more in-line below.

Regards,
=bill

> -----Original Message-----
> From: Alastair Green [mailto:alastair.green@choreology.com]
> Sent: Wednesday, May 02, 2001 12:35 PM
> To: Mark Little
> Cc: Sazi Temel; Bill Pope; bt models
> Subject: Re: interposition requirements
> 
> 
> I've just got back from holiday, and it's taken me a while to 
> review this thread. I hope you won't mind me coming in on it late
> with a few points, which are perhaps dissonant.
> 
> a) A standard should not restrict the optimization choices of 
> an implementor, nor the deployment choices of an end-user, unless
> there is a _functional_ need (where "functional" means " in order to
> fulfil a requirement"). 
>
> b) The first requirement here is "allow participants to be 
> enrolled with a coordinator so that they can vote and know the
> outcome".  Fulfilling this requirement does not require any
> restriction on who can enrol with whom.
> 
> c) There may be an addition to the basic requirement: ", and to
> ensure that participants and coordinators trust each other".
> 
> [This is not a trivial addition by any means, and I believe 
> it should not be approached in a piecemeal fashion. In the models  
> sub-committee face-to-face in London I expressed the view that a
> secure business transaction protocol was a very desirable thing, but
> that the time scale for this current effort should make all
> considerations of security out of scope. I still hold to that
> opinion. 
> If in the future we have an OASIS BTP 2.0 I think I would argue for
> the secure version to be an optional part of the spec.]
> 
> d) There are three ways of ensuring trust between the BTP
> actors. The first (Trust 1) is to put them all on a sealed network,
> where all messages are deemed to be trusted ("behind the firewall",
> a VPN). The second (Trust 2) is a variant of the first: to tunnel
> all or some protocol messages through other messages which are
> already trusted (x.com only trusts the contents of messages sent on
> a special BTP-aware link or session to y.com, but requires no
> further reassurance). The third (Trust 3) is to authenticate all
> actors, and then sign all messages between them, so that every
> message has unfalsifiable distinguished endpoints, tamper-proof
> contents, and cannot be repudiated ("do it properly").

Trust 2 is not a variant of Trust 1.  It uses a specific context to
extend trust in a specific area.  A client logs onto a server.  The
server determines a list of entitlements based on the identity (this
is close enough for discussion purposes).  Very different from
"everyone behind the firewall is trusted" regardless of the operation
being performed.  Trust 2 is what is powering the Internet today. The
trust assurances vary according to the risk each party is willing to
take.  Access to a forum may be base on only having a valid email
address.  Access to goods and services is most often based on having a
valid credit card number.  Access to corporate resources is most often
based on having an off-line verified business relationship.

> e) Making rules about who can register with whom in order to enforce
> performance, is not our business with our standards hats on (so long
> as we don't _mandate_ the noxiously unperformant). Making such rules
> to enforce aspects of security is not possible without establishing
> a trust framework. 

Making such rules to enforce aspects of security is not possible
without establishing a trust framework OR using a pre-existing trust
framework.  In a B2B relationship there is some expectation of, well,
a relationship.  This can be manifested by granting an account,
exchanging certs, sending a URL, or what ever is appropriate to the
relationship.

> [We obviously can't mandate Trust 1. We could try to shoehorn 
> BTP protocol messages onto authenticated application messages (Trust
> 2), but that would require some nice judgements about how much trust
> to mandate/recognize, or would be infeasible, depending on how much
> of the protocol you want to secure -- just enrollment or the full
> 2PC that follows. In the latter case there may not be enough
> application messages to support the voting/outcome protocol, or we
> have just reinvented Trust 1. The only way to properly restrict 
> message passing is to use Trust 3. That implies that all actors (app
> and protocol engine) have authenticated identities etc. Are we
> really up for that and all it implies? I doubt it, and I also would
> strongly oppose mandating such an elaborate framework in a nascent
> field.] 

Agreed, Trust 3 has been successful only within limited communities
like PGP mail or hub and spoke business relationships.  It mandates an
infrastructure that is not widely deployed.  However I do think that a
Trust 2 model bears closer examination before being discounted.  In
particular looking at the trust boundries and actor relationships to
see if there is some expressable set of expectations.
I strongly agree with your point not to mandate an impediment to
adoption. 

> f) Both the coordinator and the participant might have legitimate
> reasons to restrict enrollment (refuse to do business with the other
> party). 

Agreed.

> g) The role "sub-coordinator" is a convenient term for a participant
> which chooses to act as a coordinator to other participants. It is
> not a distinct actor, because its behaviour can be fully described
> in terms of two existing actors: P and C.

Correct in the abstract but I would not have wanted to attempt this
discussion without being able to use the term.  Similarly I would not
want to describe these interactions to the eventual implementors
without access to the term.


> Alastair
> 
> Mark Little wrote:
> 
> > > We can always define and disallow it per definition but 
> it looks like an
> > > artificial restriction... because a service can always go 
> around it by
> > > starting its own transaction under the cover and the main 
> coordinator
> > > cannot do anything, cannot even aware of this new transaction.
> >
> > The default should be that it interposition is available 
> from a participant
> > then it should be used. However, I've nothing against it being a
> > configurable option as long as it is up to the participant 
> to decide whether
> > it wants to allow it to be turned off.
> >
> > Mark.
> >
> > ----------------------------------------------
> > Dr. Mark Little (mark@arjuna.com)
> > Transactions Architect, HP Arjuna Labs
> > Phone +44 191 2064538
> > Fax   +44 191 2064203
>