[要約] RFC 6753は、HTTPを使用した場所の参照プロトコルであるHELDに関するものです。このRFCの目的は、モバイルデバイスの位置情報を効率的に取得するための標準化を提供することです。
Internet Engineering Task Force (IETF) J. Winterbottom
Request for Comments: 6753 Commscope
Category: Standards Track H. Tschofenig
ISSN: 2070-1721 Nokia Siemens Networks
H. Schulzrinne
Columbia University
M. Thomson
Microsoft
October 2012
A Location Dereference Protocol Using HTTP-Enabled Location Delivery (HELD)
HTTP対応ロケーション配信（HELD）を使用したロケーション逆参照プロトコル
Abstract
概要
This document describes how to use the Hypertext Transfer Protocol (HTTP) over Transport Layer Security (TLS) as a dereference protocol to resolve a reference to a Presence Information Data Format Location Object (PIDF-LO). This document assumes that a Location Recipient possesses a URI that can be used in conjunction with the HTTP-Enabled Location Delivery (HELD) protocol to request the location of the Target.
このドキュメントでは、プレゼンス情報データフォーマットロケーションオブジェクト（PIDF-LO）への参照を解決するための参照解除プロトコルとして、トランスポート層セキュリティ（TLS）上のハイパーテキスト転送プロトコル（HTTP）を使用する方法について説明します。このドキュメントでは、ロケーション受信者がURIを所有し、HTTP対応のロケーション配信（HELD）プロトコルと組み合わせて使用して、ターゲットのロケーションをリクエストできることを前提としています。
Status of This Memo
本文書の状態
This is an Internet Standards Track document.
これはInternet Standards Trackドキュメントです。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
このドキュメントは、IETF（Internet Engineering Task Force）の製品です。これは、IETFコミュニティのコンセンサスを表しています。公開レビューを受け、インターネットエンジニアリングステアリンググループ（IESG）による公開が承認されました。インターネット標準の詳細については、RFC 5741のセクション2をご覧ください。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc6753.
このドキュメントの現在のステータス、正誤表、およびフィードバックの提供方法に関する情報は、http：//www.rfc-editor.org/info/rfc6753で入手できます。
Copyright Notice
著作権表示
Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved.
Copyright（c）2012 IETF Trustおよびドキュメントの作成者として特定された人物。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
この文書は、BCP 78およびこの文書の発行日に有効なIETF文書に関するIETFトラストの法的規定（http://trustee.ietf.org/license-info）の対象となります。これらのドキュメントは、このドキュメントに関するあなたの権利と制限を説明しているため、注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、Trust Legal Provisionsのセクション4.eに記載されているSimplified BSD Licenseのテキストが含まれている必要があり、Simplified BSD Licenseに記載されているように保証なしで提供されます。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. HELD Dereference Protocol . . . . . . . . . . . . . . . . . . 4
3.1. HELD Usage Profile . . . . . . . . . . . . . . . . . . . . 4
3.2. HTTP GET Behavior . . . . . . . . . . . . . . . . . . . . 5
4. Authorization Models . . . . . . . . . . . . . . . . . . . . . 6
4.1. Authorization by Possession . . . . . . . . . . . . . . . 7
4.2. Authorization via Access Control . . . . . . . . . . . . . 8
4.3. Access Control with HELD Dereference . . . . . . . . . . . 9
5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . . 15
Appendix A. GEOPRIV Using Protocol Compliance . . . . . . . . . . 18
Appendix B. Compliance to Location Reference Requirements . . . . 21
B.1. Requirements for a Location Configuration Protocol . . . . 21
B.2. Requirements for a Location Dereference Protocol . . . . . 23
A location URI [RFC5808] identifies a resource that contains the location of an entity. This document specifies how a holder of an "http:" or "https:" location URI uses that URI to retrieve location information using a subset of HELD functionality or an HTTP GET request.
ロケーションURI [RFC5808]は、エンティティのロケーションを含むリソースを識別します。このドキュメントでは、「http：」または「https：」ロケーションURIの保有者がそのURIを使用して、HELD機能のサブセットまたはHTTP GETリクエストを使用してロケーション情報を取得する方法を指定します。
A location URI can be acquired using a location configuration protocol, such as HTTP-Enabled Location Delivery (HELD) [RFC5985] or the Dynamic Host Configuration Protocol (DHCP) location URI option [DHCP-URI-OPT].
ロケーションURIは、HTTP対応ロケーション配信（HELD）[RFC5985]や動的ホスト構成プロトコル（DHCP）ロケーションURIオプション[DHCP-URI-OPT]などのロケーション構成プロトコルを使用して取得できます。
A Location Recipient that dereferences a location URI acquires location information in the form of a Presence Information Data Format - Location Object (PIDF-LO) document [RFC4119]. HELD parameters allow for specifying the type of location information, though some constraints are placed on allowable parameters.
ロケーションURIを逆参照するロケーション受信者は、プレゼンス情報データ形式-ロケーションオブジェクト（PIDF-LO）ドキュメント[RFC4119]の形式でロケーション情報を取得します。 HELDパラメータを使用すると、位置情報のタイプを指定できますが、許可されるパラメータにはいくつかの制約があります。
Location URIs compatible with HELD dereferencing use the "https:" or "http:" scheme. HELD can be used by Location Recipients that are aware of the fact that the URI is a location URI. Mandatory support for an HTTP GET request ensures that the URI can be used even if it is not recognized as a location URI.
HELD逆参照と互換性のあるロケーションURIは、「https：」または「http：」スキームを使用します。 HELDは、URIがロケーションURIであることを認識しているロケーション受信者が使用できます。 HTTP GETリクエストの必須サポートにより、ロケーションURIとして認識されない場合でも、URIを確実に使用できます。
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 [RFC2119].
このドキュメントのキーワード「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「MAY」、および「OPTIONAL」は、 [RFC2119]で説明されているように解釈されます。
This document uses key terminology from several sources:
このドキュメントでは、いくつかのソースからの主要な用語を使用しています。
o The terms for the GEOPRIV reference model defined are in [RFC6280].
o 定義されたGEOPRIV参照モデルの用語は、[RFC6280]にあります。
o The term "Location Information Server (LIS)", from [RFC5687], is a node in the access network that provides location information to an endpoint. A LIS provides location URIs.
o [RFC5687]からの「位置情報サーバー（LIS）」という用語は、位置情報をエンドポイントに提供するアクセスネットワークのノードです。 LISはロケーションURIを提供します。
o The term "Location Server (LS)", from [RFC6280], is used to identify the role that responds to a location dereference request. A Location Server might be the same entity as the LIS, but the model in [RFC5808] allows for the existence of separate -- but related -- entities.
o [RFC6280]からの「ロケーションサーバー（LS）」という用語は、ロケーション逆参照要求に応答するロールを識別するために使用されます。ロケーションサーバーはLISと同じエンティティである場合がありますが、[RFC5808]のモデルでは、個別の（ただし関連する）エンティティの存在が可能です。
o The term "location URI" is coined in [RFC5808].
o 「ロケーションURI」という用語は、[RFC5808]で作成されました。
This section describes how HELD can be used to dereference a location URI. This process can be applied when a Location Recipient is in possession of a location URI with an "https:" or "http:" URI scheme.
このセクションでは、HELDを使用してロケーションURIを逆参照する方法について説明します。このプロセスは、ロケーション受信者が「https：」または「http：」URIスキームのロケーションURIを所有している場合に適用できます。
This document does not describe a specific authentication mechanism. This means that authorization policies are unable to specifically identify authorized Location Recipients.
このドキュメントでは、特定の認証メカニズムについては説明していません。つまり、承認ポリシーでは、承認された場所の受信者を明確に識別することができません。
A Location Recipient that wishes to dereference an "https:" or "http:" URI performs a HELD request on HTTP to the identified resource.
「https：」または「http：」URIの逆参照を希望するロケーション受信者は、識別されたリソースに対してHTTPでHELDリクエストを実行します。
Note: In many cases, an "http:" URI does not provide sufficient security for location URIs. The absence of the security mechanisms provided by TLS means that the Rule Maker has no control over who receives location information, and the Location Recipient has no assurance that the information is correct.
注：多くの場合、「http：」URIはロケーションURIに十分なセキュリティを提供しません。 TLSによって提供されるセキュリティメカニズムがないことは、ルールメーカーが場所情報を受信するユーザーを制御できず、場所の受信者が情報が正しいことを保証できないことを意味します。
The Location Recipient establishes a connection to the LS, as described in [RFC2818].
[RFC2818]で説明されているように、ロケーション受信者はLSへの接続を確立します。
The scheme of a location URI determines whether or not TLS is used on a given dereference transaction. Location Servers MUST be configured to issue only HTTPS URIs and respond to only to HTTPS dereference requests, unless confidentiality and integrity protection are provided by some other mechanism. For example, the server might only accept requests from clients within a trusted network or via an IPsec-protected channel. When TLS is used, the TLS ciphersuite TLS_NULL_WITH_NULL_NULL MUST NOT be used, and the LS MUST be authenticated [RFC6125] to ensure that the correct server is contacted.
ロケーションURIのスキームは、TLSが特定の逆参照トランザクションで使用されるかどうかを決定します。位置情報サーバーは、他のメカニズムによって機密性と整合性の保護が提供されない限り、HTTPS URIのみを発行し、HTTPS逆参照要求にのみ応答するように構成する必要があります。たとえば、サーバーは信頼されたネットワーク内のクライアントからの要求、またはIPsecで保護されたチャネルを介した要求のみを受け入れる場合があります。 TLSを使用する場合は、TLS暗号スイートTLS_NULL_WITH_NULL_NULLを使用してはならず（MUST NOT）、LSを認証して[RFC6125]、正しいサーバーに確実にアクセスできるようにする必要があります。
A Location Server MAY reject a request and ask that a Location Recipient provide authentication credentials if authorization is dependent on the Location Recipient identity. Future specifications could define an authentication mechanism and a means by which Location Recipients are identified in authorization policies. This document does not provide definitions for either item.
許可がロケーション受信者のアイデンティティに依存している場合、ロケーションサーバーはリクエストを拒否し、ロケーション受信者に認証資格情報を提供するように要求する場合があります。将来の仕様では、認証メカニズムと、認可ポリシーでロケーション受信者を識別する手段を定義する可能性があります。このドキュメントでは、どちらのアイテムの定義も提供していません。
Use of HELD as a location dereference protocol is largely the same as its use as a location configuration protocol. Aside from the restrictions noted in this document, HELD semantics do not differ from those established in [RFC5985].
ロケーション逆参照プロトコルとしてのHELDの使用は、ロケーション構成プロトコルとしての使用とほとんど同じです。このドキュメントに記載されている制限を除いて、HELDセマンティクスは[RFC5985]で確立されたものと変わりません。
The HELD "locationRequest" is the only request permitted by this specification. Similarly, request parameters other than the following MUST NOT be accepted by the LS: "responseTime" and "locationType" (including the associated "exact" attribute).
HELD "locationRequest"は、この仕様で許可されている唯一の要求です。同様に、「responseTime」と「locationType」（関連する「正確な」属性を含む）以外のリクエストパラメータは、LSによって受け入れられてはなりません（MUST NOT）。
Parameters and requests that do not have known behavior for dereference requests MUST NOT be used. The LS MUST ignore any parameters that it does not understand unless it knows the parameters to be invalid. If parameters are understood by the LS and known to be invalid, the LS MAY generate a HELD error response. For instance, those defined in [RFC6155] are always invalid and can be rejected.
逆参照要求の動作がわかっていないパラメーターと要求は使用してはなりません（MUST NOT）。 LSは、パラメーターが無効であることがわかっていない限り、理解できないパラメーターを無視する必要があります。パラメータがLSによって理解され、無効であることがわかっている場合、LSはHELDエラー応答を生成する場合があります。たとえば、[RFC6155]で定義されているものは常に無効であり、拒否することができます。
The LS MUST NOT generate location URIs or provide a "locationUriSet" in response to a dereference request. If the location request contains a "locationType" element that includes "locationURI", this parameter is either ignored or rejected as appropriate, based on the associated "exact" attribute.
LSは、逆参照要求に応答してロケーションURIを生成したり、「locationUriSet」を提供してはなりません（MUST NOT）。ロケーション要求に「locationURI」を含む「locationType」要素が含まれている場合、このパラメーターは、関連する「正確な」属性に基づいて、必要に応じて無視または拒否されます。
GET is the method assumed by generic HTTP user agents; therefore, unless context identifies an "https:" URI as a HELD URI, such a user agent might simply send an HTTP GET. Rather than providing an HTTP 405 (Method Not Allowed) response indicating that POST is the only permitted method, a LIS MUST provide a HELD location response if it receives an HTTP GET request.
GETは、一般的なHTTPユーザーエージェントが想定する方法です。したがって、コンテキストが「https：」URIをHELD URIとして識別しない限り、そのようなユーザーエージェントは単にHTTP GETを送信する可能性があります。 POSTが唯一の許可されたメソッドであることを示すHTTP 405（Method Not Allowed）応答を提供するのではなく、LISは、HTTP GET要求を受信した場合、HELDロケーション応答を提供する必要があります。
An HTTP GET request to a HELD URI produces a HELD response as if the following HELD request had been sent using HTTP POST:
HELD URIへのHTTP GETリクエストは、次のHELDリクエストがHTTP POSTを使用して送信されたかのようにHELDレスポンスを生成します。
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held">
<locationType exact="false">
geodetic civic
</locationType>
</locationRequest>
Figure 1: GET Request Equivalent Location Request
図1：GETリクエストと同等のロケーションリクエスト
HTTP GET requests MUST be safe and idempotent [RFC2616] -- that is, there are no side effects of making the request, and a repeated request has no more effect than a single request. Repeating a HELD request might result in a different location, but only as a result of a change in the state of the resource: the location of the Target.
HTTP GETリクエストは安全でべき等である必要があります[RFC2616]-つまり、リクエストを行うことによる副作用はなく、繰り返されたリクエストは単一のリクエストよりも効果がありません。 HELDリクエストを繰り返すと、別の場所になる可能性がありますが、それはリソースの状態、つまりターゲットの場所が変更された結果のみです。
Only the creation of a location URI as a result of receiving a request causes a HELD request to have side effects. A request to a location URI can be both safe and idempotent, since a location URI cannot be produced in response to a request to a location URI. A Location Recipient MAY infer from a response containing the HELD content type "application/held+xml" that a URI references a resource that supports HELD.
リクエストを受け取った結果としてロケーションURIが作成されるだけで、HELDリクエストに副作用が生じます。ロケーションURIへのリクエストに応答してロケーションURIを生成することはできないため、ロケーションURIへのリクエストは安全かつべき等の両方になる可能性があります。 Location Recipientは、HELDをサポートするリソースを参照するURIがHELDコンテンツタイプ「application / held + xml」を含む応答から推測する場合があります。
Content negotiation MAY be supported to produce a presence document in place of a HELD location response. Where the presence document would otherwise be included in a "locationResponse" document, it can be included in the body of the HTTP response directly by including an "Accept" header that includes "application/pidf+xml".
HELDロケーション応答の代わりにプレゼンスドキュメントを生成するために、コンテンツネゴシエーションがサポートされる場合があります。プレゼンスドキュメントが「locationResponse」ドキュメントに含まれる場合は、「application / pidf + xml」を含む「Accept」ヘッダーを含めることで、HTTP応答の本文に直接含めることができます。
This section discusses two extreme types of authorization models for dereferencing with HELD URIs, namely "Authorization by Possession" and "Authorization by Access Control". In the subsequent subsections, we discuss the properties of these two models. Figure 2, from [RFC5808], shows the model applicable to location configuration, conveyance, and dereference.
このセクションでは、HELD URIで逆参照するための2つの極端なタイプの承認モデル、つまり「所有による承認」と「アクセス制御による承認」について説明します。以降のサブセクションでは、これら2つのモデルのプロパティについて説明します。 [RFC5808]の図2は、ロケーション構成、伝達、逆参照に適用可能なモデルを示しています。
+---------+--------+ Location +-----------+
| | | Dereference | Location |
| LIS - LS +---------------+ Recipient |
| | | Protocol | |
+----+----+--------+ (3) +-----+-----+
| `. |
| Policy `. |
Location | Exchange `. |
Configuration | (*) | |
Protocol | +----+----+ |
(1) | | Rule | Location |
| | Maker | Conveyance |
+-----+----+ +---------+ Protocol |
| | (2) |
| Target +------------------------------+
| |
+----------+
Figure 2: Communication Model
図2：通信モデル
It is important to note that this document does not mandate a specific authorization model. It is possible to combine aspects of both models. However, no authentication framework is provided, which limits the policy options available when the "Authorization by Access Control" model is used.
このドキュメントは特定の承認モデルを義務付けていないことに注意することが重要です。両方のモデルの側面を組み合わせることが可能です。ただし、認証フレームワークは提供されておらず、「アクセス制御による承認」モデルが使用されている場合に使用可能なポリシーオプションが制限されています。
For either authorization model, the overall process is similar. The following steps are followed, with minor alterations:
どちらの承認モデルでも、全体的なプロセスは似ています。次の手順に従いますが、少し変更します。
1. The Target acquires a location URI from the LIS. This uses a location configuration protocol (LCP), such as HELD or DHCP.
1. ターゲットはLISからロケーションURIを取得します。これは、HELDやDHCPなどのロケーション構成プロトコル（LCP）を使用します。
2. The Target then conveys the location URI to a third party, the Location Recipient (for example, using SIP as described in [RFC6442]). This step is shown in (2) of Figure 2.
2. 次に、ターゲットはロケーションURIをサードパーティのロケーション受信者に伝えます（たとえば、[RFC6442]で説明されているようにSIPを使用します）。この手順を図2の（2）に示します。
3. The Location Recipient then needs to dereference the location URI in order to obtain the Location Object (3). An "https:" or "http:" URI is dereferenced as described in this document; other URI schemes might be dereferenced using another method.
3. 次に、ロケーション受信者は、ロケーションオブジェクトを取得するためにロケーションURIを逆参照する必要があります（3）。このドキュメントで説明されているように、「https：」または「http：」URIは逆参照されます。他のURIスキームは、別の方法を使用して逆参照される場合があります。
In this final step, the Location Server (LS) or LIS makes an authorization decision. How this decision is reached depends on the authorization model.
この最後のステップでは、ロケーションサーバー（LS）またはLISが承認を決定します。この決定がどのように行われるかは、承認モデルによって異なります。
In this model, possession -- or knowledge -- of the location URI is used to control access to location information. A location URI might be constructed such that it is hard to guess (see C8 of [RFC5808]), and the set of entities that it is disclosed to can be limited. The only authentication this would require by the LS is evidence of possession of the URI. The LS could immediately authorize any request that indicates this URI.
このモデルでは、ロケーションURIの所有（または知識）を使用して、ロケーション情報へのアクセスを制御します。ロケーションURIは、推測が困難になるように構築される場合があり（[RFC5808]のC8を参照）、それが開示されるエンティティのセットは制限される場合があります。これがLSで必要とする唯一の認証は、URIの所有の証拠です。 LSは、このURIを示すリクエストをすぐに承認できます。
Authorization by possession does not require direct interaction with a Rule Maker; it is assumed that the Rule Maker is able to exert control over the distribution of the location URI. Therefore, the LIS can operate with limited policy input from a Rule Maker.
所有による承認には、ルールメーカーとの直接のやり取りは必要ありません。ルールメーカーは、ロケーションURIの配布を制御できると想定されています。したがって、LISはルールメーカーからの限られたポリシー入力で動作できます。
Limited disclosure is an important aspect of this authorization model. The location URI is a secret; therefore, ensuring that adversaries are not able to acquire this information is paramount. Encryption, such as might be offered by TLS [RFC5246] or S/MIME [RFC5751], protects the information from eavesdroppers.
制限付きの開示は、この承認モデルの重要な側面です。ロケーションURIは秘密です。したがって、攻撃者がこの情報を取得できないようにすることが最も重要です。 TLS [RFC5246]やS / MIME [RFC5751]によって提供されるような暗号化は、盗聴者から情報を保護します。
Use of authorization by possession location URIs in a hop-by-hop protocol such as SIP [RFC3261] adds the possibility of on-path adversaries. Depending on the usage of the location URI for certain location-based applications (e.g., emergency services and location-based routing), specific treatment is important, as discussed in [RFC6442].
SIP [RFC3261]などのホップバイホッププロトコルで所有ロケーションURIによる認証を使用すると、パス上の敵の可能性が追加されます。 [RFC6442]で説明されているように、特定の場所ベースのアプリケーション（緊急サービスや場所ベースのルーティングなど）の場所URIの使用方法によっては、特定の扱いが重要です。
Using possession as a basis for authorization means that, once granted, authorization cannot be easily revoked. Cancellation of a location URI ensures that legitimate users are also affected; application of additional policy is theoretically possible but could be technically infeasible. Expiration of location URIs limits the usable time for a location URI, requiring that an attacker continue to learn new location URIs to retain access to current location information.
所有権を承認の基礎として使用するということは、いったん付与されると、承認を簡単に取り消すことができないことを意味します。ロケーションURIをキャンセルすると、正当なユーザーにも影響が及ぶことが保証されます。追加のポリシーの適用は理論的には可能ですが、技術的に不可能である可能性があります。ロケーションURIの有効期限は、ロケーションURIの使用可能時間を制限し、攻撃者が現在のロケーション情報へのアクセスを保持するために新しいロケーションURIを学習し続けることを要求します。
A very simple policy might be established at the time that a location URI is created. This policy specifies that the location URI expires after a certain time, which limits any inadvertent exposure of location information to adversaries. The expiration time of the location URI might be negotiated at the time of its creation, or it might be unilaterally set by the LIS.
ロケーションURIが作成されるときに、非常に単純なポリシーが確立される場合があります。このポリシーは、ロケーションURIが特定の時間の後に期限切れになることを指定します。これにより、ロケーション情報が不注意で敵に公開されることが制限されます。ロケーションURIの有効期限は、その作成時にネゴシエートされるか、LISによって一方的に設定される場合があります。
Use of explicit access control provides a Rule Maker greater control over the behavior of an LS. In contrast to authorization by possession, possession of this form of location URI does not imply authorization. Since an explicit policy is used to authorize access to location information, the location URI can be distributed to many potential Location Recipients.
明示的なアクセス制御を使用すると、LSの動作をより細かく制御できます。所有による承認とは対照的に、この形式のロケーションURIの所有は承認を意味しません。明示的なポリシーを使用して位置情報へのアクセスを承認するため、位置URIは多くの潜在的な位置受信者に配布できます。
Either before creation or dissemination of the location URI, the Rule Maker establishes an authorization policy with the LS. In reference to Figure 2, authorization policies might be established at creation (Step 1) and need to be established before the location URI is published (Step 2) to ensure that the policy grants access to the desired Location Recipients. Depending on the mechanism used, it might also be possible to change authorization policies at any time.
ロケーションURIの作成または配布の前に、ルールメーカーはLSで承認ポリシーを確立します。図2を参照すると、許可ポリシーは作成時に確立され（ステップ1）、ロケーションURIが公開される前に確立され（ステップ2）、ポリシーが目的のロケーション受信者へのアクセスを確実に許可するようにする必要があります。使用するメカニズムによっては、いつでも許可ポリシーを変更できる場合があります。
A possible format for these authorization policies is available with GEOPRIV Common Policy [RFC4745] and Geolocation Policy [GEOPRIV-POLICY]. Additional constraints might be established by other means.
これらの許可ポリシーの可能な形式は、GEOPRIV共通ポリシー[RFC4745]および地理位置情報ポリシー[GEOPRIV-POLICY]で利用できます。追加の制約が他の手段によって確立される場合があります。
The LS enforces the authorization policy when a Location Recipient dereferences the URI. Explicit authorization policies allow a Rule Maker to specify how location information is provided to Location Recipients.
LSは、ロケーション受信者がURIを逆参照するときに承認ポリシーを適用します。明示的な承認ポリシーにより、ルールメーカーはロケーション情報をロケーション受信者に提供する方法を指定できます。
This document does not describe a specific authentication mechanism; therefore, the authorization by access control model is not an option. Instead, this document assumes the authorization by possession model.
このドキュメントでは、特定の認証メカニズムについては説明していません。したがって、アクセス制御モデルによる許可はオプションではありません。代わりに、このドキュメントは所有モデルによる承認を前提としています。
Other policy mechanisms, such as those described in [GEOPRIV-POLICY], can be applied for different Location Recipients if each recipient is given a different location URI. Each location URI can be assigned a different authorization policy. Selective disclosure used in this fashion can be used in place of identity-based authorization.
[GEOPRIV-POLICY]で説明されているような他のポリシーメカニズムは、各受信者に異なるロケーションURIが与えられている場合、異なるロケーション受信者に適用できます。各ロケーションURIには、異なる許可ポリシーを割り当てることができます。この方法で使用される選択的開示は、IDベースの承認の代わりに使用できます。
How policy is associated with a location URI is not defined by this document. [GEOPRIV-POLICY-URI] describes one possible mechanism.
ポリシーがロケーションURIに関連付けられる方法は、このドキュメントでは定義されていません。 [GEOPRIV-POLICY-URI]は、考えられるメカニズムの1つを説明しています。
Use of an identity-based authorization policy is not precluded. A Location Server MAY support an authentication mechanism that enables identity-based authorization policies to be used. Future specifications might define means of identifying recipients.
IDベースの許可ポリシーの使用は除外されません。ロケーションサーバーは、IDベースの承認ポリシーの使用を可能にする認証メカニズムをサポートする場合があります。将来の仕様では、受信者を識別する方法を定義する可能性があります。
Note: Policy frameworks like [RFC4745] degrade in a way that protects privacy if features are not supported. If a policy specifies a rule that is conditional on the identity of a recipient and the protocol does not (or cannot) provide an assertion identity of the recipient, the rule has no effect, and the policy defaults to providing less information.
注：[RFC4745]のようなポリシーフレームワークは、機能がサポートされていない場合にプライバシーを保護する方法で低下します。ポリシーが受信者のIDを条件とするルールを指定し、プロトコルが受信者のアサーションIDを提供しない（または提供できない）場合、ルールは効果がなく、ポリシーはデフォルトで提供する情報が少なくなります。
An example scenario envisioned by this document is shown in Figure 3.
This diagram shows how a location dereference protocol fits with
location configuration and conveyance. [RFC5808] contains more
information on this scenario and others like it.
+-------------+
+------------+ | Location | +-----------+
| End Device | | Information | | Location |
| (Target) | | Server | | Recipient |
+-----+------+ +------+------+ +-----+-----+
| | |
.- + - - - - - - - - - - - - + -. |
: | locationRequest | : |
. |----(for location URI)-->| . |
: | | : Location |
. | locationResponse | . Configuration |
: |<-----(location URI)-----| : |
. | | . |
`- + - - - - - - - - - - - - + -' |
| | |
| Location Conveyance |
|~ ~ ~ ~ ~ ~ ~ ~ ~ ~(location URI)~ ~ ~ ~ ~ ~ ~ ~ ~>|
| | |
| .- + - - - - - - - - - - - - + -.
| : | locationRequest | :
| . |<------(for civic)-------| .
| Dereferencing : | | :
| . | locationResponse | .
| : |--------(PIDF-LO)------->| :
| . | | .
| `- + - - - - - - - - - - - - + -'
| | |
Figure 3: Example of Dereference Protocol Exchange
図3：間接参照プロトコル交換の例
The example in Figure 4 shows the simplest form of dereferencing request using HELD to the location URI "https://ls.example.com:49152/uri/w3g61nf5n66p0". The only way that this differs from the example in Section 10.1 of [RFC5985] is in the request URI and the source of the URI.
図4の例は、ロケーションURI "https://ls.example.com:49152/uri/w3g61nf5n66p0"へのHELDを使用した最も単純な形式の逆参照リクエストを示しています。これが[RFC5985]のセクション10.1の例と異なる唯一の方法は、リクエストURIとURIのソースにあります。
POST /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Content-Type: application/held+xml
Content-Length: 87
<?xml version="1.0"?>
<locationRequest xmlns="urn:ietf:params:xml:ns:geopriv:held"/>
Figure 4: Minimal Dereferencing Request
図4：最小限の逆参照要求
Figure 5 shows the response to the previous request listing both civic and geodetic location information of the Target's location. Again, this is identical to the response in Section 10.1 of [RFC5985] -- unless policy specifies otherwise, the Location Recipient receives the same information as the Device.
図5は、ターゲットの場所の都市および測地の両方の位置情報をリストした、前の要求に対する応答を示しています。繰り返しますが、これは[RFC5985]のセクション10.1の応答と同じです。ポリシーで特に指定されていない限り、ロケーション受信者はデバイスと同じ情報を受け取ります。
HTTP/1.1 200 OK
Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private
Content-Type: application/held+xml
Content-Length: 676
<?xml version="1.0"?>
<locationResponse xmlns="urn:ietf:params:xml:ns:geopriv:held">
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
<tuple id="b650sf789nd">
<status>
<geopriv xmlns="urn:ietf:params:xml:ns:pidf:geopriv10"
xmlns:gbp="urn:ietf:params:xml:ns:pidf:geopriv10:basic-policy">
<location-info>
<Point xmlns="http://www.opengis.net/gml"
srsName="urn:ogc:def:crs:EPSG::4326">
<pos>-34.407 150.88001</pos>
</Point>
</location-info>
<usage-rules>
<gbp:retransmission-allowed>
false</gbp:retransmission-allowed>
<gbp:retention-expiry>
2011-01-11T03:42:29+00:00</gbp:retention-expiry>
</usage-rules>
<method>Wiremap</method>
</geopriv>
</status>
<timestamp>2006-01-10T03:42:28+00:00</timestamp>
</tuple>
</presence>
</locationResponse>
Figure 5: Response with Location Information
図5：位置情報を含む応答
The following GET request is treated in an equivalent fashion. The LS treats this request as though it were a location request of the form shown in Figure 1. The same response might be provided.
次のGET要求は同等の方法で処理されます。 LSは、この要求を、図1に示す形式のロケーション要求であるかのように扱います。同じ応答が提供される場合があります。
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/held+xml
Figure 6: GET Request
図6：GETリクエスト
The following GET request uses content negotiation to indicate a preference for a presence document.
次のGETリクエストは、コンテンツネゴシエーションを使用して、プレゼンスドキュメントの設定を示しています。
GET /uri/w3g61nf5n66p0 HTTP/1.1
Host: ls.example.com:49152
Accept: application/pidf+xml,application/held+xml;q=0.5
Figure 7: GET Request with Content Negotiation
図7：コンテンツネゴシエーションを伴うGETリクエスト
The response only differs from a normal HELD location response to a POST request in that the "locationResponse" element is omitted and the "Content-Type" header reflects the changed content.
応答は、「locationResponse」要素が省略され、「Content-Type」ヘッダーが変更されたコンテンツを反映するという点で、POST要求に対する通常のHELDロケーション応答とは異なります。
HTTP/1.1 200 OK
Server: Example LIS
Date: Mon, 10 Jan 2011 03:42:29 GMT
Expires: Tue, 11 Jan 2011 03:42:29 GMT
Cache-control: private
Content-Type: application/pidf+xml
Content-Length: 591
<?xml version="1.0"?>
<presence xmlns="urn:ietf:params:xml:ns:pidf"
entity="pres:3650n87934c@ls.example.com">
<!-- PIDF contents are identical to the previous example -->
</presence>
Figure 8: GET Response with PIDF-LO
図8：PIDF-LOを使用したGET応答
Privacy of location information is the most important security consideration for this document. Two measures in particular are used to protect privacy: TLS and authorization policies. TLS provides a means of ensuring confidentiality of location information through encryption and mutual authentication. An authorization policy allows a Rule Maker to explicitly control how location information is provided to Location Recipients.
ロケーション情報のプライバシーは、このドキュメントの最も重要なセキュリティ上の考慮事項です。特に、プライバシーを保護するために、TLSと承認ポリシーという2つの手段が使用されます。 TLSは、暗号化と相互認証を通じて位置情報の機密性を確保する手段を提供します。承認ポリシーにより、ルールメーカーは、ロケーション情報がロケーション受信者に提供される方法を明示的に制御できます。
The process by which a Rule Maker establishes an authorization policy is not covered by this document; several methods are possible, for instance, [GEOPRIV-POLICY-URI] and [RFC4825].
ルールメーカーが承認ポリシーを確立するプロセスは、このドキュメントでは扱いません。 [GEOPRIV-POLICY-URI]や[RFC4825]など、いくつかの方法が可能です。
TLS MUST be used for dereferencing location URIs unless confidentiality and integrity are provided by some other mechanism, as discussed in Section 3. Location Recipients MUST authenticate the host identity using the domain name included in the location URI, using the procedure described in Section 3.1 of [RFC2818]. Local policy determines what a Location Recipient does if authentication fails or cannot be attempted.
セクション3で説明されているように、他のメカニズムによって機密性と整合性が提供されていない限り、ロケーションURIの逆参照にTLSを使用する必要があります。ロケーション受信者は、ロケーションURIに含まれるドメイン名を使用してホストIDを認証する必要があります。 [RFC2818]。ローカルポリシーは、認証が失敗した場合や試行できない場合にロケーション受信者が何をするかを決定します。
The authorization by possession model (Section 4.1) further relies on TLS when transmitting the location URI to protect the secrecy of the URI. Possession of such a URI implies the same privacy considerations as possession of the PIDF-LO document that the URI references.
所有モデルによる承認（セクション4.1）は、URIの機密性を保護するためにロケーションURIを送信するときに、TLSにさらに依存します。そのようなURIの所有は、URIが参照するPIDF-LOドキュメントの所有と同じプライバシーの考慮事項を意味します。
Location URIs MUST only be disclosed to authorized Location Recipients. The GEOPRIV architecture [RFC6280] designates the Rule Maker to authorize disclosure of the URI.
ロケーションURIは、許可されたロケーション受信者にのみ開示する必要があります。 GEOPRIVアーキテクチャ[RFC6280]は、URIの開示を承認するようにルールメーカーを指定します。
Protection of the location URI is necessary, since the policy attached to such a location URI permits anyone who has the URI to view the associated location information. This aspect of security is covered in more detail in the specification of location conveyance protocols, such as [RFC6442].
ロケーションURIに添付されたポリシーは、URIを持っているすべてのユーザーが関連するロケーション情報を表示できるため、ロケーションURIの保護が必要です。セキュリティのこの側面については、[RFC6442]などのロケーション伝達プロトコルの仕様で詳しく説明しています。
According to the requirements in [RFC5808] the LS MUST NOT provide any information about the Target except its location, unless policy from a Rule Maker allows otherwise. Thus, the Location Server MUST only provide an unlinked pseudonym in the "entity" attribute of the PIDF-LO document unless the Rule Maker policy allows for identity disclosure.
[RFC5808]の要件によれば、LSは、ルールメーカーからのポリシーが別の方法で許可しない限り、ターゲットの場所を除いて、ターゲットに関する情報を提供してはなりません。したがって、ロケーションサーバーは、ルールメーカーのポリシーでIDの開示が許可されていない限り、PIDF-LOドキュメントの「エンティティ」属性にリンクされていない仮名のみを提供する必要があります。
Further security considerations and requirements relating to the use of location URIs are described in [RFC5808].
ロケーションURIの使用に関するセキュリティの考慮事項と要件については、[RFC5808]で説明されています。
Thanks to Barbara Stark and Guy Caron for providing early comments. Thanks to Rohan Mahy for constructive comments on the scope and format of the document. Thanks to Ted Hardie for his strawman proposal that provided assistance with the security section of this document. Richard Barnes made helpful observations on the application of authorization policy. Bernard Aboba and Julian Reschke contributed constructive reviews.
初期のコメントを提供してくれたBarbara StarkとGuy Caronに感謝します。ドキュメントの範囲と形式に関する建設的なコメントを提供してくれたRohan Mahyに感謝します。このドキュメントのセキュリティセクションで支援を提供したわらの提案をしてくれたTed Hardieに感謝します。 Richard Barnesは、認可ポリシーの適用に関して有益な観察を行いました。 Bernard AbobaとJulian Reschkeが建設的なレビューを投稿しました。
The participants of the GEOPRIV interim meeting 2008 provided significant feedback on this document.
2008年GEOPRIV中間会議の参加者は、このドキュメントに関する重要なフィードバックを提供しました。
James Polk provided input on security in June 2008.
James Polkは、2008年6月にセキュリティに関する意見を提供しました。
Martin Dawson was an original author of this document. Sadly, he passed away prior to its publication.
マーティン・ドーソンはこの文書の原作者です。悲しいことに、彼はその出版前に亡くなりました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するキーワード」、BCP 14、RFC 2119、1997年3月。
[RFC2616] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.
[RFC2616] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、「ハイパーテキスト転送プロトコル-HTTP / 1.1」 、RFC 2616、1999年6月。
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC2818] Rescorla、E。、「HTTP over TLS」、RFC 2818、2000年5月。
[RFC4119] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[RFC4119] Peterson、J。、「A Presence-based GEOPRIV Location Object Format」、RFC 4119、2005年12月。
[RFC5491] Winterbottom, J., Thomson, M., and H. Tschofenig, "GEOPRIV Presence Information Data Format Location Object (PIDF-LO) Usage Clarification, Considerations, and Recommendations", RFC 5491, March 2009.
[RFC5491] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「GEOPRIV Presence Information Data Format Location Object（PIDF-LO）Usage Clarification、Considerations、and Recommendations」、RFC 5491、2009年3月。
[RFC5985] Barnes, M., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[RFC5985] Barnes、M。、「HTTP-Enabled Location Delivery（HELD）」、RFC 5985、2010年9月。
[RFC6125] Saint-Andre, P. and J. Hodges, "Representation and Verification of Domain-Based Application Service Identity within Internet Public Key Infrastructure Using X.509 (PKIX) Certificates in the Context of Transport Layer Security (TLS)", RFC 6125, March 2011.
[RFC6125] Saint-Andre、P。およびJ. Hodges、「トランスポート層セキュリティ（TLS）のコンテキストでX.509（PKIX）証明書を使用したインターネット公開鍵インフラストラクチャ内のドメインベースのアプリケーションサービスIDの表現と検証」、 RFC 6125、2011年3月。
[DHCP-URI-OPT] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", Work in Progress, May 2012.
[DHCP-URI-OPT] Polk、J。、「ロケーションURI（Uniform Resource Identifier）の動的ホスト構成プロトコル（DHCP）IPv4およびIPv6オプション」、作業中、2012年5月。
[GEOPRIV-POLICY] Schulzrinne, H., Tschofenig, H., Cuellar, J., Polk, J., Morris, J., and M. Thomson, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Work in Progress, August 2012.
[GEOPRIV-POLICY] Schulzrinne、H.、Tschofenig、H.、Cuellar、J.、Polk、J.、Morris、J。、およびM. Thomson、「地理位置情報ポリシー：位置情報のプライバシー設定を表現するためのドキュメント形式」 、Work in Progress、2012年8月。
[GEOPRIV-POLICY-URI] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, "Location Configuration Extensions for Policy Management", Work in Progress, November 2011.
[GEOPRIV-POLICY-URI] Barnes、R.、Thomson、M.、Winterbottom、J。、およびH. Tschofenig、「ポリシー管理のためのロケーション構成拡張」、Work in Progress、2011年11月。
[RFC3261] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[RFC3261] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：Session Initiation Protocol」 、RFC 3261、2002年6月。
[RFC3693] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[RFC3693] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「Geopriv要件」、RFC 3693、2004年2月。
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., Polk, J., and J. Rosenberg, "Common Policy: A Document Format for Expressing Privacy Preferences", RFC 4745, February 2007.
[RFC4745] Schulzrinne、H.、Tschofenig、H.、Morris、J.、Cuellar、J.、Polk、J.、J。Rosenberg、「Common Policy：A Document Format for Expressing Privacy Preferences」、RFC 4745、2月2007年
[RFC4825] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[RFC4825] Rosenberg、J。、「Extensible Markup Language（XML）Configuration Access Protocol（XCAP）」、RFC 4825、2007年5月。
[RFC5246] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[RFC5246] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocol Version 1.2」、RFC 5246、2008年8月。
[RFC5687] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010.
[RFC5687] Tschofenig、H。およびH. Schulzrinne、「GEOPRIV Layer 7 Location Configuration Protocol：Problem Statement and Requirements」、RFC 5687、2010年3月。
[RFC5751] Ramsdell, B. and S. Turner, "Secure/Multipurpose Internet Mail Extensions (S/MIME) Version 3.2 Message Specification", RFC 5751, January 2010.
[RFC5751] Ramsdell、B。およびS. Turner、「Secure / Multipurpose Internet Mail Extensions（S / MIME）Version 3.2 Message Specification」、RFC 5751、2010年1月。
[RFC5808] Marshall, R., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010.
[RFC5808] Marshall、R。、「Location-by-Referenceメカニズムの要件」、RFC 5808、2010年5月。
[RFC6155] Winterbottom, J., Thomson, M., Tschofenig, H., and R. Barnes, "Use of Device Identity in HTTP-Enabled Location Delivery (HELD)", RFC 6155, March 2011.
[RFC6155] Winterbottom、J.、Thomson、M.、Tschofenig、H。、およびR. Barnes、「Use-Device Identity in HTTP-Enabled Location Delivery（HELD）」、RFC 6155、2011年3月。
[RFC6280] Barnes, R., Lepinski, M., Cooper, A., Morris, J., Tschofenig, H., and H. Schulzrinne, "An Architecture for Location and Location Privacy in Internet Applications", BCP 160, RFC 6280, July 2011.
[RFC6280] Barnes、R.、Lepinski、M.、Cooper、A.、Morris、J.、Tschofenig、H。、およびH. Schulzrinne、「An Internet Location in Location and Location Privacy in Internet Applications」、BCP 160、RFC 6280、2011年7月。
[RFC6442] Polk, J., Rosen, B., and J. Peterson, "Location Conveyance for the Session Initiation Protocol", RFC 6442, December 2011.
[RFC6442] Polk、J.、Rosen、B。、およびJ. Peterson、「Session Initiation Protocolのロケーション伝達」、RFC 6442、2011年12月。
This section describes how use of HELD as a location dereference protocol complies with the GEOPRIV requirements described in [RFC3693].
このセクションでは、ロケーション逆参照プロトコルとしてのHELDの使用が、[RFC3693]で説明されているGEOPRIV要件にどのように準拠するかについて説明します。
Req. 1. (Location Object generalities):
必須1.（ロケーションオブジェクトの一般性）：
This requirement relates to the PIDF-LO [RFC4119] document, which is used by HELD. These requirements are addressed by [RFC4119] and [RFC5491].
この要件は、HELDで使用されるPIDF-LO [RFC4119]ドキュメントに関連しています。これらの要件は、[RFC4119]と[RFC5491]で対処されています。
Req. 2. (Location Object fields):
必須2.（場所オブジェクトフィールド）：
This requirement relates to the PIDF-LO [RFC4119] document, which is used by HELD. These requirements are addressed by [RFC4119] and [RFC5491].
この要件は、HELDで使用されるPIDF-LO [RFC4119]ドキュメントに関連しています。これらの要件は、[RFC4119]と[RFC5491]で対処されています。
Req. 3. (Location Data Types):
必須3.（位置データタイプ）：
This requirement relates to the PIDF-LO [RFC4119] document, which is used by HELD. These requirements are addressed by [RFC4119] and [RFC5491].
この要件は、HELDで使用されるPIDF-LO [RFC4119]ドキュメントに関連しています。これらの要件は、[RFC4119]と[RFC5491]で対処されています。
Section 7.2 of [RFC3693] details the requirements of a "Using Protocol". These requirements are restated, followed by a statement of compliance:
[RFC3693]のセクション7.2は、「プロトコルの使用」の要件について詳しく説明しています。これらの要件は改めて説明され、その後に準拠の声明が続きます。
Req. 4. "The using protocol has to obey the privacy and security instructions coded in the Location Object and in the corresponding Rules regarding the transmission and storage of the LO".
必須4.「使用プロトコルは、LOの送信と保存に関して、ロケーションオブジェクトと対応するルールにコーディングされているプライバシーとセキュリティの指示に従う必要があります。」
Compliant: This specification describes the use of HTTP over TLS for carrying the PIDF-LO from the LS to the Location Recipient. The sending and receiving parties are expected to comply with the instructions carried inside the object.
準拠：この仕様は、LSからロケーション受信者にPIDF-LOを伝送するためのHTTP over TLSの使用について説明しています。送信側と受信側は、オブジェクト内に含まれる指示に従うことが求められます。
Though discouraged, using unsecured "http:" URIs is permitted. Using unsecured HTTP is likely to result in non-compliance with this requirement.
推奨されていませんが、保護されていない「http：」URIの使用は許可されています。安全でないHTTPを使用すると、この要件に準拠しなくなる可能性があります。
Req. 5. "The using protocol will typically facilitate that the keys associated with the credentials are transported to the respective parties, that is, key establishment is the responsibility of the using protocol".
必須5.「使用プロトコルは通常、資格に関連付けられたキーがそれぞれの関係者に転送されることを容易にします。つまり、キーの確立は使用プロトコルの責任です」。
Compliant: This document specifies that authentication of the LS uses the established public key infrastructure used by HTTP over TLS [RFC2818]. Authentication of Location Recipients is based on distribution of a secret (the location URI) using a conveyance protocol (for instance, [RFC6442]), allowances are made for later work to define alternative methods.
準拠：このドキュメントは、LSの認証がHTTP over TLS [RFC2818]によって使用される確立された公開鍵インフラストラクチャを使用することを指定しています。ロケーション受信者の認証は、伝達プロトコル（[RFC6442]など）を使用したシークレット（ロケーションURI）の配布に基づいており、後の作業で代替メソッドを定義できるように許可されています。
Req. 6. "(Single Message Transfer) In particular, for tracking of small target devices, the design should allow a single message/packet transmission of location as a complete transaction".
必須6.「（単一メッセージ転送）特に、小さなターゲットデバイスの追跡の場合、設計は、単一メッセージ/パケットのロケーションの完全なトランザクションとしての送信を許可する必要があります。」
Not Compliant: The XML encoding specified in [RFC4119] is not suited to single packet transfers. Use of compressed content encoding [RFC2616] might allow this condition to be met.
非準拠：[RFC4119]で指定されているXMLエンコーディングは、単一パケット転送には適していません。圧縮コンテンツエンコーディング[RFC2616]を使用すると、この条件が満たされる可能性があります。
Section 7.3 of [RFC3693] details the requirements of a "Rule based Location Data Transfer". These requirements are restated where they are applicable to this document:
[RFC3693]のセクション7.3は、「ルールベースの位置情報データ転送」の要件を詳述しています。これらの要件は、このドキュメントに該当する場合に修正されます。
Req. 7. "(LS Rules) The decision of a Location Server to provide a Location Recipient access to Location Information MUST be based on Rule Maker-defined Privacy Rules".
必須7.「（LSルール）ロケーションサーバーがロケーション情報へのロケーション受信者アクセスを提供する決定は、ルールメーカーが定義したプライバシールールに基づく必要があります。
Compliant: This document describes two alternative methods by which a Rule Maker is able to control access to location information. Rule Maker policy is enforced by the LS when a location URI is dereferenced. However, this document does not describe how a location URI is created or how a Rule Maker associates policy with a location URI. These are covered by other specifications.
準拠：このドキュメントでは、ルールメーカーが位置情報へのアクセスを制御できる2つの代替方法について説明します。 Rule Makerポリシーは、ロケーションURIが逆参照されるときにLSによって実施されます。ただし、このドキュメントでは、ロケーションURIの作成方法や、ルールメーカーがポリシーをロケーションURIに関連付ける方法については説明していません。これらは他の仕様でカバーされています。
Req. 8. (LG Rules) Not Applicable: This relationship between LS and the source of its information (be that Location Generator (LG) or LIS) is out of the scope of this document.
必須8.（LGルール）該当なし：LSとその情報源（Location Generator（LG）またはLIS）の間のこの関係は、このドキュメントの範囲外です。
Req. 9. "(Viewer Rules) A Viewer does not need to be aware of the full Rules defined by the Rule Maker (because a Viewer SHOULD NOT retransmit Location Information), and thus a Viewer SHOULD receive only the subset of Privacy Rules necessary for the Viewer to handle the LO in compliance with the full Privacy Rules (such as, instruction on the time period for which the LO can be retained)".
必須9.「（ビューアルール）ビューアは、ルールメーカーによって定義された完全なルールを認識する必要はありません（ビューアは位置情報を再送信するべきではないため）。したがって、ビューアは、必要なプライバシールールのサブセットのみを受信する必要があります。完全なプライバシールール（LOを保持できる期間に関する指示など）に準拠してLOを処理するビューア。」
Compliant: The Rule Maker might define (via mechanisms outside the scope of this document) which policy rules are disclosed to other entities. For instance, if [RFC4745] is used to convey authorization policies from Rule Maker to LS, this is possible using the parameters specified in [GEOPRIV-POLICY].
準拠：ルールメーカーは、他のエンティティに開示されるポリシールールを（このドキュメントの範囲外のメカニズムを介して）定義する場合があります。たとえば、[RFC4745]を使用して承認ポリシーをルールメーカーからLSに伝達する場合、これは[GEOPRIV-POLICY]で指定されたパラメーターを使用して可能です。
In order to comply with these rules, a Location Recipient MUST NOT redistribute a location URI without express permission. Depending on the access control model, the location URI might be secret (see Section 3.3 of [RFC5808]).
これらのルールに準拠するために、ロケーション受信者は明示的な許可なしにロケーションURIを再配布してはなりません。アクセス制御モデルによっては、ロケーションURIが秘密になっている場合があります（[RFC5808]のセクション3.3を参照）。
Req. 10. (Full Rule language) Not Applicable: Note, however, that GEOPRIV has defined a rule language capable of expressing a wide range of privacy rules (see [RFC4745] and [GEOPRIV-POLICY].
必須10.（完全なルール言語）該当なし：ただし、GEOPRIVは幅広いプライバシールールを表現できるルール言語を定義していることに注意してください（[RFC4745]および[GEOPRIV-POLICY]を参照）。
Req. 11. (Limited Rule language) Not Applicable: This requirement applies to (and is addressed by) PIDF-LO [RFC4119].
必須11.（制限されたルール言語）該当なし：この要件は、PIDF-LO [RFC4119]に適用されます（これによって対処されます）。
Section 7.4 of [RFC3693] details the requirements of "Location Object Privacy and Security". These requirements are restated where they are applicable to this document:
[RFC3693]のセクション7.4は、「位置オブジェクトのプライバシーとセキュリティ」の要件を詳述しています。これらの要件は、このドキュメントに該当する場合に修正されます。
Req. 12. (Identity Protection) Compliant: Identity protection of the Target is provided as long as both of the following conditions are true:
必須12.（アイデンティティ保護）準拠：次の条件が両方とも満たされている限り、ターゲットのアイデンティティ保護が提供されます。
(a) the location URI is not associated with the identity of the Target in any context, and
（a）場所URIがどのような状況でもターゲットのIDに関連付けられていない。
(b) the PIDF-LO does not contain information about the identity of the Target.
（b）PIDF-LOには、ターゲットのアイデンティティに関する情報が含まれていません。
For instance, this requirement is complied with if the protocol that conveys the location URI does not link the identity of the Target to the location URI and the LS doesn't include meaningful identification information in the PIDF-LO document. Section 6 recommends that an unlinked pseudonym is used by the LS.
たとえば、ロケーションURIを伝達するプロトコルがターゲットのIDをロケーションURIにリンクせず、LSがPIDF-LOドキュメントに意味のある識別情報を含まない場合、この要件は遵守されます。セクション6では、リンクされていない仮名をLSで使用することを推奨しています。
Req. 13. (Credential Requirements) Compliant: The primary security mechanism specified in this document is Transport Layer Security. TLS offers the ability to use different types of credentials, including symmetric, asymmetric, or a combination of them.
必須13.（資格要件）準拠：このドキュメントで指定されている主要なセキュリティメカニズムは、トランスポート層セキュリティです。 TLSは、対称、非対称、またはそれらの組み合わせを含む、さまざまなタイプの資格情報を使用する機能を提供します。
Req. 14. (Security Features) Compliant: GEOPRIV defines a few security requirements for the protection of Location Objects such as mutual endpoint authentication, data object integrity, data object confidentiality, and replay protection. The ability to use Transport Layer Security fulfills most of these requirements. Authentication of Location Recipients in this document relies on proof of a shared secret -- the location URI. This does not preclude the addition of more robust authentication procedures.
必須14.（セキュリティ機能）準拠：GEOPRIVは、相互エンドポイント認証、データオブジェクトの整合性、データオブジェクトの機密性、再生保護など、ロケーションオブジェクトの保護に関するいくつかのセキュリティ要件を定義しています。トランスポート層セキュリティを使用する機能は、これらの要件のほとんどを満たします。このドキュメントの場所の受信者の認証は、共有秘密の証明、つまり場所のURIに依存しています。これは、より堅牢な認証手順の追加を妨げるものではありません。
Req. 15. (Minimal Crypto) Compliant: The mandatory-to-implement ciphersuite is provided in the TLS layer security specification [RFC5246].
必須15.（Minimal Crypto）準拠：実装に必須の暗号スイートは、TLSレイヤーセキュリティ仕様[RFC5246]で提供されています。
This section describes how HELD complies to the location reference requirements stipulated in [RFC5808]. Compliance of [RFC5985] to the Location Configuration Protocol is included.
このセクションでは、HELDが[RFC5808]で規定されている位置参照要件にどのように準拠するかについて説明します。 [RFC5985]のLocation Configuration Protocolへの準拠が含まれています。
Note: Use of HELD as a location dereference protocol does not necessarily imply that HELD is the corresponding LCP. This document is still applicable to HTTP location URIs that are acquired by other means.
注：ロケーション逆参照プロトコルとしてHELDを使用しても、必ずしもHELDが対応するLCPであるとは限りません。このドキュメントは、他の方法で取得されたHTTPロケーションURIにも適用されます。
C1. "Location URI support: The location configuration protocol MUST support a location reference in URI form".
C1。 「ロケーションURIサポート：ロケーション構成プロトコルは、URI形式のロケーション参照をサポートする必要があります」。
Compliant: HELD only provides location references in URI form.
準拠：HELDは、ロケーション形式の参照のみをURI形式で提供します。
C2. "Location URI expiration: When a location URI has a limited validity interval, its lifetime MUST be indicated".
C2。 「ロケーションURIの有効期限：ロケーションURIの有効期間に制限がある場合は、その有効期間を指定する必要があります」。
Compliant: HELD indicates the expiry time of location URIs using the "expires" attribute. [GEOPRIV-POLICY-URI] provides a way to control expiration of a location URI.
準拠：HELDは、「expires」属性を使用してロケーションURIの有効期限を示します。 [GEOPRIV-POLICY-URI]は、ロケーションURIの有効期限を制御する方法を提供します。
C3. "Location URI cancellation: The location configuration protocol MUST support the ability to request a cancellation of a specific location URI".
C3。 「ロケーションURIキャンセル：ロケーション構成プロトコルは、特定のロケーションURIのキャンセルを要求する機能をサポートする必要があります」。
Compliant with Extension: [GEOPRIV-POLICY-URI] describes how a location URI can be canceled through the application of policy. Without extensions, HELD does not provide a method for canceling location URIs.
拡張に準拠：[GEOPRIV-POLICY-URI]は、ポリシーの適用を通じてロケーションURIをキャンセルする方法を説明します。拡張機能がない場合、HELDはロケーションURIをキャンセルする方法を提供しません。
C4. "Location Information Masking: The location URI MUST ensure, by default, through randomization and uniqueness, that the location URI does not contain location information specific components".
C4。 「ロケーション情報マスキング：ロケーションURIは、デフォルトで、ランダム化と一意性により、ロケーションURIにロケーション情報固有のコンポーネントが含まれていないことを確認する必要があります。」
Compliant: The HELD specification [RFC5985] explicitly references this requirement in providing guidance on the format of the location URI.
準拠：HELD仕様[RFC5985]は、ロケーションURIのフォーマットに関するガイダンスを提供する際に、この要件を明示的に参照しています。
C5. "Target Identity Protection: The location URI MUST NOT contain information that identifies the Target (e.g., user or device)".
C5。 「ターゲットID保護：ロケーションURIには、ターゲット（ユーザーまたはデバイスなど）を識別する情報を含めてはなりません。」
Compliant: The HELD specification [RFC5985] provides specific guidance on the anonymity of the Target with regards to the generation of location URIs. Section 6 expands on this guidance.
準拠：HELD仕様[RFC5985]は、ロケーションURIの生成に関するターゲットの匿名性に関する具体的なガイダンスを提供します。セクション6では、このガイダンスについて詳しく説明します。
C6. "Reuse indicator: There SHOULD be a way to allow a Target to control whether a location URI can be resolved once only, or multiple times".
C6。 「再利用インジケータ：ロケーションURIを1回だけ解決できるか、複数回解決できるかをターゲットが制御できるようにする方法があるはずです。」
Not Compliant: Specific extensions to the protocol or authorization policy formats are needed to alter the default behavior, which allows unlimited resolution of the location URI.
非準拠：デフォルトの動作を変更するには、プロトコルまたは承認ポリシーの形式に特定の拡張機能が必要です。これにより、ロケーションURIを無制限に解決できます。
C7. "Selective disclosure: The location configuration protocol MUST provide a mechanism that allows the Rule Maker to control what information is being disclosed about the Target".
C7。 「選択的開示：ロケーション構成プロトコルは、ルールメーカーがターゲットについて開示する情報を制御できるようにするメカニズムを提供する必要があります」。
Compliant with Extension: Use of policy mechanisms and [GEOPRIV-POLICY-URI] enable this capability. Note that this document recommends that only location information be provided.
拡張機能に準拠：ポリシーメカニズムと[GEOPRIV-POLICY-URI]を使用すると、この機能が有効になります。このドキュメントでは、位置情報のみを提供することをお勧めしています。
C8. "Location URI Not guessable: As a default, the location configuration protocol MUST return location URIs that are random and unique throughout the indicated lifetime. A location URI with 128-bits of randomness is RECOMMENDED".
C8。 「推測できないロケーションURI：デフォルトでは、ロケーション構成プロトコルは、指定された存続期間を通じてランダムで一意のロケーションURIを返す必要があります。128ビットのランダム性を持つロケーションURIが推奨されます。」
Compliant: HELD specifies that location URIs conform to this requirement. The amount of randomness is not specifically identified since it depends on a number of factors that change over time, such as the number of valid location URIs, the validity period of those URIs, and the rate that guesses can be made.
準拠：HELDは、ロケーションURIがこの要件に準拠することを指定します。ランダム性の量は、有効なロケーションURIの数、それらのURIの有効期間、推測できるレートなど、時間とともに変化する多くの要因に依存するため、具体的には特定されません。
C9. "Location URI Options: In the case of user-provided authorization policies, where anonymous or non-guessable location URIs are not warranted, the location configuration protocol MAY support a variety of optional location URI conventions, as requested by a Target to a location configuration server, (e.g., embedded location information within the location URI)".
C9。 「ロケーションURIオプション：匿名または推測不可能なロケーションURIが保証されていない、ユーザー提供の承認ポリシーの場合、ロケーション構成プロトコルは、ロケーション構成のターゲットによって要求されるように、さまざまなオプションのロケーションURI規則をサポートする場合があります（MAY）。サーバー（たとえば、ロケーションURI内に埋め込まれたロケーション情報）」。
Not Compliant: HELD does not support Device-specified location URI forms.
非準拠：HELDはデバイス指定のロケーションURIフォームをサポートしていません。
D1. "Location URI support: The location dereference protocol MUST support a location reference in URI form".
D1。 「ロケーションURIサポート：ロケーション逆参照プロトコルは、URI形式のロケーション参照をサポートする必要があります」。
Compliant: HELD only provides location references in URI form.
準拠：HELDは、ロケーション形式の参照のみをURI形式で提供します。
D2. "Authentication: The location dereference protocol MUST include mechanisms to authenticate both the client and the server".
D2。 「認証：ロケーション逆参照プロトコルには、クライアントとサーバーの両方を認証するメカニズムが含まれている必要があります」。
Partially Compliant: TLS provides means for mutual authentication. This document only specifies the required mechanism for server authentication. Client authentication is not precluded.
部分的に準拠：TLSは相互認証の手段を提供します。このドキュメントでは、サーバー認証に必要なメカニズムのみを指定しています。クライアント認証は除外されません。
D3. "Dereferenced Location Form: The value returned by the dereference protocol MUST contain a well-formed PIDF-LO document".
D3。 「逆参照場所フォーム：逆参照プロトコルによって返される値には、整形式のPIDF-LOドキュメントが含まれている必要があります」。
Compliant: HELD requires that Location Objects are in the form of a PIDF-LO that complies with [RFC5491].
準拠：HELDは、ロケーションオブジェクトが[RFC5491]に準拠するPIDF-LOの形式であることを要求します。
D4. "Location URI Repeated Use: The location dereference protocol MUST support the ability for the same location URI to be resolved more than once, based on dereference server configuration".
D4。 「ロケーションURIの繰り返し使用：ロケーション逆参照プロトコルは、逆参照サーバー構成に基づいて、同じロケーションURIが複数回解決される機能をサポートする必要があります。」
Compliant: A Location Recipient may access and use a location URI as many times as desired until URI expiration results in the URI being invalidated. Authorization policies might include rules that modify this behavior.
準拠：ロケーション受信者は、URIの期限切れによってURIが無効になるまで、ロケーションURIに何度でもアクセスして使用できます。認可ポリシーには、この動作を変更するルールが含まれる場合があります。
D5. "The location dereference protocol MUST support confidentiality protection of messages sent between the Location Recipient and the location server".
D5。 「ロケーション逆参照プロトコルは、ロケーション受信者とロケーションサーバーの間で送信されるメッセージの機密保護をサポートする必要があります」。
Compliant: This document strongly recommends the use of TLS for confidentiality, and HELD mandates its implementation. Unsecured HTTP is permitted: the associated risks are described in Section 3.
準拠：このドキュメントでは、機密保持のためにTLSの使用を強く推奨しており、HELDはその実装を義務付けています。セキュリティで保護されていないHTTPは許可されます。関連するリスクはセクション3で説明されています。
Authors' Addresses
著者のアドレス
James Winterbottom Commscope Andrew Building (39) Wollongong University Campus Northfields Avenue Wollongong, NSW 2522 AU
James Winterbottom Commscope Andrew Building（39）ウロンゴン大学キャンパスNorthfields Avenueウロンゴン、NSW 2522 AU
Phone: +61 242 212938
EMail: james.winterbottom@commscope.com
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
ヘニングシュルズリンネコロンビア大学コンピュータサイエンス学科450コンピュータサイエンスビルディングニューヨーク、ニューヨーク10027アメリカ
Phone: +1 212 939 7042
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu
Martin Thomson Microsoft 3210 Porter Drive Palo Alto, CA 94304 USA
Martin Thomson Microsoft 3210 Porter Drive Palo Alto、CA 94304 USA
Phone: +1 650-353-1925
EMail: martin.thomson@skype.net