RE: Requirements Document

> >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.
I do understand the limitations of authentication.
I think there are often difficulties of correlating the user's sense
of identity of a party with cryptographically strong authentication,
but I suspect that we still can have strong authentication in many,
but not all cases.

I'm not aware of any techniques that ensure strong
privacy in tha absence of strong authentication.

> >
> >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.
I'm confused. If you trust the other side, then we don't need
heavyweight mechanisms to do things like delegation; we need
interoperable hints. Further, we don't need to be dogmatic
about their use - if you trust the delegatee, then you can
use a variety of mechanisms to assure that he has your
authority. I don't mind having mechanisms described
in our requirements, so long as their use is not mandated when they
aren't appropriate.

>
> >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.
Maybe we are more in agreement than I think, but I'm still thinking
I want to have qualified statements about when any delegation
mechanism, as an example, that is described in the document is appropriate
to use, and it seems to me that you want very unforgiving language
that mandates it's implementation in every use case.

Perhaps we should start writing the requirements and see what
the words do to us.

>
> >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 point is that if the consent is done by contract, then it need not
be done by network protocol. Thus the network protocol mechanism
should not mandate a consent mechanism. It can offer one, so long
as its use is optional. The requirements can state unequivically
that consent is mandatory. What I want to see is that it not
mandate that the consent has to be obtained by network protocol exchange.

Brian
Received on Thu Aug 30 15:06:41 2001