Subject: Re: [Geopriv] Deploying authorization policy

From: "Tschofenig, Hannes (NSN - FI/Espoo)" <[email-masked]>
Date: Thu, 1 Apr 2010 15:07:19 +0300

Hi Martin, 

>I'm a big fan of authorization by possession.  It has a 
>certain elegance to it.
>
>In comparison, authorization by access control is a more 
>difficult beast to tame.  If we assume that access control 
>relies on the authenticated identity of a location recipient, 
>then we need a good framework for authentication.

There is no free lunch with any of these mechanisms. I guess we can
agree on that part. 

>
>Given the deployment model, this framework must describe how a 
>location server authenticates requests.  This is especially 
>difficult because, in the expected deployment model, location 
>recipients have no prior relationship with the location server.

Correct. 

>
>HTTP doesn't have a framework for inter-domain authentication. 
> On the other hand, RFC 4474 describes how an authority can 
>provide assurances about an entity that makes a request.  

SIP (and XMPP) in general has a story for how to provide the
authenticated identity of the initiating party to the receiving party. 

For HTTP the history is a bit different but there is plenty of work for
providing inter-domain authentication. At the time when we worked on the
geolocation authorization policy it was, however, a bit too early to
reference something.

>Thus, using SIP, it is possible to fulfil this rule condition:
>
>    <identity>
>        <one id="sip:[email-masked]"/>
>    </identity>
>
>But, regardless of the protocol in use, this makes no sense:
>
>    <identity>
>        <one id="http://[email-masked]/"/>
>    </identity>
>
>(For one, that's a resource, not an entity.)

This specific example makes no sense but if you put an OP Endpoint URL
in there then it suddenly makes a lot of sense. 

>
>This has been characterized as a problem.  A missing piece.  A 
>paragon example of "magic happens here".

Not really. 

The geolocation policy draft is only a piece in a larger puzzle. The
same is true for Common Policy. The identities described in Common
Policy are abstract, so are a number of other elements. They have to be
"instantiated" with a specific protocol. RFC 5025 describes one such
usage, and it actually very nicely describes the topic that you touch
here:

"
   Although the <identity> element is defined in [8], that specification
   indicates that the specific usages of the framework document need to
   define details that are protocol and usage specific.  In particular,
   it is necessary for a usage of the common policy framework to:

   o  Define acceptable means of authentication.

   o  Define the procedure for representing the identity of the WR
      (Watcher/Requestor) as a URI or Internationalized Resource
      Identifier (IRI) [13]. 
"
http://tools.ietf.org/html/rfc5025#section-3.1.1
 
>
>A few years back, I was convinced that this problem should and 
>could be solved.  It didn't take much research into SAML and 
>OpenID and their ilk to disabuse me of the notion that there 
>was a solution.
>
>I've recently concluded that this "problem" doesn't need to be solved.
>
>Examine the use case:  There are groups of people that you 
>want to authorize to different degrees.  One group is not 
>authorized at all.  Another group is authorized to acquire 
>location with no constraints.  Other groups are authorized 
>with various limitations: time, accuracy, location, etc...
>
>Here's a clue: authorization policy allows for more than just 
>a straight Boolean allow/deny decision based on identity.
>
>Here's another clue: authentication is typically achieved by 
>having the subject prove knowledge of a piece of information.  
>For PKI, this is a private key; for basic or digest, this is a 
>username and password; for authorization by possession, this 
>is the location URI.
>
>Simple authorization by possession uses selective disclosure 
>to separate recipients into just two groups: those who are 
>allowed to receive location (and who get a location URI), and 
>those who aren't (and remain ignorant of the location URI).
>
>To "solve" the problem, recipients are separated into groups 
>by giving each group a different location URI.
>
>The location URI becomes a substitute for the <identity> condition.
>
>Each location URI is assigned a different policy.  That policy 
>does not include <identity> conditions - it doesn't need to.  
>Instead, it contains all the other wonderful policy controls 
>that we've defined: time-based conditions, location 
>obfuscation, and so forth.
>
>If you want to treat a particular recipient specially, then 
>mint a location URI just for them and ensure that they are the 
>only ones who get that URI (and that URI is the only one they 
>can use to locate you).

This is definitely an option to mint new URL and hand them out to
different parties. 
That's not particularly new for me though. 

>
>Where disclosure cannot be controlled sufficiently to 
>segregate potential recipients into the desired groups, it's 
>possible to fall back on identity.  That is where SIP, with 
>all the glory of RFC 4474, comes into play.  A LIS can provide 
>SIP location URIs directly, or an HTTP location URI can be 
>indirectly published to a presence server.

It is certainly true that you want to have both mechanisms. 

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. 

(This makes me wonder what the future of
http://tools.ietf.org/id/draft-garcia-geopriv-indirect-publish-01.txt
is.)

>
>HELD provides a location URI set that can contain both HTTP 
>and SIP URIs.  For the resource that these identify, it would 
>be reasonable to allow for the inclusion of policy that 
>allowed for both forms of authentication.
>
>Rules containing identity conditions would only apply to SIP 
>requests; these rules might grant greater access than might 
>otherwise be granted.  Any rule containing <identity> 
>conditions would not apply to an HTTP/HELD dereference.
>
>This is the story I hope to tell with the HELD dereference 
>draft.  It's also the story that will make policy additions 
>work with HELD.  I also hope that Hannes' proposal for the 
>DHCP location URI draft tells a story that is consistent with this.

I thought about this issue when I was working on the HELD deref
document. 
Initially, my believe was that we have to go as far as RFC 5025 in
describing the mapping of identity information. However, my work on
identity management protocols told me something else. With identity
management protocols the community is somewhat different and location is
only a minor piece and not the driving force. Hence, the direction from
which people are approaching the problem is more or less the opposite
from the GEOPRIV group: location is just an extension to an existing
OpenID, Oauth, SAML, etc. mechanism. They are not going to use the HELD
deref document. So, it is helpful to worry about that problem since
these folks have not worked on a standardized authorizatoin policy for
the all the other things. I doubt that they will be particularly
interested in the authorization policy for location. 

The conclusion is the same but the path I got there is different. 

Ciao
Hannes

>--Martin
>
>Acknowledgements: I have to credit Richard with much of this, 
>or at least for dropping the first clue.
>

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 2 Apr 2010 17:06:38 -0400

> 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

---

From: Richard Barnes <[email-masked]>
Date: Fri, 2 Apr 2010 17:40:20 -0400

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:

> 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
>
> _______________________________________________
> Geopriv mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/geopriv

---

From: Henning Schulzrinne <[email-masked]>
Date: Fri, 2 Apr 2010 17:50:50 -0400

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.

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:
> 
> 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>
> 
> So it seems like the market is refuting your hypothesis about user preferences.
> 
> --Richard
> 
> 
>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 05 Apr 2010 14:25:29 -0500

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

> > 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:
> >
> > 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:
> >
> > 
> >> 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

---

From: Richard Barnes <[email-masked]>
Date: Mon, 5 Apr 2010 15:47:13 -0400

James,

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:

>> 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.
>
> 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  
> 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?
>

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Apr 2010 07:37:22 +0800

This is a salient point.  Richard's example only casts doubt on what user expectations actually are.  I don't have a research budget that could be used on a survey or study to determine what users might think when presented with such a URI.

If it were simply a matter of managing expectations, it might be as simple as re-branding the identifier: rather than "location URI" we could label it the "where I am right now URI".  Or, we could rely on good UI to make the consequences clear.

In all cases, I'd like to temper this with the observation that this particular mode - that of location recipients coming directly to a LIS for their location information - is not necessarily the best option.  In my view, a presence service - with a stable identifier for the Target - is a more usable option.

--Martin

> -----Original Message-----
> From: Henning Schulzrinne [mailto:[email-masked]]
> Sent: Saturday, 3 April 2010 8:51 AM
> To: Richard Barnes
> Cc: Tschofenig, Hannes (NSN - FI/Espoo); [email-masked]; Thomson,
> Martin
> Subject: Re: [Geopriv] Deploying authorization policy
> 
> 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.
> 
> Henning
> 
> 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:
> >
> 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
> >>

---

From: "James M. Polk" <[email-masked]>
Date: Mon, 05 Apr 2010 19:53:57 -0500

Richard

Once upon a time -- in the DHC WG -- I got absolutely plastered for 
suggesting more than one URI get requested in a DHCP response. That 
WG had a cow about the idea that so many (what is currently called) 
sub-options (which are unique URI types each having unique meanings) 
*because* , and I'm paraphrasing "you're expecting DHCP to be a 
complicated protocol - able to handle each of these sub-options for 
each client."  What they were trying to tell me is that DHCP is a 
simple protocol, and not to clutter it up with so many different 
possible combinations - each of which are unique to each client.

DHC may have changed their tune over the years, but consensus was 
near unanimous that 1 Option code equals 1 URI type.

What they were saying at the time is they felt they had enough Option 
numbers available for each URI purpose.  I read below that you are 
suggesting at least 2 different URI purposes
- 1 that has unrestricted access
- 1 that provides access to within 50km

DHC WG will - if they haven't changed their collective minds - will 
say these two are 2 different DHCP Option codes.

James

---

From: Henning Schulzrinne <[email-masked]>
Date: Mon, 5 Apr 2010 22:20:38 -0400

> If it were simply a matter of managing expectations, it might be as simple as re-branding the identifier: rather than "location URI" we could label it the "where I am right now URI".  Or, we could…

Except that the UI really can't do this, easily (except in cases where the users hands these out manually). This gets particularly confusing if you have multiple versions of similar-looking URLs with very different access properties:

http://lis.com/alice/293590D256FBEE1F75E816
hands out the current location (one location);
http://lis.com/alice/293590D256FBEE1F75E817
hands out locations from now to eternity.

Somebody is likely to get bitten by this, badly...

> In all cases, I'd like to temper this with the observation that this particular mode - that of location recipients coming directly to a LIS for their location information - is not necessarily the b…

Agreed. While there is no difference in theory, in practice, the plain possession URL is more prone to inadvertent or malicious forwarding to others (or posting on a blog or web site). This is a limited problem when this is a location snapshot, particularly if there's no timing information included. ("Alice was at the Empire State Building at some point in time" isn't much of a secret; naturally, "Alice was at an abortion clinic" more so.) It's a big problem if that URL provides on-going tracking access; the target may not even realize that their information has been compromised since they won't see the location accesses.

People are much more reluctant and unlikely to give all their friends their SIP or XMPP credentials, so the presence mode does seem safer. (Naturally, anybody can build a proxy that makes some of their information available to the world at large, but that requires actual malice and non-trivial technical skills.)

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Apr 2010 11:24:44 +0800

> Except that the UI really can't do this, easily (except in cases where
> the users hands these out manually).

Without wanting to go "no true Scotsman" on this discussion, the implied involvement of a user requires greater analysis.

To what extent do we expect a user to interact with URIs?  While I'm happy to discuss the implications on usability, I personally don't expect a user to be so intimately involved in the process.

More likely, to my mind, is this sort of question: "Do you wish to allow this site to track your movements?"  With the specific mechanism hidden thus, such concerns might be assuaged.

> This gets particularly confusing
> if you have multiple versions of similar-looking URLs with very
> different access properties:

The only reasonable response here is to treat all URLs as they should be treated - as opaque identifiers.  If context identifies these as location URIs, then the safest course is to assume the worst: that it can be used to track some target.

--Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Apr 2010 11:39:56 +0800

James,

> What they were trying to tell me is that DHCP is a

What I think is being suggested is that a DHCP client could request or receive multiple URIs.  Each URI could have different policy attributed to it.  The specific _how_ I think is left to the reader.

> say these two are 2 different DHCP Option codes.

I don't think that this is the case - these were just examples.  Probably more pertinent would be my discussion - say you divide your friends list into several groups: family, poker buddies, cricket team, work colleagues, mistresses (to list one possible taxonomy).  If you wish to apply different policy to each, then you need a different URI for each group.  That's a lot more than two, and certainly a poor use of the limited option code space.

One realization in DHCP has the server provide a limited number of URIs when requested.  (Repeated sub-options might work with DHCP lbyr, but don't let the specifics get in the way of the example.)  Another choice would be to have the client make several requests, with each request getting a different response.

Each URI is then allocated a policy by the client.  In this proposal, each location URI has a matching policy URI.  The client updates the policy for the location URI by changing the document at the policy URI.

So, the client designates a location URI as being for colleagues.  Before handing that URI out, they create an appropriate policy at the matching policy URI.

--Martin

---

From: "Thomson, Martin" <[email-masked]>
Date: Tue, 6 Apr 2010 11:50:14 +0800

Hi Hannes,

I don't think that there's a problem with the conclusion, but I have a few comments.

> geolocation authorization policy it was, however, a bit too early to

You're closer to OpenID than I, but my reading of the specification throws doubt on its suitability for this sort of application.  

Do you believe that we're any closer to getting a mechanism that could be referenced in the same fashion that we might reference something like RFC 4474?

> That's not particularly new for me though.

I'm glad you think so.  It wasn't intended to be a surprise :)

> It is certainly true that you want to have both mechanisms.

Actually, I'm not sure that this is true, but there's enough uncertainty in that statement that I'm willing to continue exploring the consequences of providing both.  Then we can see what works when the dust settles.
 
> users are expected to hand around new URLs all the time 

I'd like to challenge that assumption.  The definition of "user" in this discussion probably needs greater scrutiny.  I just said the same to Henning.

> http://tools.ietf.org/id/draft-garcia-geopriv-indirect-publish-01.txt

I've got a separate email on that coming ;)

> The conclusion is the same but the path I got there is different.

That's reassuring. 

--Martin