It looks like most of this is an artefact of my inability to generate sane prose :) I
> 3.1 says:
...
> I find the multiple caveats here to be confusing. I think the outcome
> you're looking for is that an LS SHOULD allow all requests, but it MAY
> deny certain requests based on local authorization policy (e.g.,
> allowing GETs but not PUTs, or only allowing dereferences from certain
> clients). Is that right?
Correct. I'll take a second go at this.
> 3.2: This section discusses both policies for access to location and
> policies for access to policy URIs. Combining them like this is pretty
> confusing, and I'm not sure that either part is complete. For access
> to location, you say that the default policy has to be what it would
> be if there were no policy, but you don't say what the default policy
> is. The example in 5.3 suggests that the default policy's
> transformations are
>
> <transformations>
> <gp:provide-location/>
> </transformations>
>
> Didn't the default policy used to also include retransmission-allowed
> = FALSE and retention-expiry = 24 hours? What happened to those?
Thanks. We should be explicit about what the default policy is. And I missed those.
> For access to policy URIs, it says
>
> "A Location Server chooses whether or not to provide a policy URI
> based on local policy."
>
> I'm confused about the LS "providing" a URI in HELD. You describe a
> mechanism in 5.1 for *creating* a URI. But how does an LS provide a
> URI that has previously been created?
It doesn't have to and it probably should not. I'll expand on this below.
> If a Target issues the HELD
> request in 5.1, and then a third party issues a query containing both
> a "requestPolicyUri" element and a "device" element, does the original
> URI get overwritten? Or is that the point at which the "local policy"
> referenced above gets checked to see whether the third party is
> authorized to overwrite (or receive?) the URI?
A policy URI applies to a single location URI - if we haven't then we'd better fix it.
Following on from this, we don't want to provide the same location URI to uncorrelated requests for the same Target, which means different policy URIs. Some text on this would be a good idea. I think that there might be something in RFC5808 on uniqueness of URIs, but if there isn't we should make explicit note of it.
The main reason for this is that a single Target from the perspective of the LIS, could actually be several different devices and - by extension - people. These people can have different preferences and policies and they might want to ensure that their policies (and identity) remain distinct. Once you start attributing policy to URIs, giving each a unique location URI ensures that they don't trample on each other's policies. Even the ability to see another person's policy is sufficient reason for separation.
When you add a third party into the equation, it gets even worse. For instance, you don't want your service provider messing with your policy. If they have to set policy, then they can (and should) do so transparently by altering the initial policy you get for the location URI and preventing you from destroying their rules.
Of course, uniqueness of URIs matters considerably less for pure authorization by possession.
Obviously, this needs text. I'll propose something later.
> As to your question below about LSes providing other policy URIs,
> since the requests aren't coming via HELD or DHCP, what would you
> intend to specify other than making a generic statement that an LS can
> hand out policy URIs via other protocols? It seems like an LS that
> implements other protocols could do that already if it wanted to.
The idea that a policy URI applies to a specific location URI tends to bias me against what Richard is talking about. The same underlying reasons apply.
>
> Alissa
_______________________________________________
Geopriv mailing list
Geopriv@ietf.org
https://www.ietf.org/mailman/listinfo/geopriv
