RE: Requirements Document

At 9:20 AM -0400 8/23/01, Brian Rosen wrote:
> > >There certainly is scope for dealing with agents that are
>> across the wire
>> >from the sender (I send location to a server that authenticates and
>> >provides my location to others on my behalf).
>>
>> There are senders and receivers. What you are talking about is a
>> receiver who may become a sender, and calling this receiver-sender an
>> "agent". I'm just clarifying terminology.
>Yes, you have interpreted what I meant correctly.
>
>>
>> > I want the object to be able to be used in such a circumstance.
>> >The issues of how the delegation is done, and how the authentication
>> >between the ultimate receiver and my agent is, I think, also beyond
>> >any strict requirement.
>>
>> I disagree. The delegation rights for the information must be
>> encoded in the location message.
>I agree that it COULD be, for some uses, although I suspect that
>in fact the delegation for the vast majority of the cases is
>in fact more static, and received out of band. With respect
>to our work, I can see writing up some requirements for a
>such a case as an example, but I would be against mandating the
>mechanism. Thus my opposition to a strict requirement.

Our goal is to insure that location information is revealed in
compliance with the agreement between the sender's controller and the
receiver's controller. We must assume that each transaction is
independent. Therefore the access rights applying to any particular
transaction must be included in every transaction. To do otherwise
allows the condition that location revelation is not controlled by
security considerations in every circumstance. This would be a
fundamental flaw.

>
>We can say something like, "where it is appropriate, delegation
>of rights could be sent with the location message. In such a
>case, protocol designers may consider the following requirements."
>
>What you can't do is state absolute requirements, because they vary
>greatly by use case.
>>
>> > My agent could receive my delegation by out-of-band means. It
>> >could authenticate by out-of-band means.
>>
>> I suppose it could. But why is that desirable? Even if it is, we
>> still need a way to change the delegation privileges in-band. We
>> don't want to force people to go out-of-band to change the delegation
>> privileges. That would be inconvenient in many circumstances.
>
>It is desirable because the UI for the end device may be much less
>convenient to allow a full and complete disclosure of when and
>under what circumstances delegation is permitted.

I say with all respect, the UI capability of the end device is not
our primary concern. First, we must create a protocol which insures
privacy considerations of sender and receiver are respected to the
greatest degree possible.

>A much more reasonable scenario is that you sign up for a service which has
>a website where your contract is spelled out. You may have a number
>of controls, best managed by a desktop UI. You make your choices,
>come to agreement, and then your end device makes reports to the service
>and the service does the delegation.

This is only reasonable in terms of devices which were designed
several years ago. Do not be bound by this. We must not be bound by
this. We are designing for devices to be built tomorrow, not
yesterday.

>
>I don't want to force anything on anybody. I want to make services
>available.
>I want options, not restrictions. I'll be very happy to accommodate
>any of the mechanisms you want to see, as long as every one of them
>is optional to implement.

If they are optional, they are meaningless.

-- 
john noerenberg
jwn2@qualcomm.com
   ----------------------------------------------------------------------
   Like the Sorcerer's Apprentice, we succeeded beyond our
   wildest dreams and our worst fears.
   -- Steve Crocker, quoted in Wired Magazine, Apr, 1999
   ----------------------------------------------------------------------