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