One document matched: draft-barnes-geopriv-policy-uri-01.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
There has to be one entity for each item to be referenced.
An alternate method (rfc include) is described in the references. -->
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs),
please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
(Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="4"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space
(using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" ipr="trust200902">
<!-- category values: std, bcp, info, exp, and historic
ipr values: full3667, noModification3667, noDerivatives3667
you can add the attributes updates="NNNN" and obsoletes="NNNN"
they will automatically be output with "(if approved)" -->
<!-- ***** FRONT MATTER ***** -->
<front>
<!-- The abbreviated title is used in the page header - it is only necessary if the
full title is longer than 39 characters -->
<title abbrev="LCP Policy URIs">Location Configuration Extensions for Policy Management</title>
<!-- add 'role="editor"' below for the editors if appropriate -->
<author fullname="Richard Barnes" initials="R.L." surname="Barnes">
<organization>BBN Technologies</organization>
<address>
<postal>
<street>9861 Broken Land Parkway</street>
<city>Columbia</city>
<region>MD</region>
<code>21046</code>
<country>US</country>
</postal>
<phone>+1 410 290 6169</phone>
<email>rbarnes@bbn.com</email>
</address>
</author>
<author initials="M." surname="Thomson" fullname="Martin Thomson">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>AU</country>
</postal>
<phone>+61 2 4221 2915</phone>
<email>martin.thomson@andrew.com</email>
</address>
</author>
<author initials="J." surname="Winterbottom" fullname="James Winterbottom">
<organization>Andrew Corporation</organization>
<address>
<postal>
<street>Andrew Building (39)</street>
<street>Wollongong University Campus</street>
<street>Northfields Avenue</street>
<city>Wollongong</city>
<region>NSW</region>
<code>2522</code>
<country>AU</country>
</postal>
<phone>+61 242 212938</phone>
<email>james.winterbottom@andrew.com</email>
</address>
</author>
<date month="May" year="2010" />
<!-- If the month and year are both specified and are the current ones, xml2rfc will fill
in the current day for you. If only the current year is specified, xml2rfc will fill
in the current day and month for you. If the year is not the current one, it is
necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the
purpose of calculating the expiry date). With drafts it is normally sufficient to
specify just the year. -->
<area>RAI</area>
<workgroup>GEOPRIV</workgroup>
<!-- WG name at the upperleft corner of the doc,
IETF is fine for individual submissions.
If this element is not present, the default is "Network Working Group",
which is used by the RFC Editor as a nod to the history of the IETF. -->
<keyword>geopriv, geolocation, privacy, policy</keyword>
<!-- Keywords will be incorporated into HTML output
files in a meta tag but they have no effect on text or nroff
output. If you submit your draft to the RFC Editor, the
keywords will be used for the search engine. -->
<abstract>
<t>Current location configuration protocols are capable of provisioning an Internet host with a location URI that refers to the host's location. These protocols lack a mechanism for the target host to inspect or set the privacy rules that are applied to the URIs they distribute. This document extends the current location configuration protocols to provide hosts with a reference to the rules that are applied to a URI, so that the host can view or set these rules.</t>
</abstract>
</front>
<middle>
<section anchor="intro-sec" title="Introduction">
<t>A critical step in enabling Internet hosts to access location-based services is to provision those hosts with information about their own location. This is accomplished via a Location Configuration Protocol (LCP) <xref target="RFC5687"></xref>, which allows a location provider (e.g., a local access network) to inform a host about its location.</t>
<t>There are two basic patterns for location configuration, namely configuration "by value" and "by reference" <xref target="RFC5808"></xref>. Configuration by value provisions a host directly with its location, by providing it location information that is directly usable (e.g., coordinates or a civic address). Configuration by reference provides a host with a URI that references the host's location, i.e., one that can be dereferenced to obtain the location (by value) of the host.</t>
<t>In some cases, location by reference offers a few benefits over location by value. From a privacy perspective, the required dereference transaction provides a policy enforcement point, so that the opaque URI itself can be safely conveyed over untrusted media (e.g., SIP through untrusted proxies <xref target="RFC5606"></xref>). If the target host is mobile, an application provider can use a single reference to obtain the location of the host multiple times, saving bandwidth to the host. For some configuration protocols, the location object referenced by a location URI provides a much more expressive syntax for location values than the configuration protocol itself (e.g., DHCP geodetic location <xref target="I-D.ietf-geopriv-rfc3825bis"></xref> versus GML in a PIDF-LO <xref target="RFC4119"></xref>). </t>
<t>From a privacy perspective, however, current LCPs are limited in their flexibility, in that they do not provide the Device (the client in an LCP) with a way to inform the Location Server with policy for how his location information should be handled. This document addresses this gap by defining a simple mechanism for referring to and manipulating policy, and by extending current LCPs to carry policy references. Using the mechanisms defined in this document, an LCP server (acting for the Location Server) can inform a client as to which policy document controls a given location resource, and the LCP client (in its Rule Maker role) can inspect this document and modify it as necessary.</t>
<t>The remainder of this document is structured as follows: After introducing a few relevant terms, we define policy URIs as a channel for referencing, inspecting, and updating policy documents. We then define extensions to the HELD protocol and the DHCP option for location by reference to allow these protocols to carry policy URIs. Examples are given that demonstrate how policy URIs are carried in these protocols and how they can be used by clients.</t>
</section>
<section anchor="def-sec" title="Definitions">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
<section anchor="policy-uri-sec" title="Policy URIs">
<t>A policy URI is an <xref target="RFC2616">HTTP</xref> URI that identifies a policy resource that contains the authorization policy for a linked location resource. Access to the location resource is governed by the contents of the authorization policy.</t>
<t>A policy URI identifies an HTTP resource that a Rule Maker can use to inspect and install policy documents that tell a Location Server how it should protect the associated location resource. A policy URI always identifies a resource that can be represented as a <xref target="RFC4745">common-policy document</xref> (possibly including some extensions; e.g., for <xref target="I-D.ietf-geopriv-policy">geolocation policy</xref>).</t>
<t><list style="hanging"><t hangText="Note:"><xref target="RFC3693">RFC 3693</xref> identified the Rule Holder role as the one that stores policy information. In this document, the Location Server is also a Rule Holder.</t></list></t>
<section anchor="policy-uri-usage-sec" title="Policy URI Usage">
<t>A Location Server that is the authority for policy URIs MUST support GET, PUT, and DELETE requests to these URIs, in order to allow clients to inspect, replace, and delete policy documents. Clients support the three request methods as they desire to perform these operations.</t>
<t>Knowledge of the policy URI can be considered adequate evidence of authorization. While the Location Server MAY deny any particular request according to local policy, it SHOULD allow all requests (with any of the three methods). This does not prevent a Location Server from applying local policy in determining how to authorize any of these requests. For instance, a Location Server might allow clients to inspect policy (GET), but not to update it (PUT).</t>
<t>A GET request to a policy URI is a request for the referenced policy information. If the request is authorized, then the Location Server sends an HTTP 200 response containing the complete policy identified by the URI.</t>
<t>A PUT request to a policy URI is a request to replace the current policy. The entity-body of a PUT request includes a complete policy document. When a Location Server receives a PUT request, it MUST validate the policy document included in the body of the request. If the request is valid and authorized, then the Location Server replaces the current policy with the policy provided in the request.</t>
<t>A DELETE request to a policy URI is a request to delete the referenced policy document and terminate access to the protected resource. If the request is authorized, then the Location Server deletes the policy referenced by the URI and disallows any further access to the location resource it governs.</t>
<t>The Location Server MUST support policy documents in the <xref target="RFC4745">common-policy format</xref>, as identified by the MIME media type of <spanx style="verb">application/auth-policy+xml</spanx>. The common-policy format MUST be provided as the default format in response to GET requests that do not include specific <spanx style="verb">Accept</spanx> headers, but content negotiation MAY be used to allow for other formats.</t>
<t>This usage of HTTP is generally compatible with the use of <xref target="RFC4825">XCAP</xref> or <xref target="RFC4918">WebDAV</xref> to manage policy documents, but this document does not define or require the use of these protocols.</t>
</section>
<section anchor="policy-uri-alloc-sec" title="Policy URI Allocation">
<t>A Location Server allocates a policy URI for a location resource; that is, the location resource that is referenced by a location URI. The URI of the policy resource MUST be different to the location URI.</t>
<t>The initial policy MUST be identical to the policy that would be applied if no policy URI is provided. A client that does not support policy URIs can continue to use location URIs as they would have previously.</t>
<t><list style="empty"><t>For DHCP and HELD, the client is forced to assume that the default policy grants access to any requester that is able to prove knowledge of a location URI. A client that wishes to specify a different policy updates the policy prior to distributing location URIs.</t></list></t>
<t>A Location Server chooses whether or not to provide a policy URI based on local policy. A HELD-specific extension also allows a requester to specifically ask for a policy URI.</t>
<t>A policy URI is a shared secret between Location Server and its clients. Knowledge of a policy URI is all that is required to perform any operations allowed on the policy. Thus, a policy URI is constructed so that it is hard to predict (see <xref target="sec-cons-sec"/>).</t>
</section>
</section>
<section anchor="extn-sec" title="Location Configuration Extensions">
<t>Location configuration protocols can provision hosts with location URIs that refer to the host's location. If the target host is to control policy on these URIs, it needs a way to access the policy that the Location Server uses to guide how it serves location URIs. This section defines extensions to LCPs to carry policy URIs that the target can use to control access to location resources.</t>
<section anchor="held-extn-sec" title="HELD">
<t>The HELD protocol <xref target="I-D.ietf-geopriv-http-location-delivery"></xref> defines a <spanx style="verb">locationUriSet</spanx> element, which contain a set of one or more location URIs that reference the same resource and share a common access control policy. The schema in <xref target="policy-uri-schema"></xref> defines two extension elements for HELD: an empty <spanx style="verb">requestPolicyUri</spanx> element that is added to a location request to indicate that a Device desires that a policy URI be allocated; and a <spanx style="verb">policyUri</spanx> element that is included in the location response.</t>
<figure anchor="policy-uri-schema">
<artwork><![CDATA[
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema
targetNamespace="urn:ietf:params:xml:ns:geopriv:held:policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:hp="urn:ietf:params:xml:ns:geopriv:held:policy"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<xs:element name="requestPolicyUri">
<xs:complexType name="empty"/>
</xs:element>
<xs:element name="policyUri" type="xs:anyURI"/>
</xs:schema>
]]></artwork>
</figure>
<t>The URI carried in a <spanx style="verb">policyUri</spanx> element refers to the common access control policy for location URIs in the location response. The URI MUST be a policy URI as described in <xref target="policy-uri-sec"></xref>. A policy URI MUST use the <spanx style="verb">http:</spanx> or <spanx style="verb">http:</spanx> scheme, and the Location Server MUST support the specified operations on the URI.</t>
<t>A HELD request MAY contain an explicit request for a policy URI. The presence of the <spanx style="verb">requestPolicyUri</spanx> element in a location request indicates that a policy URI is desired.
</t>
</section>
<section anchor="dhcp-extn-sec" title="DHCP">
<t>The DHCP location by reference option <xref target="I-D.ietf-geopriv-dhcp-lbyr-uri-option"></xref> provides location URIs in sub-options called LuriElements. This document defines a new LuriElement type for policy URIs.</t>
<t>
<list style="hanging" hangIndent="11">
<t hangText="LuriType=TBD ">Policy-URI - This is a policy URI that refers to the access control policy for the location URIs.</t>
</list>
</t>
<t>[NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned LuriType value and remove this note]</t>
<t>A Policy-URI LuriElement uses a UTF-8 character encoding.</t>
<t>A Policy-URI LuriElement identifies the policy resource for all location URIs included in the location URI option. The URI MUST be a policy URI as described in <xref target="policy-uri-sec"></xref>: It MUST use either the <spanx style="verb">http:</spanx> or <spanx style="verb">https:</spanx> scheme, and the Location Server MUST support the specified operations on the URI.</t>
</section>
</section>
<section anchor="example-sec" title="Examples">
<t>In this section, we provide some brief illustrations of how policy URIs are delivered to target hosts and used by those hosts to manage policy.</t>
<section anchor="held-example-sec" title="HELD">
<t>A HELD request that explicitly requests the creation of a policy URI has the following form:</t>
<figure><artwork><![CDATA[
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="true">locationURI</locationType>
<requestPolicyUri
xmlns="urn:ietf:params:xml:ns:geopriv:held:policy"/>
</locationRequest>
]]></artwork>
</figure>
<t>A HELD response providing a single <spanx style="verb">locationUriSet</spanx>, containing two URIs under a common policy, would have the following form:</t>
<figure><artwork><![CDATA[
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationUriSet expires="2011-01-01T13:00:00.0Z">
<locationURI>
https://ls.example.com:9768/357yc6s64ceyoiuy5ax3o
</locationURI>
<locationURI>
sip:9769+357yc6s64ceyoiuy5ax3o@ls.example.com:
</locationURI>
</locationUriSet>
<policyUri xmlns="urn:ietf:params:xml:ns:geopriv:held:policy">
https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b
</policyUri>
</locationResponse>
]]></artwork></figure>
</section>
<section anchor="dhcp-example-sec" title="DHCP">
<t>A DHCP option providing one of the location URIs and the corresponding policy URI from the previous example would have the following form:</t>
<figure><artwork><![CDATA[
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| option-code | 110 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 0 | 1 | 49 | 'h' |
+---------------+---------------+---------------+---------------|
| 't' | 't' | 'p' | 's' |
+---------------+---------------+---------------+---------------|
| ':' | '/' | '/' | 'l' |
+---------------+---------------+---------------+---------------|
| 's' | '.' | ... |
+---------------+---------------+---------------+---------------|
| TBD | 56 | 'h' 't' |
+---------------+---------------+---------------+---------------|
| 't' | 'p' | 's' | ':' |
+---------------+---------------+---------------+---------------|
| '/' | '/' | ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
]]></artwork></figure>
<t>[NOTE TO IANA/RFC-EDITOR: Please replace TBD above with the assigned LuriType value and remove this note]</t>
</section>
<section anchor="policy-example-sec" title="Basic access control policy">
<t>Consider a user that gets the policy URI <https://ls.example.com:9768/policy/357lp6f64prlbvhl5nk3b>, as in the above LCP example. The first thing this allows the user to do is inspect the default policy that the LS has assigned to this URI:</t>
<figure><artwork><![CDATA[
GET /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
HTTP/1.1 200 OK
Content-type: application/auth-policy+xml
Content-length: 388
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy"
xmlns:gp="urn:ietf:params:xml:ns:geolocation-policy">
<rule id="AA56ia9">
<conditions>
<validity>
<until>2011-01-01T13:00:00.0Z</until>
</validity>
</conditions>
<actions/>
<transformations>
<gp:provide-location/>
</transformations>
</rule>
</ruleset>
]]></artwork></figure>
<t>This policy allows any requester to obtain location information, as long as they know the location URI. If the user disagrees with this policy, and prefers for example, to only provide location to one friend, at a city level of granularity, then he can install this policy on the Location Server:</t>
<figure><artwork><![CDATA[
PUT /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
Content-type: application/auth-policy+xml
Content-length: 462
<?xml version="1.0" encoding="UTF-8"?>
<ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:friend@example.com"/>
</identity>
<validity>
<until>2011-01-01T13:00:00.0Z</until>
</validity>
</conditions>
<actions/>
<transformations>
<gp:provide-location
profile="civic-transformation">
<lp:provide-civic>city</lp:provide-civic>
</gp:provide-location>
</transformations>
</rule>
</ruleset>
HTTP/1.1 200 OK
]]></artwork></figure>
<t>Finally, after using the URI for a period, the user wishes to permanently invalidate the URI.</t>
<figure><artwork><![CDATA[
DELETE /policy/357lp6f64prlbvhl5nk3b HTTP/1.1
Host: ls.example.com:9768
HTTP/1.1 200 OK
]]></artwork></figure>
</section>
</section>
<section anchor="ack-sec" title="Acknowledgements">
<t>Thanks to Hannes Tschofenig, and Mary Barnes for providing critical commentary on the ideas described in this document.</t>
</section>
<section anchor="iana-sec" title="IANA Considerations">
<t>This document requires several IANA registrations, detailed below.</t>
<section anchor="iana-ns-sec" title="URN Sub-Namespace Registration for urn:ietf:params:xml:ns:geopriv:held:policy">
<t>This section registers a new XML namespace, <spanx style="verb">urn:ietf:params:xml:ns:geopriv:held:policy</spanx>, per the guidelines in <xref target="RFC3688"></xref>.
<list style="empty" hangIndent="3">
<t>URI: urn:ietf:params:xml:ns:grip</t>
<t>Registrant Contact: IETF, GEOPRIV working group, (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com).</t>
<t>XML: <figure>
<artwork><![CDATA[
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN"
"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
<head>
<title>HELD Policy URI Extension</title>
</head>
<body>
<h1>Namespace for HELD Policy URI Extension</h1>
<h2>urn:ietf:params:xml:ns:geopriv:held:policy</h2>
[NOTE TO IANA/RFC-EDITOR: Please replace XXXX
with the RFC number for this specification.]
<p>See RFCXXXX</p>
</body>
</html>
END
]]></artwork>
</figure></t>
</list></t>
</section>
<section anchor="iana-schema-sec" title="XML Schema Registration">
<t>This section registers an XML schema as per the guidelines in <xref target="RFC3688"></xref>.
<list style="hanging" hangIndent="3">
<t hangText="URI:"> urn:ietf:params:xml:schema:geopriv:held:policy</t>
<t hangText="Registrant Contact:">IETF, GEOPRIV working group (geopriv@ietf.org), Richard Barnes (rbarnes@bbn.com)</t>
<t hangText="Schema:">The XML for this schema can be found in Section <xref target="held-extn-sec"></xref>.</t>
</list>
</t>
</section>
<section anchor="iana-dhcp-sec" title="DHCP LuriType Registration">
<t>IANA is requested to add a value to the LuriTypes registry, as follows:</t>
<figure><artwork><![CDATA[
+------------+----------------------------------------+-----------+
| LuriType | Name | Reference |
+------------+----------------------------------------+-----------+
| TBD* | Policy-URI | RFC XXXX**|
+------------+----------------------------------------+-----------+
* TBD is to be replaced with the assigned value
** RFC XXXX is to be replaced with this document's RFC number.
]]></artwork></figure>
</section>
</section>
<section anchor="sec-cons-sec" title="Security Considerations">
<t>There are two main classes of risks associated with access control policy management: The risk of unauthorized disclosure of the protected resource via manipulation of the policy management process, and the risk of disclosure of policy information itself.</t>
<t>Protecting the policy management process from manipulation entails two primary requirements: First, the policy URI has to be faithfully and confidentially transmitted to the client, and second, the policy document has to be faithfully and confidentially transmitted to the Location Server. The mechanism also needs to ensure that only authorized entities are able to acquire or alter policy.</t>
<section title="Integrity and Confidentiality for Authorization Policy Data">
<t>Each LCP ensures integrity and confidentiality through different means (see <xref target="I-D.ietf-geopriv-http-location-delivery"/> and <xref target="I-D.ietf-geopriv-dhcp-lbyr-uri-option"/>). These measures ensure that a policy URI is conveyed to the client without modification or interception.</t>
<t>To protect the integrity and confidentiality of policy data during management, the Location Server SHOULD provide policy URIs with the <spanx style="verb">https:</spanx> scheme and require the use of <xref target="RFC2818">HTTP over TLS</xref>. The cipher suites required by <xref target="RFC5246">TLS</xref> provide both integrity protection and confidentiality. If other means of protection are available, an <spanx style="verb">http:</spanx> URI MAY be used.</t>
</section>
<section title="Access Control for Authorization Policy">
<t>Access control for the policy resource is based on knowledge of its URI. The URI of a policy resource operates under the same constraints as a <xref target="RFC5808">possession model location URI</xref> and is subject to the same constraints:
<list style="symbols">
<t>Knowledge of a policy URI MUST be restricted to authorized Rule Makers. Confidentiality is required for its conveyance in the location configuration protocol, and in the requests that are used to inspect, change or delete the policy resource.</t>
<t>The Location Server MUST ensure that the URI cannot be easily predicted. The policy URI MUST NOT be derived solely from information that might be public, including the Target identity or any location URI. The addition of random entropy increases the difficulty of guessing a policy URI.</t>
</list></t>
<!-- <t>Additional requestor authentication MAY be used for policy resources. For instance, in the particular case where the Device is identified to the Location Server by its IP address, the Location Server could use IP return routability as an additional authentication mechanism.</t> -->
</section>
<section title="Location URI Allocation">
<t>A policy URI enables the <xref target="RFC5808">authorization by access control lists model</xref> for associated location URIs. Under this model, it might be possible to more widely distribute a location URI, relying on the authorization policy to constrain access to location information.</t>
<t>To allow for wider distribution, authorization by access control lists places additional constraints on the construction of location URIs.</t>
<t>If multiple Targets share a location URI, an unauthorized location recipient that acquires location URIs for the Targets can determine that the Targets are at the same location by comparing location URIs. With shared policy URIs, Targets are able to see and modify authorization policy for other Targets.</t>
<t>To allow for the creation of Target-specific authorization policies that are adequately privacy-protected, every location URI and policy URI that is issued to a different Target MUST be different. That is, no two client can receive the same location URI or policy URI.</t>
<t>In some deployments it is not always apparent to a LCP server that two clients are different. In particular, where a <xref target="RFC3234">middlebox</xref> exists two or more clients might appear as a single client. An example of a deployment scenario of this nature is described in <xref target="RFC5687"/>. In these scenarios, it is RECOMMENDED that a different location URI and policy URI be provided for every request.</t>
</section>
</section>
</middle>
<!-- *****BACK MATTER ***** -->
<back>
<references title="Normative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2616.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.2818.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4745.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5246.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3688.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-http-location-delivery"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-dhcp-lbyr-uri-option"?>
</references>
<references title="Informative References">
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3234.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.3693.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4119.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4825.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.4918.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5606.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5687.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml/reference.RFC.5808.xml"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-policy"?>
<?rfc include="http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-geopriv-rfc3825bis"?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-23 23:16:22 |