RE: Requirements Document

Been tied up with other things the last couple of days....sorry...

At 2:48 PM -0400 8/24/01, Brian Rosen wrote:
>Huh, now I'm the one with more ambition wrt privacy than you.
>
>I believe we CAN provide a reasonable degree of privacy
>to location information within the bounds of my current problem.
>
>For example, I think we CAN require strong authentication
>prior to transmission of location information in nearly every
>case I'm aware of.

In order to do that, you need a mechanisms to represent unambiguous
identity of both parties in the exchange. The sad truth is no widely
accepted Internet mechanism for this yet exists. This is still true,
even when you try to restrict the domain geographically. That's why
requiring strong authentication in the near term is optimistic, imho.

>
>On the other hand, I'm pretty pessimistic about what real
>privacy controls you can put assuming next generation devices.
>The problem, as I see it, is that there is no way the
>sender can know if the receiver will respect its wishes.

Be careful of wandering into issues of trustworthiness. For the
purposes of design we can specify there is a trust mechanism and it
works in a particular fashion. I agree that it's wholly beyond our
control whether operators of the protocol sender/receivers consider
their partners trustworthy. At the same time, I don't think that's
our responsibility, so I'm not going to worry overmuch about this
question.

>All of the controls you want seem to be hints sent by the
>sender to the receiver telling the receiver what you hope
>it will do with the data.

I'd characterize it more definitely. The purpose of a protocol is
for each partner to determine if the other is correctly following the
steps of the negotiation. Cheaters can misrepresent themselves, and
there are cryptographic techniques than can limit the effectiveness
of cheating (zero-knowledge proofs), but they aren't perfect. I'd
conclude technology can aid building trust between partners, but
there are no guarantees cheating can be eliminated.

Essentially we agree. But this contradicts the original assertion
that strong authentication can be assured.

>Certainly, out of band mechanisms are as good, if not better than
>that, since they can either explicitly or implicitly create a
>contract, where a protocol mechanism cannot. A well designed
>consent form is a much more effective privacy control than any
>protocol mechanism could ever be.

I have two observations here.

A well-designed consent form is a form of a protocol - not one
created by the IETF, necessarily, but it still is a protocol.
Because it is a protocol, it can be modeled by one we design.

You've made the leap that a consent form constitutes a legal
document. Whether true or not, this is beyond our scope. Further,
it is beyond our scope whether law-making bodies would sanction an
IETF protocol as legally binding. Certainly this is a possibility,
but it's not our concern.

>
>The real problem though is that there is no way to test
>conformance to the requirements you seem to want to write,
>since there is no observable protocol behavior difference
>between a conforming and a non-conforming implementation.

If the rules of the protocol are explicit, then whether or not the
execution of the protocol conforms to the rules is certainly
testable. That's what our goal should be.

best,

-- 
john noerenberg
jwn2@qualcomm.com
   ----------------------------------------------------------------------
   If we admire the Net, should not a burden of proof fall on those
   who would change the basic assumptions that brought it about in
   the first place?
   -- David Brin, "The Transparent Society", 1998
   ----------------------------------------------------------------------