You message made me realize that my carefully crafted a response to Robert had not been CC'ed the group.
Kind of like you said, my reading of the section that Robert cites was more that the access control model is just harder to implement in practice than the possession model. For example, the lack of a global authentication system makes it hard to enforce policies based on requester identity.
Suggested text:
NEW:
"
However, the lack of a uniform authentication infrastructure for the Internet means that certain access control policies will be difficult to implement in practice, especially policies based on the identity of the requestor.
"
OLD:
"
A possible format for these authorization policies is available with GEOPRIV Common Policy [RFC4745] and Geolocation Policy [I-D.ietf-geopriv-policy].
"
NEW:
"
A possible format for these authorization policies is available with GEOPRIV Common Policy [RFC4745] and Geolocation Policy [I-D.ietf-geopriv-policy]. If a device receives location URIs via DHCP or HELD, the location server may also provided with a policy URI that can be used to provision privacy policy [I-D.ietf-geopriv-policy-uri].
"
NEW:
[informative reference to draft-ietf-geopriv-policy-uri]
Thoughts?
--Richard
On Oct 12, 2011, at 10:34 PM, Thomson, Martin wrote:
> On 2011-10-12 at 04:30:00, Robert Sparks wrote:
>> There is some text that I think could be further improved before
>> publishing this as an RFC.
>> The following notion appears several times in the document:
>>
>> However, no authentication framework is provided, which
>> limits the policy options available when the "Authorization by
>> Access
>> Control" model is used.
>> There is other work coming from this working group that supports the
>> authorization
>> by access control model. Is the point of these phrases to highlight
>> that other documents
>> are needed to make authorization by access control more useful? Or is
>> it to note that the
>> current tools deployed for authentication over http make authorization
>> by access
>> difficult.
>
> The intent was to simply highlight an area where a commonplace or reasonable assumption (that identity-based access control is an option) could lead to an unexpected conclusion. HTTP authentication doesn't work until you put in a lot of ground-work: identifying principals, deciding on realms, authentication credentials, trust anchors, and much more. We don't define them here, so it would be dishonest to even give the impression that HTTP authentication is going to work.
>
> Whether or not we ever get to the point that we can reliably use (client) authentication in HTTP, I don't want to speculate.
>
>> As written, I expect readers who have not been following this work
>> closely to interpret the phrase to mean that the group chose not to provide a framework and
>> thus doesn't
>> expect people to use authorization by access control much.
>
> I didn't think that it was a good idea to presume anything about how a specification would be deployed. But your conclusion is the exact one that I would hope that readers take away.
>
> Given the maturity of -policy-uri, it might improve the situation by adding a citation in Section 3.2. That might at least point a reader in the right direction.
>
> --Martin
> _______________________________________________
> 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
