Re: interposition requirements

[Alastair Green <alastair.green@choreology.com>]

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").

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.

[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.]

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

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.

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
begin:vcard 
n:Green;Alastair
tel;cell:+44 795 841 2107
tel;fax:+44 207 670 1785
tel;work:+44 207 670 1780
x-mozilla-html:FALSE
url:www.choreology.com
org:Choreology Ltd
version:2.1
email;internet:alastair.green@choreology.com
title:Managing Director
adr;quoted-printable:;;13 Austin Friars=0D=0A;London;;EC2N 2JX;
fn:Alastair Green
end:vcard