RE: Clarifying optionality of HTTP binding

The reason we do standards is to insure interoperability.

As part of clarifying optionality, clarify if you mean
"optional to implement" or "optional to use". If there
are no mandatory-to-implement bindings, how will you avoid
N implementations, each with a different binding,
which can't be configured so that they interoperate?

Adequate mandatory-to-implement security mechanism(s)
needs to be part of the binding specification, for the
same reasons -- to avoid having multiple non-interoperable
implementations. As for what constitute "adequate",
consider the examples in the XML Protocol Working
Group charter (http://www.w3.org/2000/09/XML-Protocol-Charter),
which includes "validateCreditCard" in the set of simple
applications that should be supported without extensions.

To validate a credit card you need both authentication
for authorization (that the identity of the requestor is
assured and that the requestor is allowed to validate
a credit card) and privacy (that the transaction of
credit card validation cannot be read by transport
protocol intermediaries).

Note that the current (optional) HTTP transport binding
doesn't contain an adequate security mechanism that would
allow "validateCreditCard" to be realistically deployed.

Larry
-- 
http://larry.masinter.net

Received on Wednesday, 27 March 2002 20:47:02 UTC