Subject: RE: Requirements Document

From: "Rosen, Brian" <[email-masked]>
Date: Mon, 20 Aug 2001 15:07:23 -0400

> > Do you object to a requirement that it must be possible to
> > deploy the geopriv object in a standards based manner
> > such that authorization to reveal location information is 
> > handled out of band (by contract for example), rather than 
> > by explicit user action at the point of use?
> 
> Are you asking about only out-of-band, or setting up a default
> out-of-band with in-band control?  I would have no problem with the
> latter, I would have a problem with the former, there may well be
> times when I'd like to change my setting for a single call.
I claim that's an implementation issue.  We can offer some advice,
but we can't require that such an option be made available.

> 
> > I have no objection to the object having advice to implementers
> > on how to provide explicit user consent.  I strongly object
> > to requiring its use in all cases.
> 
> There is a set of times (e.g., US e911) where the information must be
> revealed in order to comply with local law.  Clearly, in that case,
> you can't require consent.  Are you using the term "explicit user
> consent" to mean that the user takes some GUI action per request, or
> in some other sense?   If you're saying that you object to the user
> being required to take action for each location request, then that's ok
> by me.  I have no problem with setting up consent settings that
> usually work.  If your objection is to the idea of explicit consent
> when I reveal my location, and such revelation is not required by law,
> I'd like to understand why you object to that.
I mean explicit consent at the point of use.  I see three possible 
ways to consent:
1. Out of band - no protocol action at all
2. Prior consent - action completed by some protocol mechanism that has
some lifetime (could be infinite)
3. Consent at the point of use

I object to having any requirements other than all of these should be
possible. I think there are valid deployment scenarios where consent
at the point of use is a bad idea, and deployment scenarios where
it is a good idea.  I don't object to a discussion in the security
considerations section where it discusses when consent MIGHT be
appropriate, but I don't believe there is any good reason why
we should go beyond offering such advice.

Consent at the point of use implies things about available UIs.  
I may not HAVE a suitable UI at the point of use.  That is my objection.
I also think the IETF has stayed away from any kind of UI discussions.
I think we should also.

Brian

---

From: Adam Shostack <[email-masked]>
Date: Mon, 20 Aug 2001 15:36:05 -0400

> 3. Consent at the point of use

Could we ammend 1 to say 'Out of band - protocol reminds end device
that choice has been made?'

This would allow me as an implementor to debug a possible error, adds
audit points, etc.  It does have a cost in bandwidth, and I know how
sensitive mobile folks are to that, but I expect that we can do this
with fairly few bits.

> we should go beyond offering such advice.

I don't see how we can assess privacy requirements without saying that
you must give choice and notice (amongst other things) to the
users.

> I also think the IETF has stayed away from any kind of UI discussions.

Its a valid objection, and I understand where you're coming from.  I
don't see how to reconcile privacy with the idea that I have no
ability to turn off tracking.  Are you suggesting ECRUSHEDBYAHAMMER as
a protocol response? ;)

Adam

-- 
"It is seldom that liberty of any kind is lost all at once."
					               -Hume