Re: interposition requirements

[Mark Little <mcl@arjuna.com>]

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

Absolutely, which is why I don't have a problem with a configurable option.
*However*, the default should be sensible enough that for the vast majority
of people who just want to knock up a BTP application it doesn't compromise
security or performance.

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

Certainly not at the low level, but security/trust and connectivity issues
at the very least may prevent this.

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

Agreed. However, at the very least allowing interposition does not
compromise security, and will work with whatever security protocol BTP X
comes up with. Remember, this is also used for performance and containment
issues, so lets not cloud the issue by simply concentrating on security.

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

Yes.

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

Given the timescales, no we are not going to achieve this.

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

Once again, yes. Interposition is purely a matter for the participant: as
far as the coordinator is concerned its a participant, as far as its
participants are concerned it's a coordinator.

Mark.

-----------------------------------------------------------------------
SENDER : Dr. Mark Little, Architect (Transactions), HP Arjuna Labs
PHONE  : +44 191 206 4538, FAX : +44 207 670 1964
EMAIL  : mark@arjuna.com