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.
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.
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. Thus, using SIP, it is possible to fulfil this rule condition:
<identity>
<one id="sip:alice@example.com"/>
</identity>
But, regardless of the protocol in use, this makes no sense:
<identity>
<one id="http://bob@example.com/"/>
</identity>
(For one, that's a resource, not an entity.)
This has been characterized as a problem. A missing piece. A paragon example of "magic happens here".
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).
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.
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.
--Martin
Acknowledgements: I have to credit Richard with much of this, or at least for dropping the first clue.
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
