Thanks for the additional information. I'm looking at p.2 of your
document now, and I believe that this can/should be handled through some
type of contract between the two organizations, with a certain level of
mutual trust specified. I see this as more of an operational issue.
Please let me know if there are more specifics either within our outside
your document that may factor in, that I have not taken into account.
mm1: The process descriptions are an expression of the agreements
between parties. Those constraints, over time, may be expressed with
automated contractual tooling and capabilities. Therefore, I see no
conflict: 1) Agreement conditions will / may exist. The process
description and underlying infrastructure are responsible to meet those
Rundgren: The key-word is "end-2-end security". This is the foundation
of the Federal PKI. It among many things means that the
sender encrypts a message for the _ultimate_ recepient.
mm1: Anders, I don't see the conflict as that places conditions on the
environment, messaging, and the use of the process description. The
specifics around how the process is implemented, as Joe indicates, is an
operational issue. That could be the constraint that the process
description (computable) is used in a process engine housed on a single
server meeting the security constraints/conditions. Given the
requirements, the process description may surface the QoS properties.
How tightly coupled the infrastructure and messaging are bound to the
process description and execution, is an agreement decision, don't you
think? Thank you.