draft-barnes-geopriv-policy-uri draft describes a really simple
mechanism for enabling clients to inspect and control what policies
apply to a URI. Here's an example scenario:
1. LIS provides a client with one URI that provides unrestricted
access (no policy), and one URI provides access to within 50km, with
corresponding policy URIs.
2.1. Client sends HTTP GET for policy URI 1
2.2. Policy server returns 404
2.3. Client understands no policy == open access
2.4. (Optional) Client sends HTTP PUT with his own policy
3.1. Client sends HTTP GET for policy URI 2
3.2. Policy server returns 200 with:
<ruleset>
<rule>
<conditions/>
<actions/>
<transformations>
<provide-location profile="geodetic-transformation">
<provide-geo radius="50000"/>
</provide-location>
</transformations>
</rule>
</ruleset>
3.3. Client sees that this is a "coarse location" URI
3.4. (Optional) Client sends HTTP PUT with his own policy
HELD already supports delivering multiple URIs. DHCP could, by
allowing more sub-options (LURItypes).
--Richard
On Apr 5, 2010, at 3:25 PM, James M. Polk wrote:
> At 04:50 PM 4/2/2010, Henning Schulzrinne wrote:
>> I suspect there are shades of gray here. It's clearly used for
>> pictures (or albums), not so much for larger-scale access (e.g.,
>> all my Picasa pictures or the whole Facebook profile). Thus, I
>> suspect a "secret" location URL that reveals where I am at 5 pm
>> today may not raise much of an eyebrow, but a URL that allows
>> tracking me from today until next December more so. To their
>> credit, Picasa also does a pretty decent job of explaining how to
>> use this URL, e.g., by showing an HTML snippet.
>
> That said -- it appears Richard has successfully pointed out how
> different Location URIs can be used. How exactly is this supposed
> to be translated into an LCP's delivery of the URIs? Currently DHCP
> is being proposed to only have 1 Location URI sent to a client about
> its location. The client isn't really going to be able to tell which
> resolution (or granularity or accuracy) this URI will provide to a
> dereferencer. That makes this inconsistent with what this thread is
> offering.
>
> Does HELD have this level of control as an LCP -- i.e., to be able
> to give an endpoint multiple location URIs, each with differing --
> but known to the endpoint -- purposes?
>
> This level of complication/complexity isn't something I've heard the
> WG talk about previously.
>
> James
>
>
>> Henning
>>
>> On Apr 2, 2010, at 5:40 PM, Richard Barnes wrote:
>>
>> > Henning,
>> >
>> > It seems to me that the the "random stuff in a URI"
>> authentication scheme is already really used today. For example,
>> say I post pictures to Picasa. I can mark albums as public or
>> private, and only the public albums show up on my user page when a
>> random stranger views it, at a URI of the form:
>> >
>> > <http://picasaweb.google.com/username>
>> >
>> > However, when I as the owner load a picture or album page, it
>> provides a URI that I can send to anyone that will show them the
>> picture (but nothing else) or one that shows the album. These URIs
>> have the form:
>> >
>> > <http://picasaweb.google.com/username/albumname?authkey=293590D256FBEE1F75E816
>> >
>> >
>> > (Borrowing Henning's random bytes.)
>> >
>> > So it seems like the market is refuting your hypothesis about
>> user preferences.
>> >
>> > --Richard
>> >
>> >
>> >
>> > On Apr 2, 2010, at 5:06 PM, Henning Schulzrinne wrote:
>> >
>> >>>
>> >>> One thing that I believe where some misunderstanding starts is
>> that
>> >>> users are expected to hand around new URLs all the time
>> (whenever they
>> >>> fetch new onces from their LIS). This is in theory possible but
>> in
>> >>> practice that might be difficult. Instead, it is more likely
>> that one
>> >>> would want to publish location to a server that fulfills
>> already other
>> >>> rules (such as a presence server alike concept; you could even
>> call
>> >>> Yahoo's FireEagle, Ovi Chat, Google's Latitude). Other uses
>> have a
>> >>> long-term contact point to go to for many reasons already.
>> >>
>> >> On a side note: One of the problems with by-possession URLs is
>> that the semantics are not always clear to the user. In other
>> words, by looking at the URL, users can't tell that they are giving
>> away their location, for example. People include URLs in email
>> messages, Twitter posts and web pages all the time, without fully
>> understanding the semantics and the consequences. I suspect people
>> would be upset if
>> >>
>> >> http://www.facebook.com/henning.schulzrinne
>> >>
>> >> just gave public access (as it does today), while
>> >>
>> >> http://www.facebook.com/henning.schulzrinne/293590D256FBEE1F75E816
>> >>
>> >> gave full access to everything, without further authentication.
>> >>
>> >> Henning
>> >> _______________________________________________
>> >> Geopriv mailing list
>> >> Geopriv@ietf.org
>> >> https://www.ietf.org/mailman/listinfo/geopriv
>> >
>> >
>>
>> _______________________________________________
>> Geopriv mailing list
>> Geopriv@ietf.org
>> https://www.ietf.org/mailman/listinfo/geopriv
>
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
