Subject: RE: [Geopriv] New draft: Location Object Authorization Policies

From: [email-masked]
Date: Wed, 3 Sep 2003 09:38:41 -0400

I agree with Henning that we clearly have to differentiate the different notions of "anonymous" here.
Access as "anonymous" user is one, I don't quite know what "anonymous access" would be though. Is it 
indeed access as an "anynomous" user (if so, we need to say this more clearly)? 

Or is it access by parties (not necessarily as "anonymous" user) which are not explicitly put into 
the authorization policy. Instead, the accessing user, for instance, presents some information to 
the location server that can be used to authorize the access. That's how I understood the token notion.

Dirk

>-----Original Message-----
>From: ext Henning Schulzrinne [mailto:[email-masked]]
>Sent: Tuesday, September 02, 2003 9:09 PM
>To: Trossen Dirk (NRC/Boston)
>Cc: [email-masked]; [email-masked]
>Subject: Re: [Geopriv] New draft: Location Object 
>Authorization Policies
>
>
>Note that some such mechanisms already exist. On most systems, you can 
>trivially create user accounts for Digest (SIP and HTTP) or (for HTTP) 
>Basic authentication. If the anonymous user can obtain the 
>user name and 
>password (e.g., by having them mailed to them, put them on my business 
>card or post them in the subway), he or she gets access. This requires 
>no more revealing of personal information than signing up for a 
>web-based email account.
>
>Thus, I'm a bit confused by the whole notion of anonymous access. We 
>need to be able to clearly distinguish this from existing notions.
>
>
>[email-masked] wrote:
>
>> Hi all,
>> 
>> in Section 2.2. of the draft, you're referring to 
>> "Currently there is no provision in [XCAP-USAGE] to provide
>>    authorization for anonymous access to location 
>information (e.g. by
>>    using tokens). A proposal will be described in a separate 
>document."
>> 
>> Do I understand such "anonymous access to location 
>information" as a kind of "on-the-fly" access 
>> for not previously defined parties that present a certain 
>token for access? In this, has the work 
>> on said proposal for such "anonymous access" already 
>started? This would need to address integration 
>> in XCAP but also the actual provisioning of the required 
>information. 
>> 
>> BTW, this kind of access would also be of interest for 
>presence information in general.
>> 
>> Regards,
>> 
>> Dirk
>> 
>> 
>>>-----Original Message-----
>>>From: ext Tschofenig Hannes [mailto:[email-masked]]
>>>Sent: Tuesday, September 02, 2003 11:12 AM
>>>To: [email-masked]'
>>>Subject: [Geopriv] New draft: Location Object Authorization Policies
>>>
>>>
>>>hi all, 
>>>
>>>as part of our geopriv interim meeting preparations we have 
>>>compiled a new
>>>draft. the draft is a joint effort of john morris, henning 
>schulzrinne,
>>>jorge cuellar, james polk and myself. 
>>>
>>>you will find the draft at: 
>>>http://www.tschofenig.priv.at/drafts/draft-tschofenig-geopriv-aut
hz-00.txt
>>
>>ciao
>>hannes
>>
>>
>>_______________________________________________
>>Geopriv mailing list
>>[email-masked]
>>https://www1.ietf.org/mailman/listinfo/geopriv
>>
> 
> 
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/geopriv

_______________________________________________
Geopriv mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Wed, 03 Sep 2003 09:46:19 -0400

> the location server that can be used to authorize the access. That's how I understood the token notion.

But that's exactly the same thing. If somebody presents a token, I have 
to have a way of checking that it is valid. If we assume that the 
querying entity does not have a public/private key pair, the data source 
needs to store the list of valid keys somewhere. How does this 
materially differ from installing username/secret pairs in Digest 
authentication?

There are variations that are of some interest, involving two parties 
that only share a secret. The first party (verifier) could hand the 
querier a token that somehow reflects its properties, e.g., its IP 
address. The data source can then verify that the querier has asked the 
verifier for permission. Is that what you have in mind?