Internet Engineering Task Force (IETF) R. Barnes
Request for Comments: 6280 M. Lepinski
BCP: 160 BBN Technologies
Updates: 3693, 3694 A. Cooper
Category: Best Current Practice J. Morris
ISSN: 2070-1721 Center for Democracy & Technology
H. Tschofenig
Nokia Siemens Networks
H. Schulzrinne
Columbia University
July 2011
An Architecture for Location and Location Privacy
in Internet Applications
Abstract
抽象
Location-based services (such as navigation applications, emergency services, and management of equipment in the field) need geographic location information about Internet hosts, their users, and other related entities. These applications need to securely gather and transfer location information for location services, and at the same time protect the privacy of the individuals involved. This document describes an architecture for privacy-preserving location-based services in the Internet, focusing on authorization, security, and privacy requirements for the data formats and protocols used by these services.
（例えば、ナビゲーションアプリケーション、緊急サービス、およびフィールド内の機器の管理など）ロケーションベースのサービスは、インターネットホスト、そのユーザー、およびその他の関連するエンティティについての地理的位置情報を必要とします。これらのアプリケーションは、安全に収集し、位置情報サービスのための位置情報を転送すると同時に、関係者のプライバシーを保護する必要があります。この文書は、許可、セキュリティ、およびこれらのサービスによって使用されるデータフォーマットとプロトコルのためのプライバシー要件に焦点を当て、インターネットでプライバシーを保存ロケーションベースのサービスのためのアーキテクチャについて説明します。
Status of This Memo
このメモのステータス
This memo documents an Internet Best Current Practice.
このメモはインターネット最も良い現在の練習を説明します。
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 BCPs is available in Section 2 of RFC 5741.
このドキュメントはインターネットエンジニアリングタスクフォース（IETF）の製品です。これは、IETFコミュニティの総意を表しています。これは、公開レビューを受けており、インターネットエンジニアリング運営グループ（IESG）によって公表のために承認されています。 BCPの詳細については、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/rfc6280.
このドキュメントの現在の状態、任意の正誤表、そしてどのようにフィードバックを提供するための情報がhttp://www.rfc-editor.org/info/rfc6280で取得することができます。
Copyright Notice
著作権表示
Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved.
著作権（C）2011 IETF信託とドキュメントの作成者として特定の人物。全著作権所有。
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ドキュメント（http://trustee.ietf.org/license-info）に関連IETFトラストの法律の規定に従うものとします。彼らは、この文書に関してあなたの権利と制限を説明するように、慎重にこれらの文書を確認してください。コードコンポーネントは、トラスト法規定のセクションで説明4.eおよび簡体BSDライセンスで説明したように、保証なしで提供されているよう簡体BSDライセンスのテキストを含める必要があり、この文書から抽出されました。
Table of Contents
目次
1. Introduction ....................................................3
1.1. Binding Rules to Data ......................................4
1.2. Location-Specific Privacy Risks ............................5
1.3. Privacy Paradigms ..........................................6
2. Terminology Conventions .........................................7
3. Overview of the Architecture ....................................7
3.1. Basic Geopriv Scenario .....................................8
3.2. Roles and Data Formats ....................................10
4. The Location Life Cycle ........................................12
4.1. Positioning ...............................................13
4.1.1. Determination Mechanisms and Protocols .............14
4.1.2. Privacy Considerations for Positioning .............16
4.1.3. Security Considerations for Positioning ............16
4.2. Location Distribution .....................................17
4.2.1. Privacy Rules ......................................17
4.2.2. Location Configuration .............................19
4.2.3. Location References ................................20
4.2.4. Privacy Considerations for Distribution ............21
4.2.5. Security Considerations for Distribution ...........23
4.3. Location Use ..............................................24
4.3.1. Privacy Considerations for Use .....................25
4.3.2. Security Considerations for Use ....................25
5. Security Considerations ........................................25
6. Example Scenarios ..............................................28
6.1. Minimal Scenario ..........................................28
6.2. Location-Based Web Services ...............................29
6.3. Emergency Calling .........................................31
6.4. Combination of Services ...................................32
7. Glossary .......................................................35
8. Acknowledgements ...............................................38
9. References .....................................................38
9.1. Normative References ......................................38
9.2. Informative References ....................................38
Location-based services (applications that require information about the geographic location of an individual or device) are becoming increasingly common on the Internet. Navigation and direction services, emergency services, friend finders, management of equipment in the field, and many other applications require geographic location information about Internet hosts, their users, and other related entities. As the accuracy of location information improves and the expense of calculating and obtaining it declines, the distribution and use of location information in Internet-based services will likely become increasingly pervasive. Ensuring that location information is transmitted and accessed in a secure and privacy-protective way is essential to the future success of these services, as well as the minimization of the privacy harms that could flow from their wide deployment and use.
ロケーションベースのサービス（個人またはデバイスの地理的位置に関する情報を必要とするアプリケーション）は、インターネット上でますます一般的になりつつあります。ナビゲーションと方向サービス、緊急サービス、友人のファインダー、フィールド内の機器の管理、および他の多くのアプリケーションは、インターネットホスト、そのユーザー、およびその他の関連するエンティティについての地理的位置情報を必要とします。位置情報の精度向上と計算し、それが低下得る費用として、インターネットベースのサービスにおける位置情報の分布および使用は、おそらく、ますます普及します。位置情報が安全とプライバシー保護の方法で送信され、アクセスされていることを保証することは、これらのサービスの将来の成功だけでなく、彼らの幅広い展開と使用から流れ込む可能性があり、プライバシーの害の最小化に不可欠です。
Standards for communicating location information over the Internet have an important role to play in providing a technical basis for privacy and security protection. This document describes a standardized privacy- and security-focused architecture for location-based services in the Internet: the Geopriv architecture. The central component of the Geopriv architecture is the location object, which is used to convey both location information about an individual or device and user-specified privacy rules governing that location information. As location information moves through its life cycle -- positioning, distribution, and use by its ultimate recipient(s) -- Geopriv provides mechanisms to secure the integrity and confidentiality of location objects and to ensure that location information is only transmitted in compliance with the user's privacy rules.
インターネット上での位置情報を通信するための基準は、プライバシーとセキュリティ保護のための技術的な基礎を提供して果たすべき重要な役割を担っています。 Geoprivアーキテクチャ：この文書は、インターネットでのロケーションベースのサービスのための標準化されたprivacy-とセキュリティ重視のアーキテクチャについて説明します。 Geoprivアーキテクチャの中心的なコンポーネントは、個人またはデバイスとその位置情報を管理するユーザ指定のプライバシールールについて双方の位置情報を伝えるために使用される場所のオブジェクトです。位置情報は、そのライフサイクルを通じて移動するにつれて - 位置、分布、及びその最終的な受信者（単数または複数）によって使用が - Geoprivは、位置オブジェクトの完全性と機密性を確保するために、その位置情報のみに準拠して送信されていることを確認するためのメカニズムを提供しますユーザーのプライバシー規則。
The goals of this document are two-fold: First, the architecture described revises and expands on the basic Geopriv Requirements [2] [3], in order to clarify how these privacy concerns and the Geopriv architecture apply to use cases that have arisen since the publication of those documents. Second, this document provides a general introduction to Geopriv and Internet location-based services, and is useful as a good first document for readers new to Geopriv.
このドキュメントの目標は2つある：まず、アーキテクチャは、修正に関するお知らせを説明し、基本的なGeoprivの要件を拡張[2] [3]、これらのプライバシーの懸念やGeoprivアーキテクチャがあるため生じた例を使用して適用する方法を明確にするために、それらの文書の出版。第二に、この文書はGeoprivとインターネットロケーションベースのサービスへの一般的な紹介を提供し、Geoprivに新しい読者のために良い最初の文書として有用です。
A central feature of the Geopriv architecture is that location information is always bound to privacy rules to ensure that entities that receive location information are informed of how they may use it. These rules can convey simple directives ("do not share my location with others"), or more robust preferences ("allow my spouse to know my exact location all of the time, but only allow my boss to know it during work hours"). By creating a structure to convey the user's preferences along with location information, the likelihood that those preferences will be honored necessarily increases. In particular, no recipient of the location information can disavow knowledge of users' preferences for how their location may be used. The binding of privacy rules to location information can convey users' desire for and expectations of privacy, which in turn helps to bolster social and legal systems' protection of those expectations.
Geoprivアーキテクチャの中心的な特徴は、位置情報は常に位置情報を受信エンティティが、彼らはそれをどのように使用できるかが通知されていることを確認するために、プライバシー規則にバインドされていることです。これらのルールは、（「私の配偶者は、すべての時間を自分の正確な位置を知ることができますが、唯一の私の上司は勤務時間中にそれを知ることができるように」）、単純なディレクティブ（「他の人と自分の位置を共有しない」）、またはより堅牢な好みを伝えることができます。位置情報とともにユーザの嗜好を伝達する構造を作成することによって、それらの選好が尊重される可能性は必然的に増加します。具体的には、位置情報のない受信者は、それらの位置を使用することができる方法に対するユーザーの嗜好の知識を否認することができません。位置情報のプライバシー規則の結合は、その期待の保護利用者の順番に、社会と法制度強化するのに役立ちますのための欲求とプライバシーの期待を伝えることができます。
Binding of usage rules to sensitive information is a common way of protecting information. Several emerging schemes for expressing copyright information provide for rules to be transmitted together with copyrighted works. The Creative Commons [28] model is the most prominent example, allowing an owner of a work to set four types of rules ("Attribution", "Noncommercial", "No Derivative Works", and "ShareAlike") governing the subsequent use of the work. After the author sets these rules, the rules are conveyed together with the work itself, so that every recipient is aware of the copyright terms.
機密情報への使用ルールの結合は、情報を保護するための一般的な方法です。著作権情報を表現するためのいくつかの新たなスキームは、著作物と一緒に送信されるルールを提供します。クリエイティブ・コモンズ[28]モデルのその後の使用を管理する規則4種類（「属性」、「非営利」、「いいえ派生物」、および「同一条件許諾」）を設定する作業の所有者を可能にする、最も顕著な例であります作品。著者はこれらのルールを設定した後、すべての受信者が著作権条項を認識しているように、ルールは、作品自体と一緒に搬送されます。
Classification systems for controlling sensitive documents within an organization are another example. In these systems, when a document is created, it is marked with a classification such as "SECRET" or "PROPRIETARY". Each recipient of the document knows from this marking that the document should only be shared with other people who are authorized to access documents with that marking. Classification markings can also convey other sorts of rules, such as a specification for how long the marking is valid (a declassification date). The United States Department of Defense guidelines for classification [4] provide one example.
組織内の機密文書を制御するための分類システムは、別の例です。文書が作成されたときに、これらのシステムでは、このような「SECRET」または「専有」として分類してマークされます。文書の各受信者は、文書はそれだけでマーキングした文書にアクセスすることを許可された他の人と共有する必要があることをこのマーキングから知っています。分類マーキングはまた、このようなマーキングが有効であるどのくらいの仕様（機密解除の日）などのルールの他の種類を、伝えることができます。分類のための国防総省のガイドライン米国は、[4]の一例を提供します。
While location-based services raise some privacy concerns that are common to all forms of personal information, many of them are heightened, and others are uniquely applicable in the context of location information.
ロケーションベースのサービスは、個人情報のすべての形態に共通するいくつかのプライバシーの問題を提起しながら、それらの多くは高まっており、他のものは、位置情報のコンテキスト内で一意に適用されます。
Location information is frequently generated on or by mobile devices. Because individuals often carry their mobile devices with them, location data may be collected everywhere and at any time, often without user interaction, and it may potentially describe both what a person is doing and where he or she is doing it. For example, location data can reveal the fact that an individual was at a particular medical clinic at a particular time. The ubiquity of location information may also increase the risks of stalking and domestic violence if perpetrators are able to use (or abuse) location-based services to gain access to location information about their victims.
位置情報は、頻繁にまたはモバイルデバイスによって生成されます。個人は、多くの場合、彼らと自分のモバイルデバイスを運ぶので、位置データは、多くの場合、ユーザーとの対話なしで、どこでも、いつでも収集することができる、それが潜在的に、人がやっていると、どこ彼または彼女はそれをやっていることの両方を記述することができます。例えば、位置データは、個人が特定の時間に特定の医療クリニックであったという事実を明らかにすることができます。加害者が使用すること（または乱用）であれば、位置情報の偏在も、被害者の位置情報へのアクセスを得るために位置情報サービスをストーカーし、家庭内暴力のリスクを増大させることができます。
Location information is also of particular interest to governments and law enforcers around the world. The existence of detailed records of individuals' movements should not automatically facilitate the ability for governments to track their citizens, but in some jurisdictions, laws dictating what government agents must do to obtain location data are either non-existent or out of date.
位置情報は、世界中の政府や法執行に特に関心のもあります。個人の動きの詳細な記録の有無を自動的に政府が国民を追跡するための能力を促進べきではありませんが、いくつかの法域では、政府のエージェントは、位置データを取得するために何をしなければならないか口述法律は存在しないか、期限が切れどちらかです。
Traditionally, the extent to which data about individuals enjoys privacy protections on the Internet has largely been decided by the recipients of the data. Internet users may or may not be aware of the privacy practices of the entities with whom they share data. Even if they are aware, they have generally been limited to making a binary choice between sharing data with a particular entity or not sharing it. Internet users have not historically been granted the opportunity to express their own privacy preferences to the recipients of their data and to have those preferences honored.
伝統的に、個人に関するデータの範囲は、インターネット上のプライバシー保護は、主にデータの受信者によって決定された楽しんでいます。インターネットユーザーは、または、彼らはデータを共有して誰とエンティティのプライバシー慣行の意識であってもなくてもよいです。彼らは認識している場合でも、彼らは一般的に、特定のエンティティで共有するデータ間のバイナリ選択をするか、それを共有しないように制限されていました。インターネットユーザーは、歴史的に、データの受信者に、自分のプライバシー設定を表現するために、それらの好みは光栄持っている機会を付与されていません。
This paradigm is problematic because the interests of data recipients are often not aligned with the interests of data subjects. While both parties may agree that data should be collected, used, disclosed, and retained as necessary to deliver a particular service to the data subject, they may not agree about how the data should otherwise be used. For example, an Internet user may gladly provide his email address on a Web site to receive a newsletter, but he may not want the Web site to share his email address with marketers, whereas the Web site may profit from such sharing. Neither providing the address for both purposes nor deciding not to provide it is an optimal option from the Internet user's perspective.
データ受信者の利益は、多くの場合、データ主体の利益と一致していないので、このパラダイムには問題があります。両当事者は、データを収集、使用、開示され、かつデータ対象に特定のサービスを提供するために、必要に応じて保持されるべきであることに同意することができるが、彼らはデータが別の方法を使用する必要があるかについて同意しない場合があります。たとえば、インターネットユーザーは喜んでニュースレターを受け取るために、Webサイト上で自分のメールアドレスを提供することができるが、Webサイトでは、そのような共有から利益場合がある彼は、Webサイトがマーケティング担当者との彼のメールアドレスを共有したくないかもしれません。どちらも両方の目的のためにアドレスを提供することも、それがインターネットユーザーの観点から最適なオプションです提供しないことを決定します。
The Geopriv model departs from this paradigm for privacy protection. As explained above, location information can be uniquely sensitive. And as location-based services emerge and proliferate, they increasingly require standardized protocols for communicating location information between services and entities. Recognizing both of these dynamics, Geopriv gives data subjects the ability to express their choices with respect to their own location information, rather than allowing the recipients of the information to define how it will be used. The combination of heightened privacy risk and the need for standardization compelled the Geopriv designers to shift away from the prevailing Internet privacy model, instead empowering users to express their privacy preferences about the use of their location information.
Geoprivモデルは、プライバシー保護のため、このパラダイムから出発します。以上説明したように、位置情報を一意に敏感であることができます。ロケーションベースのサービスが出現し、増殖するように、彼らはますますサービスとエンティティ間の位置情報を通信するための標準化されたプロトコルが必要です。これらのダイナミクスの両方を認識し、Geoprivはデータ対象をむしろ情報の受信者は、それが使用される方法を定義することを可能にするよりも、自分の位置情報に対して、その選択肢を発現する能力を与えます。高めのプライバシーリスクの組み合わせと標準化の必要性ではなく、ユーザーが自分の位置情報の利用についての彼らのプライバシー設定を表現するために力を与える、離れ実勢インターネットプライバシーモデルからシフトするGeoprivデザイナーを強要しました。
Geopriv does not, by itself, provide technical means through which it can be guaranteed that users' location privacy rules will be honored by recipients. The privacy protections in the Geopriv architecture are largely provided by virtue of the fact that recipients of location information are informed of relevant privacy rules, and are expected to only use location information in accordance with those rules. The distributed nature of the architecture inherently limits the degree to which compliance can be guaranteed and verified by technical means. Section 5 describes how some security mechanisms can address this to a limited extent.
Geoprivは、それ自体で、ユーザの位置プライバシー規則は、受信者によって尊重されることを保証することができ、それを通して技術的手段を提供していません。 Geoprivアーキテクチャのプライバシー保護は、主に、位置情報の受信者は、関連するプライバシールールを通知され、そしてのみルールに従って位置情報を使用することが期待されているという事実により提供されます。アーキテクチャの分散性は、本質的に、コンプライアンスを保証し、技術的手段によって検証することができる程度を制限します。第5節では、いくつかのセキュリティメカニズムは、限定された範囲でこの問題に対処する方法について説明します。
By binding privacy rules to location information, however, Geopriv provides valuable information about users' privacy preferences, so that non-technical forces such as legal contracts, governmental consumer protection authorities, and marketplace feedback can better enforce those privacy preferences. If a commercial recipient of location information, for example, violates the location rules bound to the information, the recipient can in a growing number of countries be charged with violating consumer or data protection laws. In the absence of a binding of rules with location information, consumer protection authorities would be less able to protect individuals whose location information has been abused.
このような法的契約、政府の消費者保護当局、および市場からのフィードバックなどの非技術的な力が、より良いものをプライバシー設定を強制することができるように、位置情報にプライバシー規則を結合することによって、しかし、Geoprivは、ユーザーのプライバシー設定に関する貴重な情報を提供します。位置情報の商用受信者は、例えば、情報に結合された場所の規則に違反した場合、受信者は、国が増えている中で、消費者やデータ保護法違反で起訴することができます。位置情報とルールの結合がない場合には、消費者保護当局は、その位置情報に虐待された個人を保護するあまりができるであろう。
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 RFC 2119 [1].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はありますRFC 2119に記載されるように解釈される[1]。
Throughout the remainder of this document, capitalized terms defined in Section 7 refer to Geopriv-specific roles and formats; the same terms used in all lowercase refer generically to those terms.
この文書の残りの部分を通して、セクション7で定義された大文字の用語はGeopriv固有のロールとフォーマットを指します。すべて小文字で使用したのと同じ用語は、それらの用語を包括的に参照してください。
This section provides an overview of the Geopriv architecture for the secure and private distribution of location information on the Internet. We describe the three phases of the "location life cycle" -- positioning, distribution, and use -- and discuss how the components of the architecture fit within each phase. The next section provides additional detail about how each phase can be achieved in a private and secure manner.
このセクションでは、インターネット上の位置情報を安全かつプライベートな配布のためGeoprivアーキテクチャの概要を説明します。ポジショニング、配布、および使用 - - 私たちは、「場所のライフサイクル」の3つの段階を説明し、各フェーズ内のアーキテクチャフィットのどのコンポーネントについて説明します。次のセクションでは、各フェーズがプライベートで安全な方法で達成することができる方法についての追加の詳細を提供します。
The risks discussed in the previous section all arise from unauthorized disclosure or usage of location information. Thus, the Geopriv architecture has two fundamental privacy goals:
前のセクションで説明したリスクは、すべての位置情報の不正な開示または使用から生じます。このように、Geoprivアーキテクチャは、2つの基本的なプライバシーの目標を持っています：
1. Ensure that location information is distributed only to authorized entities, and
1.位置情報のみ許可エンティティに配信されていることを確認し、
2. Provide information to those entities about how they are authorized to use the location information.
2.それらは、位置情報を利用することが許可されている方法についてはこれらのエンティティに情報を提供します。
If these two goals are met, all parties that receive location information will also receive directives about how they can use that information. Privacy-preserving entities will only engage in authorized uses, and entities that violate privacy will do so knowingly, since they have been informed of what is authorized (and thus, implicitly, of what is not).
これらの二つの目標が達成されている場合は、位置情報を受信するすべての関係者はまた、彼らはその情報を使用する方法についての指示を受信します。プライバシ保護エンティティは、唯一の認可用途に従事し、彼らは（したがって、暗黙のうちに、ではないものの）認可されているものが通知されているので、プライバシーを侵害するエンティティは、その故意に行います。
Privacy rules and their distribution are thus the central technical components of the privacy system, since they inform location recipients about how they are authorized to use that information. The two goals in the preceding paragraph are enabled by two classes of rules:
彼らは、彼らがその情報を使用することが許可されているかについて場所の受信者に通知するため、個人情報保護のルールとその分布は、これプライバシーシステムの中心的な技術要素です。前項の2つのゴールは、ルールの二つのクラスによって有効になります。
1. Access control rules: Rules that describe which entities may receive location information and in what form
1.アクセス制御ルール：位置情報を受信し、どのような形態で得るエンティティ記述ルール
2. Usage rules: Rules that describe what uses of location information are authorized
2.使用ルール：ルール説明位置情報を使用して、何が許可されています
Within this framework for privacy, security mechanisms provide support for the application of privacy rules. For example, authentication mechanisms validate the identities of entities requesting a location (so that authorization and access-control policies can be applied), and confidentiality mechanisms protect location information en route between privacy-preserving entities. Security mechanisms can also provide assurances that are outside the purview of privacy by, for example, assuring location recipients that location information has been faithfully transmitted to them by its creator.
プライバシーのため、この枠組みの中で、セキュリティメカニズムは、プライバシー規則の適用のためのサポートを提供します。例えば、認証メカニズムは、（その許可およびアクセス制御ポリシーを適用できるようにする）の場所を要求するエンティティのアイデンティティを検証し、機密性のメカニズムは、プライバシ保護のエンティティ間の途中の位置情報を保護します。セキュリティ・メカニズムは、その位置情報が忠実にその作成者によってそれらに送信された場所の受信者を保証するなどして、プライバシーの範囲外にある保証を提供することができます。
As location information is transmitted among Internet hosts, it goes through a "location life cycle": first, the location is computed based on some external information (positioning), and then it is transmitted from one host to another (distribution) until finally it is used by a recipient (use).
位置情報は、インターネットホスト間で送信されるように、「位置のライフサイクル」を通過する第一、位置は、いくつかの外部情報（位置）に基づいて計算され、それは別のホスト（分布）から最終的にそれまでに送信され受信者（使用）で使用されます。
For example, suppose Alice is using a mobile device, she learns of her location from a wireless location service, and she wishes to share her location privately with her friends by way of a presence service. Alice clearly needs to provide the presence server with her location and rules about which friends can be provided with her location. To enable Alice's friends to preserve her privacy, they need to be provided with privacy rules. Alice may tell some of her friends the rules directly, or she can have the presence server provide the rules to her friends when it provides them with her location. In this way, every friend who receives Alice's location is authorized by Alice to receive it, and every friend who receives it knows the rules. Good friends will obey the rules. If a bad friend breaks them and Alice finds out, the bad friend cannot claim that he was unaware of the rules.
例えば、アリスがモバイルデバイスを使用していると仮定し、彼女は無線ロケーション・サービスからの彼女の場所を知った、と彼女はプレゼンスサービスを介して、彼女の友人と個人的に彼女の場所を共有することを希望します。アリスは明らかに彼女の場所や友人が彼女の場所を提供することができるかについてのルールをプレゼンス・サーバを提供する必要があります。彼女のプライバシーを保護するためにアリスの友人を有効にするには、彼らはプライバシー規則を提供する必要があります。アリスは、直接彼女の友人のルールのいくつかを教えてくれたり、彼女はそれが彼女の場所でそれらを提供する場合、プレゼンスサーバは、彼女の友人にルールを提供することができます。このように、アリスの場所を受け取り、すべての友人は、それを受け取るためにアリスによって承認され、それを受けて、すべての友人がルールを知っています。良い友達は、ルールに従います。悪い友人がそれらを破壊し、アリスが出て見つけた場合、悪い友人が、彼はルールを知らなかったと主張することはできません。
Some of Alice's friends will be interested in using Alice's location only for their own purposes, for example, to meet up with her or plot her location over time. The usage rules that they receive direct them as to what they can or cannot do (for example, Alice might not want them keeping her location for more than, say, two weeks).
アリスの友人の中には、彼女と会うか、時間をかけて自分の位置をプロットするために、例えば、唯一独自の目的のために、アリスの場所を使用することに興味があるだろう。彼らはかできないことができるかに、それらを直接受ける利用規則は、（例えば、アリスはそれらをより二週間、たとえば、以下のための彼女の場所を保ちたくない場合があります）。
Consider one friend, Bob, who wants to send Alice's location to some of his friends. To operate in a privacy-protective way, Bob needs not only usage rules for himself, but also access control rules that describe who he can send information to and rules to give to the recipients. If the rules he received from the presence server authorize him to give Alice's location to others, he may do so; otherwise, he will require additional rules from Alice before he is authorized to distribute her location. If recipients who receive Alice's location from Bob want to distribute the location information further, they must go through the same process as Bob.
彼の友人の何人かにアリスの場所を送信したい1人の友人、ボブが、考えてみましょう。プライバシー保護の方法で動作させるために、ボブは自分のためだけではない使用規則を必要とするだけでなく、彼は受信者に与えることにして、ルール情報を送信できるユーザーを記述する制御ルールにアクセスします。彼は、プレゼンスサーバから受信したルールは、他の人にアリスの場所を与えるために彼を許可した場合、彼はそうすることが、彼は彼女の場所を配布することを許可される前に、それ以外の場合は、彼はアリスから追加のルールが必要になります。ボブからアリスの位置を受け取る受信者は、さらに位置情報を配布する場合、彼らはボブと同じプロセスを経なければなりません。
The whole example is illustrated in the following figure:
全体の例を次の図に示します。
+----------+
| Wireless |
| Location |
| Service | Retrieve
+----------+ Access Control Rules
| +--------------------------------+
| | +--------------------------+ |
Location | | Access | |
| | | Control Rules v |
| | | +-----+
| | | | Bob |
| | | |+---+|--> ...
| | | +----->||PC ||
........... v | | ++---++
| +------+| +----------+ |
| |Mobile|+--Location->| Presence |--Location-->| +----------+
| |Phone || | Server | |---->| Friend-1 |
| +------++---Rules--->| |---Rules---->| +----------+
| Alice | +----------+ |
| O | |
| /|\ | | +----------+
| / \ | +---->| Friend-2 |
`---------' +----------+
Figure 1: Basic Geopriv Scenario
図1：基本的なシナリオGeopriv
The above example illustrates the six basic roles in the Geopriv architecture:
上記の例では、Geoprivアーキテクチャの6つの基本的な役割を示しています。
Target: An individual or other entity whose location is sought in the Geopriv architecture. In many cases, the Target will be the human user of a Device, but it can also be an object such as a vehicle or shipping container to which a Device is attached. In some instances, the Target will be the Device itself. The Target is the entity whose privacy Geopriv seeks to protect. Alice is the Target in Figure 1.
ターゲット：その場所Geoprivアーキテクチャで求められている個人またはその他のエンティティ。多くの場合、対象は、装置の人間のユーザになり、それはまた、そのようなデバイスが取り付けられた車両又は輸送コンテナなどの対象とすることができます。いくつかの例では、ターゲットは、デバイス自体になります。ターゲットは、そのプライバシーGeoprivを保護しようとする実体です。アリスは、図1の標的です。
Device: The physical device, such as a mobile phone, PC, or embedded micro-controller, whose location is tracked as a proxy for the location of a Target. Alice's mobile phone is the Device in Figure 1.
デバイス：物理デバイス、例えば位置ターゲットの位置のためのプロキシとして追跡され、携帯電話、PC、または組み込みマイクロコントローラ、など。アリスの携帯電話は、図1のデバイスです。
Rule Maker (RM): Performs the role of creating rules governing access to location information for a Target. In some cases, the Target performs the Rule Maker role (as is the case with Alice), and in other cases they are separate. For example, a parent may serve as the Rule Maker when the Target is his child, or a corporate security officer may serve as the Rule Maker for devices owned by the corporation but used by employees. The Rule Maker is also not necessarily the owner of the Device. For example, a corporation may provide a Device to an employee but permit the employee to serve as the Rule Maker and set her own privacy rules.
ルールメーカー（RM）は：ターゲットの位置情報へのアクセスを管理する規則を作成するための役割を実行します。 （アリスと同様に）いくつかのケースでは、ターゲットは、ルールメーカーの役割を行い、他の場合には、それらは分離されています。ターゲットは彼の子であるとき例えば、親がルールメーカーとして働くことができる、または企業のセキュリティ担当者は、企業が所有しているが、従業員が使用するデバイスのためのルールメーカーとしての役割を果たすことができます。ルールのメーカーは必ずしもまた、デバイスの所有者ではありません。例えば、企業は、従業員へのデバイスを提供しますが、ルールメーカーとして機能し、彼女自身のプライバシー規則を設定するために従業員を許可することができます。
Location Generator (LG): Performs the roles of initially determining or gathering the location of the Device and providing it to Location Servers. Location Generators may be any sort of software or hardware used to obtain the Device's location. Examples include Global Positioning System (GPS) chips and cellular networks. A Device may even perform the Location Generator role for itself; Devices capable of unassisted satellite-based positioning and Devices that accept manually entered location information are two examples. The wireless location service plays the Location Generator role in Figure 1.
位置ジェネレータ（LG）は：最初に決定またはデバイスの位置を収集しロケーションサーバにそれを提供する役割を実行します。位置ジェネレータは、デバイスの位置を取得するために使用されるソフトウェアまたはハードウェアの任意の種類であってもよいです。例としては、全地球測位システム（GPS）チップ及びセルラネットワークを含みます。デバイスがあっても、それ自体のためにロケーション・ジェネレータの役割を実行することができます。自力衛星ベースの位置決めが可能なデバイスと手動で入力された位置情報を受け入れるデバイスは2つの例です。無線ロケーションサービスは、図1の場所ジェネレーターの役割を果たしています。
Location Server (LS): Performs the roles of receiving location information and rules, applying the rules to the location information to determine what other entities, if any, can receive location information, and providing the location to Location Recipients. Location Servers receive location information from Location Generators and rules from Rule Makers, and then apply the rules to the location information. Location Servers may not necessarily be "servers" in the colloquial sense of hosts in remote data centers servicing requests. Rather, a Location Server can be any software or hardware component that distributes location information. Examples include a server in an access network, a presence server, or a Web browser or other software running on a Device. The above example includes three Location Servers: Alice's mobile phone, the presence service, and Bob's PC.
ロケーションサーバ（LS）は：もしあれば、位置情報およびルールを受信し、他のどのエンティティを決定するために、位置情報にルールを適用する役割を行い、位置情報を受信し、位置受信者に場所を提供することができます。ロケーションサーバは、ルールメーカーから場所ジェネレータとルールから位置情報を受信して、位置情報にルールを適用します。ロケーションサーバは、必ずしも要求にサービスを提供し、リモートデータセンターでホストの口語意味での「サーバー」ではないかもしれません。むしろ、ロケーションサーバは位置情報を配信する任意のソフトウェアまたはハードウェアコンポーネントとすることができます。例としては、アクセスネットワーク、プレゼンスサーバ、またはWebブラウザやデバイス上で実行されている他のソフトウェアでサーバーが含まれています。アリスの携帯電話、プレゼンスサービス、およびボブのPC：上記の例では、3台のロケーションサーバを含んでいます。
Location Recipient (LR): Performs the role of receiving location information. A Location Recipient may ask for a location explicitly (by sending a query to a Location Server), or it may receive a location asynchronously. The presence service, Bob, Friend-1, and Friend-2 are Location Recipients in Figure 1.
場所受信者（LR）は：位置情報を受信する役割を実行します。場所受信者は、（ロケーションサーバにクエリを送信することにより）明示的に場所を求めることができる、またはそれは非同期的に場所を受け取ることができます。プレゼンスサービスは、ボブは、友達-1、及びフレンド-2は、図1の場所受信者です。
In general, these roles may or may not be performed by physically separate entities, as demonstrated by the entities in Figure 1, many of which perform multiple roles. It is not uncommon for the same entity to perform both the Location Generator and Location Server roles, or both the Location Recipient and Location Server roles. A single entity may take on multiple roles simply by virtue of its own capabilities and the permissions provided to it.
複数の役割を実行多くは図1のエンティティによって示されるように、一般的に、これらの役割は、または、物理的に別々のエンティティによって実行してもしなくてもよいです。同じエンティティが場所ジェネレータおよびロケーションサーバの役割、または両方の場所受信者とロケーションサーバの役割の両方を実行することは珍しくありません。単一のエンティティは、単にそれ自身の機能と、それに設けられた権限によって複数の役割をとることができます。
Although in the above example there is only a single Location Generator and a single Rule Maker, in some cases a Location Server may receive Location Objects from multiple Location Generators or Rules from multiple Rule Makers. Likewise, a single Location Generator may publish location information to multiple Location Servers, and a single Location Recipient may receive Location Objects from multiple Location Servers.
上記の例では、単一の場所ジェネレータと単一のルールメーカーがあるが、いくつかの場合にはロケーションサーバは、複数のルールのメーカーからの複数の場所ジェネレータまたはルールから位置オブジェクトを受信することができます。同様に、単一の場所ジェネレータは、複数のロケーションサーバへの位置情報を公開することができ、単一の場所の受信者は、複数のロケーションサーバからのロケーションオブジェクトを受け取ることができます。
There is a close relationship between a Target and its Device. The term "Device" is used when discussing protocol interactions, whereas the term "Target" is used when discussing generically the person or object being located and its privacy. While in the example above there is a one-to-one relationship between the Target and the Device, Geopriv can also be used to convey location information about a device that is not directly linked to a single individual or object, such as a Device shared by multiple individuals.
ターゲットとそのデバイスとの間には密接な関係があります。プロトコル相互作用を議論する際に一般的に人やオブジェクトに配置されると、そのプライバシーを議論する場合、用語「標的」が使用され、一方、用語「デバイス」は、使用されています。一例では、上記ターゲットとデバイスとの間の1対1の関係があるが、Geoprivはまた、共有デバイスとして直接単個人やオブジェクトにリンクされていない装置についての位置情報を伝えるために使用することができます複数の個人によります。
Two data formats are necessary within this architecture:
二つのデータ形式は、このアーキテクチャ内で必要です：
Location Object (LO): An object used to convey location information together with Privacy Rules. Geopriv supports both geodetic location data (latitude, longitude, altitude, etc.) and civic location data (street, city, state, etc.). Either or both types of location information may be present in a single LO (see the considerations in [5] for LOs containing multiple locations). Location Objects typically include some sort of identifier of the Target.
位置オブジェクト（LO）：プライバシールールと一緒に位置情報を伝えるために使用されるオブジェクト。 Geoprivは測地位置データ（緯度、経度、高度等）、市民の位置データ（通り、市、州、等）の両方をサポートします。いずれかまたは位置情報の両方のタイプは、単一のLO（LOSが複数の場所を含むため[5]で考察を参照）中に存在してもよいです。ロケーションオブジェクトは、典型的には、標的の識別子のいくつかの並べ替えが含まれます。
Privacy Rule: A directive that regulates an entity's activities with respect to location information, including the collection, use, disclosure, and retention of the location information. Privacy Rules describe which entities may obtain location information in what form (access control rules) and how location information may be used by an entity (usage rules).
プライバシールール：収集、使用、開示、および位置情報の保持などの位置情報、に関して、企業の活動を規制する指令。プライバシールールは、どのような形で位置情報を取得することができるエンティティ記述（アクセス制御ルール）と位置情報は、エンティティ（使用規則）によって使用されることができる方法。
The whole example, using Geopriv roles and formats, is illustrated in the following figure:
全例では、Geoprivロールおよびフォーマットを使用して、次の図に示されています。
+----+
| LG |
+----+
^
|
Positioning
Data
|
| +------------Privacy Rules------------------>+----+
| | +---->| LR |--> ...
| | | | LS |
v | | +----+
+-------+ |
|Target | +----+ | +----+
|Device |--------------->| LR |---------------+---->| LR |
| RM | LO | LS | LO | +----+
| LS | +----+ |
+-------+ |
| +----+
+---->| LR |
+----+
Figure 2: Basic Geopriv Scenario
図2：基本的なシナリオGeopriv
The previous section gave an example of how an individual's location can be distributed through the Internet. In general, the location life cycle breaks down into three phases:
前のセクションでは、個々の場所は、インターネットを介して配布することができる方法の例を示しました。一般的には、場所のライフサイクルは3つのフェーズに分解し：
1. Positioning: A Location Generator determines the Device's location.
1.ポジショニング：ロケーションジェネレータは、デバイスの位置を決定します。
2. Distribution: Location Servers send location information to Location Recipients, which may in turn act as Location Servers and further distribute the location to other Location Recipients, possibly several times.
2.分布：ロケーションサーバは、ロケーションサーバとしてターン行為で、さらにおそらく他の場所受信者、数回に位置を分配することができる場所の受信者に位置情報を送信します。
Each of these phases involves a different set of Geopriv roles, and each has a different set of privacy and security implications. The Geopriv roles are mapped onto the location life cycle in the figure below.
これらの相のそれぞれは、Geoprivの役割の異なるセットを含み、それぞれがプライバシーとセキュリティの影響の異なるセットを持っています。 Geoprivロールは下図の位置のライフサイクルにマッピングされます。
+----------+
| Rule |+
| Maker(s)||
Positioning | ||
Data +----------+|
| +----------+
| | Rules
| |
| |
V V
+----------+ +----------+ +----------+
|Location | Location | Location |+ LO |Location |
|Generator |--------------->| Server(s)||-------------->|Recipient |
| | | || | |
+----------+ +----------+| +----------+
+----------+
<-------------------------><---------------------------><----------->
Positioning Distribution Use
Figure 3: Location Life Cycle
図3：場所のライフサイクル
Positioning is the process by which the physical location of the Device is computed, based on some observations about the Device's situation in the physical world. (This process goes by several other names, including Location Determination or Sighting.) The input to the positioning process is some information about the Device, and the outcome is that the LG knows the location of the Device.
ポジショニングは、物理的な世界では、デバイスの状況についていくつかの観察に基づいて、デバイスの物理的な位置が計算されるプロセスです。 （このプロセスは、位置決定または照準を含むいくつかの他の名前で行く。）測位処理への入力は、デバイスに関するいくつかの情報であり、結果は、LGは、デバイスの位置を知っていることです。
In this section, we give a brief taxonomy of current positioning systems, their requirements for protocol support, and the privacy and security requirements for positioning.
このセクションでは、現在の測位システム、プロトコルをサポートするための要件、および位置決めのためのプライバシーとセキュリティ要件の簡単な分類を与えます。
While the specific positioning mechanisms that can be applied for a given Device are strongly dependent on the physical situation and capabilities of the Device, these mechanisms generally fall into the three categories described in detail below:
所与のデバイスに適用することができる特定の位置決め機構は、デバイスの物理的状況や能力に強く依存しているが、これらの機構は、一般に、以下に詳細に説明した3つのカテゴリに分類されます。
o Device-based
Oデバイスベース
o Network-based
Oネットワークベース
o Network-assisted
Oネットワーク支援
As suggested by the above names, a positioning scheme can rely on the Device, an Internet-accessible resource (not necessarily a network operator), or a combination of the two. For a given scheme, the nature of this reliance will dictate the protocol mechanisms needed to support it.
上記名称によって示唆されるように、位置決め方式は、デバイス、インターネットアクセス可能なリソース（必ずしもネットワーク事業者）、またはその2つの組合せに依存することができます。与えられたスキームでは、この依存の性質は、それをサポートするために必要なプロトコルメカニズムを決定します。
With Device-based positioning mechanisms, the Device is capable of determining its location by itself. This is the case for a manually entered location or for (unassisted) satellite-based positioning using a Global Navigation Satellite System (GNSS). In these cases, the Device acts as its own LG, and there are no protocols required to support positioning beyond those that transmit the positioning data from the satellite to the user.
デバイスベースの位置決め機構と、デバイスは、それ自体でその位置を決定することができます。これは、手動で入力された位置または全地球的航法衛星システム（GNSS）を使用して（補助なし）衛星ベースの測位の場合です。これらのケースでは、デバイスは、自身のLGとして作用し、そしてユーザに衛星からの測位データを送信するものを越えて位置決めをサポートするために必要な一切のプロトコルは存在しません。
In network-based positioning schemes, an external LG (an Internet host other than the Device) has access to sufficient information about the Device, through out-of-band channels, to establish the position of the Device. The most common examples of this type of LG are entities that have a physical relationship to the Device (such as ISPs). In wired networks, wiremap-based location is a network-based technique; in wireless networks, timing and signal-strength-based techniques that use measurements from base stations are considered to be network-based. Large-scale IP-to-geo databases (for example, those based on WHOIS data or latency measurements) are also considered to be network-based positioning mechanisms.
ネットワークベースの測位方式では、外部LG（装置以外のインターネットホスト）は、デバイスの位置を確立するために、アウトオブバンドチャネルを介して、デバイスに関する十分な情報へのアクセスを有します。 LGのこのタイプの最も一般的な例は、（ISPなど）デバイスへの物理的関係を有するエンティティです。有線ネットワークにおいては、ワイヤーマップベースの位置は、ネットワークベースの技術です。無線ネットワークにおいて、基地局からの測定値を使用してタイミングおよび信号強度に基づく技術は、ネットワークベースであると考えられます。大規模IPツーGEOデータベース（例えば、WHOISデータやレイテンシ測定値に基づくもの）は、ネットワークベースの位置決め機構であると考えられます。
For network-based positioning as for Device-based, no protocols for communication between the Device and the LG are strictly necessary to support positioning, since positioning information is collected outside of the location distribution system (at lower layers of the network stack, for example). This does not rule out the use of other Internet protocols (like the Simple Network Management Protocol (SNMP)) to collect inputs to the positioning process. Rather, since these inputs can only be used by certain LGs to determine location, they are not controlled as private information. Network-based positioning often provides location information to protocols by which the network informs a Device of its own location. These are known as Location Configuration Protocols; see Section 4.2.2 for further discussion.
位置情報は、例えば、ネットワークスタックの下位層に位置分配システム（の外に回収されるので、デバイスベースのようなネットワークベースのポジショニングのために、デバイスとLGとの間の通信のためのプロトコルは、ポジショニングをサポートするために厳密に必要ではありません）。これは、位置決めプロセスへの入力を収集するために（簡易ネットワーク管理プロトコル（SNMP）のような）他のインターネットプロトコルの使用を排除しません。これらの入力のみ位置を決定するために、特定のLGSで使用することができるので、むしろ、それらは個人情報として制御されていません。ネットワークベースのポジショニングは、多くの場合、ネットワークが自身の位置のデバイスを通知することにより、プロトコルに位置情報を提供します。これらは、ロケーションの設定のプロトコルとして知られています。さらなる議論については、セクション4.2.2を参照してください。
Network-assisted systems account for the greatest number and diversity of positioning schemes. In these systems, the work of positioning is divided between the Device and an external LG via some communication (possibly over the Internet), typically in one of two ways:
ネットワーク支援システムは、位置決め制度の最大数と多様性を占めています。これらのシステムでは、位置合わせの作業は、典型的には2つの方法のいずれかで、（おそらくインターネット上で）いくつかの通信を介してデバイスと外部のLGとの間に分割されます。
o The Device provides measurements to the LG, or
Oデバイスは、LGに測定値を提供する、または
o The LG provides assistance data to the Device.
O LGは、デバイスへの支援データを提供します。
"Measurements" are understood to be observations about the Device's environment, ranging from wireless signal strengths to the Media Access Control (MAC) address of a first-hop router. "Assistance" is the complement to measurement, namely the positioning information that enables the computation of location based on measurements. A set of wireless base station locations (or wireless calibration information) would be an assistance datum, as would be a table that maps routers to buildings in a corporate campus.
「測定は、」無線信号強度からの最初のホップルータのMAC（Media Access Control）アドレスに至るまで、デバイスの環境についての所見であると理解されます。 「サポート」は、測定、測定値に基づいて位置の計算を可能にする、すなわち位置情報を補完します。企業キャンパス内の建物にルータをマッピングテーブルであろうように、無線基地局の場所（または無線のキャリブレーション情報）の組は、補助基準であろう。
For example, wireless and wired networks can serve as the basis for network-assisted positioning. In several current 802.11 positioning systems, the Device sends measurements (e.g., MAC addresses and signal strengths) to an LG, and the LG returns a location to the client. In wired networks, the Device can send its MAC address to the LG, which can query the MAC-layer infrastructure to determine the switch and port to which that MAC address is connected, then query a wire map to determine the location at which the wire connected to that port terminates.
例えば、無線および有線ネットワークはネットワークアシスト測位の基礎として役立つことができます。いくつかの現在の802.11測位システムでは、デバイスは、LGに測定（例えば、MACアドレスおよび信号強度）を送信し、そしてLGは、クライアントに位置を返します。有線ネットワークにおいては、MAC層インフラストラクチャを照会することができるLGへのMACアドレスを送信することができるデバイスは、MACアドレスが接続されていることを、次いで位置を決定するために、ワイヤマップを照会するためにどのスイッチポートを決定するためにどの線でそのポートに接続されて終了します。
As an aside, the common phrase "assisted GPS" ("assisted GNSS" more broadly) actually encompasses techniques that transmit both measurements and assistance data. Systems in which the Device provides the LG with GNSS measurements are measurement-based, while those in which the assistance server provides ephemeris or almanac data are assistance-based in the above terminology. (Those familiar with GNSS positioning will note that there are of course cases in which both of these interactions occur within a single location determination protocol, so the categories are not mutually exclusive.)
余談として、一般的な語句「アシストGPS」（より広く「支援GNSS」）は、実際に測定し、支援データの両方を送信する技術を包含する。支援サーバは、エフェメリスまたはアルマナックデータを提供するものは、上記の用語で援助ベースている間、デバイスは、GNSS測定値とLGを提供するシステムは、測定系です。 （GNSS測位に精通した者は、これらの相互作用の両方が、単一の位置判定プロトコル内で発生するので、カテゴリーは相互に排他的ではないれているコースの場合があることに留意されたいです。）
Naturally, the exchange of measurement or positioning data between the Device and the LG requires a protocol over which the information is carried. The structure of this protocol will depend on which of the two patterns a network-assisted scheme follows. Conversely, the structure of the protocol will determine which of the two parties (the Device, the LG, or both) is aware of the Device's location at the end of the protocol interaction.
当然のことながら、デバイスとLGとの間の測定や位置データの交換は、情報が搬送されるプロトコルを必要とします。このプロトコルの構造はネットワークアシスト方式は以下の二つのパターンのどちらに依存するであろう。逆に、プロトコルの構造は、プロトコルインタラクションの終了時にデバイスの位置を認識している両当事者（デバイス、LG、または両方）のどちらかを決定します。
Positioning is the first point at which location may be associated with a particular Device and may be associated with the Target's identity. Local identifiers, unlinked pseudonyms, or private identifiers that are not linked to the real identity of the Target should be used as forms of identity whenever possible. This provides privacy protection by disassociating the location from the Target's identity before it is distributed.
位置決め位置が特定のデバイスに関連付けられてもよく、対象者のアイデンティティと関連付けられてもよいれる最初のポイントです。ターゲットの正体にリンクされていないローカル識別子、リンクされていない偽名、またはプライベート識別子は、可能な限りアイデンティティの形態として使用する必要があります。これは、それが配布される前に、対象者の身元から場所を解離することにより、プライバシーの保護を提供します。
At the conclusion of the positioning process, the entity acting as the LG has the Device's location. If the Device is performing the LG role, then both the Device and LG have it. If the entity acting as the LG also performs the role of LS, the privacy considerations in Section 4.2.4 apply.
位置決めプロセスの終了時に、LGとして動作するエンティティは、デバイスのロケーションに位置しています。デバイスは、LGの役割を実行している場合は、[デバイスとLGの両方がそれを持っています。 LGとして動作するエンティティは、LSの役割を実行した場合は、セクション4.2.4におけるプライバシーの考慮事項が適用されます。
In some deployment scenarios, positioning functions and distribution functions may need to be provided by separate entities, in which case the LG and LS roles will not be performed by the same entity. In this situation, the LG acts as a "dumb", non-privacy-aware positioning resource, and the LS provides the privacy logic necessary to support distribution (possibly with multiple LSes using the same LG). In order to allow the privacy-unaware LG to distribute location information to these LSes while maintaining privacy, the relationship between the LG and its set of LSes MUST be tightly constrained (effectively "hard-wired"). That is, the LG MUST only provide location information to a small fixed set of LSes, and each of these LSes MUST comply with the requirements of Section 4.2.4.
いくつかの展開シナリオでは、位置決め機能及び分布関数は、LGとLSの役割が同じエンティティによって実行されることはありません、その場合、別個のエンティティによって提供される必要があり得ます。この状況で、LGは、「ダム」非プライバシーを意識位置決めリソースとして作用し、LSは、（おそらく同じLGを使用して複数のLSESで）配布をサポートするのに必要なプライバシー・ロジックを提供します。プライバシーを維持しながら、プライバシーを意識しないLGは、これらの小売り供給者に位置情報を配信することを可能にするために、LGと小売り供給者のそのセットとの間の関係は、緊密に（効果的に「ハードワイヤード」）に拘束されなければなりません。つまり、LGのみLSESの小さな固定セットに位置情報を提供しなければなりません、そして、これらの小売り供給者の各々は、セクション4.2.4の要件を遵守しなければなりません。
Manipulation of the positioning process can expose location information through two mechanisms:
測位処理の操作は二つのメカニズムを介して位置情報を公開することができます。
1) A third party could guess or derive measurements about a specific device and use them to get the location of that Device. To mitigate this risk, the LG SHOULD be able to authenticate and authorize devices providing measurements and, if possible, verify that the presented measurements are likely to be the actual physical values measured by that client. These security procedures rely on the type of positioning being done, and may not be technically feasible in all cases.
1）第三者が推測又は導出測定値を特定のデバイスについて、そのデバイスの位置を取得するためにそれらを使用することができます。このリスクを軽減するために、LGは、可能な場合には、提示測定は、そのクライアントによって測定された実際の物理的な値である可能性が高いことを確認し、測定結果を提供するデバイスを認証し、承認することができるとすべきです。これらのセキュリティ手順が行われている位置の種類に依存し、すべての場合には技術的に実現可能ではないかもしれません。
2) By eavesdropping, a third party may be able to obtain measurements sent by the Device itself that indicate the rough position of the Device. To mitigate this risk, protocols used for positioning MUST provide confidentiality and integrity protections in order to prevent observation and modification of transmitted positioning data while en route between the Target and the LG.
2）盗聴することにより、第三者がデバイスの大まかな位置を示す装置自体によって送信された測定値を得ることができるかもしれません。このリスクを軽減するために、位置決めのために使用されるプロトコルは、標的とLGとの間の途中ながら、送信された測位データの観察及び変形を防止するために、機密性と完全性の保護を提供しなければなりません。
If an LG or a Target chooses to act as an LS, it inherits the security requirements for an LS, described in Section 4.2.5.
LGやターゲットがLSとして機能することを選択した場合、それは、4.2.5項で説明した、LSのセキュリティ要件を継承します。
When an entity receives location information (from an LG or an LS) and redistributes it to other entities, it acts as an LS. Location Distribution is the process by which one or more LSes provide LOs to LRs in a privacy-preserving manner.
エンティティは、（LGまたはLSからの）位置情報を受信し、他のエンティティにそれを再配布する場合は、LSとして機能します。場所の配布は、一つ以上のLSESプライバシー保存方法でのLRへのLOを提供するプロセスです。
The role of an LS is thus two-fold: First, it must collect location information and Rules that control access to that information. Rules can be communicated within an LO, within a protocol that carries LOs, or through a separate protocol that carries Rules. Second, the LS must process requests for location information and apply the Rules to these requests in order to determine whether it is authorized to fulfill them by returning location information.
LSの役割は、このように2重である：第一に、それは、位置情報と、その情報へのアクセスを制御するルールを収集する必要があります。ルールロスを運ぶプロトコル内、またはルールを搬送する別のプロトコルを介して、LO内で通信することができます。第二に、LSは、位置情報の要求を処理し、位置情報を返すことによって、それらを満たすために許可されているかどうかを判断するために、これらの要求にルールを適用する必要があります。
An LS thus has at least two types of interactions with other hosts, namely receiving and sending LOs. An LS may optionally implement a third interaction, allowing Rule Makers to provision it with Rules. The distinction between these two cases is important in practice, because it determines whether the LS has a direct relationship with a Rule Maker: An LS that accepts Rules directly from a Rule Maker has such a relationship, while an LS that acquires all its Rules through LOs does not.
LSは、このように、すなわち受信ロスを送信する他のホストとの相互作用の少なくとも2種類があります。 LSは、必要に応じて規則に規定それがルールメーカーができるように、第三の相互作用を実装することができます。介してすべてのルールを取得LSながら、ルールメーカーから直接ルールを受け入れるような関係を持っているLS：それはLSは、ルールメーカーとの直接的な関係を持っているかどうかを決定するため、これら2例の区別は、実際には重要ですLOSがありません。
Privacy Rules are the central mechanism in Geopriv for maintaining a Target's privacy, because they provide a recipient of an LO (an LS or LR) with information on how the LO may be used.
彼らはLOを使用することができる方法に関する情報とLO（LSまたはLR）の受信者を提供するため、プライバシールールは、対象者のプライバシーを維持するためGeoprivにおいて中心的メカニズムです。
Throughout the Geopriv architecture, Privacy Rules are communicated in rules languages with a defined syntax and semantics. For example, the Common Policy rules language has been defined [6] to provide a framework for broad-based rule specifications. Geopriv Policy [7] defines a language for creating location-specific rules. The XML Configuration Access Protocol (XCAP) [8] can be used as a protocol to install rules in both of these formats.
Geoprivアーキテクチャを通じて、個人情報保護規則が定義されている構文とセマンティクスでルール言語で伝達されます。例えば、一般的なポリシールール言語は、[6]ブロードベースのルール仕様のためのフレームワークを提供するために定義されています。 Geoprivポリシー[7]位置固有のルールを作成するための言語を定義します。 XMLコンフィギュレーションアクセスプロトコル（XCAP）[8]これらの形式の両方でルールをインストールするためのプロトコルとして使用することができます。
Privacy Rules follow a default-deny pattern: an empty set of Rules implies that all requests for location information should be denied, except requests made by the Target itself. Each Rule adds to the set, granting a specific permission. Adding a Rule can only augment privacy protections because all Rules are positive grants of permission.
プライバシールールはデフォルト-拒否パターンに従う：ルールの空のセットには、位置情報に対するすべての要求は、ターゲット自体によって行われた要求を除いて、拒否されなければならないことを意味します。各ルールには、特定の許可を与える、セットに追加します。すべてのルールは、許可の正の補助金であるため、ルールを追加するだけで、プライバシーの保護を強化することができます。
The following are examples of Privacy Rules governing location distribution:
場所の分布を支配するプライバシー・ルールの例は次の通りであります：
o Retransmit location information when requested from example.com.
example.comから要求されたときにO位置情報を再送信します。
o Retransmit only city and country.
O唯一の都市と国を再送。
o Retransmit location information with no less than a 100-meter radius of uncertainty.
O不確かさの100メートルの半径よりも小さくないと位置情報を再送信します。
o Retransmit location information only for the next two weeks.
O次の2週間のためにのみ位置情報を再送信します。
LSes enforce Privacy Rules in two ways: by denying requests for location information, or by transforming the location information before retransmitting it.
LSESは、2つの方法で個人情報保護規則を施行：位置情報の要求を拒否することにより、またはそれを再送信する前に、位置情報を変換することによって。
LSes may also receive Rules governing location retention, such as "Retain location only for 48 hours". Such Rules are simply directives about how long the Target's location information can be retained.
LSESはまた、「48時間だけのための場所を保持します」などの位置保持を管理する規則を、受け取ることができます。このようなルールは単純に対象者の位置情報を保持することができますどのくらいの期間についてのディレクティブです。
Privacy Rules can govern the behavior of both LSes and LRs. Rules that direct LSes about how to treat a Target's location information are known as Local Rules. Local Rules are used internally by the LS to handle requests from LRs. They are not distributed to LRs.
プライバシールールはLSESとのLRの両方の動作を管理することができます。対象者の位置情報を扱う方法についての直接LSESはローカルルールとして知られているルール。ローカルルールは、尤度比からの要求を処理するためにLSによって内部的に使用されています。彼らは、言語資源に配布されていません。
Forwarded Rules, on the other hand, travel inside LOs and direct LSes and LRs about how to handle the location information they receive. Because the Rules themselves may reveal potentially sensitive information about the Target, only the minimal subset of Forwarded Rules necessary to handle the LO is distributed.
転送されたルールは、他の一方で、彼らは受信場所の情報を処理する方法についてはLOSと直接LSESとのLRの内側に移動します。ルール自体はターゲットに関する機密情報を明らかにすることができるので、LOを処理するために必要な転送されたルールの最小限のサブセットが分散されています。
An example can illustrate the interaction between Local Rules and Forwarded Rules. Suppose Alice provides the following Local Rules to an LS:
例では、ローカルルールと転送されたルール間の相互作用を説明することができます。アリスはLSに次のローカルルールを提供しているとします。
o The LS may retransmit Alice's precise location to Bob, who in turn is permitted to retain the location information for one month.
O LSは、順番に1ヶ月間の位置情報を保持することが許可され、ボブ、アリスの正確な位置を再送信することができます。
o The LS may retransmit Alice's city, state, and country to Steve, who in turn is permitted to retain the location information for one hour.
O LSは、順番に1時間の位置情報を保持することが許可されたスティーブにアリスの都市、州、国を再送信することができます。
o The LS may retransmit Alice's country to a photo-sharing Web site, which in turn is permitted to retain the location information for one year and retransmit it to any requesters.
O LSは、順番に一年間の位置情報を保持し、任意の要求に応えて、それを再送信することが許可された写真共有Webサイトにアリスの国を再送信することができます。
When Steve asks for Alice's location, the LS can transmit to Steve the limited location information (city, state, and country) along with Forwarded Rules instructing Steve to (a) not further retransmit Alice's location information, and (b) only retain the location information for one hour. By only sending these specifically applicable Forwarded Rules to Steve (as opposed to the full set of Local Rules), the LS is protecting Alice's privacy by not disclosing to Steve that (for example) Alice allows Bob to obtain more precise location information than Alice allows Steve to receive.
スティーブはアリスの位置を要求するとき、LSは、（a）は、アリスの位置情報を再送信しない、及び（B）のみの位置を保持するためにスティーブにスティーブを指示転送されたルールと一緒に限られた位置情報（都市、州、および国）を送信することができます。 1時間の情報。のみスティーブ（ローカルルールのフルセットとは対照的に）これら具体該当転送されたルールを送信することにより、LSは、アリスが可能よりも（例えば）アリスはボブがより正確な位置情報を取得することを可能にすることがスティーブに開示しないことにより、アリスのプライバシーを保護してスティーブは受信します。
Geopriv is designed to be usable even by devices with constrained processing capabilities. To ensure that Forwarded Rules can be processed on constrained devices, LOs are required to carry only a limited set of Forwarded Rules, with an option to reference a more robust set of external Rules. The limited Rule set covers two privacy aspects: how long the Target's location may be retained ("Retention"), and whether or not the Target's location may be retransmitted ("Retransmission"). An LO may contain a pointer to more robust Rules, such as those shown in the set of four Rules at the beginning of this section.
Geoprivをも拘束処理能力を有するデバイスによって使用できるように設計されています。転送されたルールが制約デバイス上で処理することができることを確実にするために、ロスは、外部ルールのより堅牢なセットを参照するためのオプションで、転送されたルールの限られたセットを運ぶために必要とされます。限られたルールセットは、2つのプライバシーの側面をカバー：ターゲットの位置は、（「保存」）を保持し、かつ対象者の場所が（「再送信」）を再送信することができるかどうかをすることができるどのくらい。 LOは、このセクションの冒頭で4つのルールのセットに示されるようなより堅牢なルールへのポインタを含んでいてもよいです。
Some entities performing the LG role are designed only to provide Targets with their own locations, as opposed to distributing a Target's location to others. The process of providing a Target with its own location is known within Geopriv as Location Configuration. The term "Location Information Server" (LIS) is often used to describe the entity that performs this function. However, a LIS may also perform other functions, such as providing a Target's location to other entities.
他人へのターゲットの場所を配布とは対照的に、LGの役割を実行するいくつかのエンティティは、唯一の自分の位置とターゲットを提供するように設計されています。自身の位置をターゲットに提供するプロセスは、ロケーションの設定としてGeopriv内で知られています。用語「位置情報サーバー」（LIS）は、多くの場合、この機能を実行するエンティティを記述するために使用されます。しかしながら、LISはまた、他のエンティティの対象者の位置を提供するように、他の機能を実行することができます。
A Location Configuration Protocol (LCP) [9] is one mechanism that can be used by a Device to discover its own location from a LIS. LCPs provide functions in the way they obtain, transport, and deliver location requests and responses between a LIS and a Device such that the LIS can trust that the location requests and responses handled via the LCP are in fact from/to the Target. Several LCPs have been developed within Geopriv [10] [11] [12] [13].
ロケーション構成プロトコル（LCP）[9] LISから自身の位置を発見するためにデバイスによって使用できる1つのメカニズムです。 LCPは、彼らが得るように機能を提供するトランスポート、およびLISとLISは、LCPを介して処理位置要求および応答は、ターゲットに/から実際にあることを信頼することができるような装置との間の位置要求および応答を提供します。いくつかのLCPはGeopriv内[10] [11] [12] [13]が開発されています。
A LIS whose sole purpose is to perform Location Configuration need only follow a simple privacy-preserving policy: transmit a Target's location only to the Target itself. This is known as the "LCP policy".
唯一のターゲット自体にターゲットの位置を送信する：その唯一の目的LISは、単純なプライバシ保護ポリシーに従う必要がロケーションの設定を実行することです。これは、「LCP政策」として知られています。
Importantly, if an LS is also serving in the role of LG and it has not been provisioned with Privacy Rules for a particular Target, it MUST follow the LCP policy, whether it is a LIS or not. In the positioning phase, an entity serving the roles of both LG and LS that has not received Privacy Rules must follow this policy. The same is true for any LS in the distribution phase.
LSはまた、LGの役割で提供され、それが特定のターゲットのプライバシー規則でプロビジョニングされていない場合に重要なこと、LISであるかどうか、LCPの方針に従わなければなりません。位置決め段階では、個人情報保護のルールを受信していないLGとLSの両方の役割を提供するエンティティは、この方針に従わなければなりません。同じことは、分布相のいずれかのLSにも当てはまります。
The location distribution process occurs through a series of transmissions of LOs: transmissions of location "by value". Location "by value" can be expressed in terms of geodetic location data (latitude, longitude, altitude, etc.) and civic location data (street, city, state, etc.).
位置の送信「の値により」：位置分布処理はロスの伝送の一連を通して起こります。 「値の」位置は測地位置データ（緯度、経度、高度等）、市民の位置データ（通り、市、州、等）で表すことができます。
A location can also be distributed "by reference", where a reference is represented by a URI that can be dereferenced to obtain the LO. This document summarizes the properties of location-by-reference that are discussed at length in [14].
位置はまた、参照がLOを得るために逆参照することができるURIによって表され、「参照によって」分散することができます。この文書は、位置によって参照[14]の長さで議論されているの特性をまとめたものです。
Distribution of location-by-reference (distribution of location URIs) offers several benefits. Location URIs are a more compact way of transmitting location information, since URIs are usually smaller than LOs. A recipient of location information can make multiple requests to a URI over time to receive updated location information if the URI is configured to provide a fresh location rather than a single "snapshot".
場所ごとの参照（場所のURIの分布）の分布は、いくつかの利点を提供しています。 URIのロスよりも通常小さいので、ロケーションURIは、位置情報を送信するよりコンパクトな方法です。位置情報の受信者は、URIが新鮮な場所ではなく、単一の「スナップショット」を提供するように構成されている場合更新された位置情報を受信するために時間をかけてURIに複数の要求を行うことができます。
From a positioning perspective, location-by-reference can offer the additional benefit of "just in time" positioning. If a location is distributed by reference, an entity acting as a combined LG/LS only needs to perform positioning operations when a recipient dereferences a previously distributed URI.
位置決めの観点から、位置ごとの参照は、「ジャストインタイム」の位置決めの付加的な利点を提供することができます。位置は、参照により提供される場合、合成LG / LSとして機能するエンティティは、受信者が以前に分散URIを逆参照するときの位置決め操作を実行する必要があります。
From a privacy perspective, distributing a location as a URI instead of as an LO can help protect privacy by forcing each recipient of the location to request location information from the referenced LS, which can then apply access controls individually to each recipient. But the benefit provided here is contingent on the LS applying access controls. If the LS does not apply an access control policy to requests for a location URI (in other words, if it enforces the "possession model" defined in [14]), then transmitting a location URI presents the same privacy risks as transmitting the LO itself. Moreover, the use of location URIs without access controls can introduce additional privacy risks: If URIs are predictable, an attacker to whom the URI has not been sent may be able to guess the URI and use it to obtain the referenced LO. To mitigate this, location URIs without access controls need to be constructed so that they contain a random component with sufficient entropy to make guessing infeasible.
プライバシーの観点から、URIとして代わりのLOとして位置を分散すること、各受信者に個別にアクセス制御を適用することができ、参照LSから位置情報を要求する位置の各受信者を強制することによってプライバシーを保護することができます。しかし、ここで提供さの利点は、アクセス制御を適用するLS上の偶発的です。 LSは、ロケーションURIの要求にアクセス制御ポリシーを適用しない場合（これは[14]で定義される「所有モデル」を強制言い換えれば、）、次いで位置を送信するURIは、LOを送信するのと同じプライバシーリスクを提示します自体。また、アクセス制御なしの場所のURIを使用することは、付加的なプライバシーリスクを導入することができる：URIは予測可能である場合、URIが送信されていない人の攻撃者は、URIを推測し、参照LOを取得するためにそれを使用することができるかもしれません。これを緩和するために、アクセス制御のない場所のURIは、彼らが実行不可能推測させるのに十分なエントロピーとのランダム成分を含むように構築する必要があります。
Location information MUST be accompanied by Rules throughout the distribution process. Otherwise, a recipient will not know what uses are authorized, and will not be able to use the LO. Consequently, LOs MUST be able to express Rules that convey appropriate authorizations.
位置情報は流通プロセス全体のルールを添付しなければなりません。そうでなければ、受信者は用途が許可されているのか分からないだろう、とLOを使用することはできません。したがって、LOSが適切な権限を伝えるルールを表現できなければなりません。
An LS MUST only accept Rules from authorized Rule Makers. For an LS that receives Rules exclusively in LOs and has no direct relationship with a Rule Maker, this requirement is met by applying the Rules provided in an LO to the distribution of that LO. For an LS with a direct relationship to a Rule Maker, this requirement means that the LS MUST be configurable with an RM authorization policy. An LS SHOULD define a prescribed set of RMs that may provide Rules for a given Target or LO. For example, an LS may only allow the Target to set Rules for itself, or it might allow an RM to set Rules for several Targets (e.g., a parent for children, or a corporate security officer for employees).
LSは、許可ルールのメーカーからルールを受け入れなければなりません。 LOでのみルールを受信し、ルールメーカーとは直接の関係を有していないLSため、この要件は、LOの分布にLOに設けられたルールを適用することによって満たされます。ルールメーカーへの直接的な関係を持つLSの場合、この要件は、LSがRMの承認ポリシーで設定しなければならないことを意味します。 LSは、所与の標的またはLOのためのルールを提供することができるのRMの所定のセットを定義する必要があります。例えば、LSは唯一の目標は、自分自身のためのルールを設定することを可能にする、またはそれはRMは、いくつかの目標（例えば、子供の親、または従業員に対する企業のセキュリティ担当者）のためのルールを設定することができる場合があります。
No matter how Rules are provided to an LS, for each LO it receives, it MUST combine all Rules that apply to the LO into a Rule set that defines which transmissions are authorized, and it MUST transmit location information only in ways that are authorized by these Rules.
どんなにルールをLSに提供される方法、それが受信する各LOのために、それは、送信が許可されている定義するルールセットにLOに適用されるすべてのルールを組み合わせてはならない、そしてそれだけによって認可されている方法で位置情報を送信しなければなりませんこれらのルール。
An LS that receives Rules exclusively through LOs MUST examine the Rules that accompany a given LO in order to determine how the LS may use the LO. If any Rules are included by reference, the LS SHOULD attempt to download them. If the LO includes no Rules that allow the LS to transmit the LO to another entity, then the LS MUST NOT transmit the LO. If the LO contains no Rules at all -- for example, if it is in a format with no Rules syntax -- then the LS MUST delete it. Emergency services provide an exception in that Rules can be implicit; see [15]). If the LO included Rules by reference, but these Rules were not obtained for any reason, the LS MUST NOT transmit the LO and MUST adhere to the provided value in the retention-expires field.
LOを介して排他的にルールを受信LSは、LSは、LOを使用することができる方法を決定するために、与えられたLOを伴うルールを検査しなければなりません。いずれかのルールが参照により含まれている場合は、LSは、それらをダウンロードしようとします。 LOは、LSは、別のエンティティにLOを送信することができないルールが含まれない場合、LSは、LOを送信してはいけません。 LOがまったくルールが含まれていない場合 - それはなしルールの構文と形式の場合、たとえば、 - その後、LSは、それを削除しなければなりません。緊急サービスは、そのルールに例外を暗黙的にすることができ提供します。 [15]）を参照してください。 LOは、参照によってルールが含まれ、これらの規則が何らかの理由で得られなかった場合、LSは、LOを送信してはいけませんと保持-満了するフィールドで与えられた値を遵守しなければなりません。
An LS that receives Rules both directly from one or more Rule Makers and through LOs MUST combine the Rules in a given LO with Rules it has received from the RMs. The strategy the LS uses to combine these sets of Rules is a matter for local policy, depending on the relative priority that the LS grants to each source of Rules. Some example policies are:
直接一つ以上のルールメーカーから、ロスを介して両方のルールを受信LSはそれのRMから受信したルールで指定されたLOのルールを結合する必要があります。 LSは、ルールのこれらのセットを組み合わせるために使用する戦略は、ルールの各ソースにLSグラントその相対優先順位に応じて、ローカルポリシーの問題です。いくつかの例の方針は以下のとおりです。
Union: A transmission of location information is authorized if it is authorized by either a rule in the LO or an RM-provided rule.
組合：それはLOでルールまたはRM-提供ルールのいずれかによって承認された場合に位置情報の送信が許可されています。
Intersection: A transmission of location information is authorized if it is authorized by both a rule in the LO and an RM-provided rule.
交差点：それはLOでルールとRM-設けルールの両方によって許可された場合に位置情報の送信が許可されています。
RM Override: A transmission of location information is authorized if it is authorized by an RM-provided rule, regardless of the LO Rules.
RMオーバーライド：それは関係なく、LOルールの、RM-設けルールによって許可された場合に位置情報の送信が許可されています。
LO Override: A transmission of location information is authorized if it is authorized by an LO-provided rule, regardless of the RM Rules.
LOオーバーライド：それは関係なく、RMルールの、LO-設けられたルールによって許可された場合に位置情報の送信が許可されています。
The default combination policy for an LS that receives multiple rule sets is to combine them according to procedures in Section 10 of RFC 4745 [6]. Privacy rules always grant access; i.e., the default is to deny access, and rules specify conditions under which access is allowed. Thus, when an LS is provided more than one policy document that applies to a given LO, it has been instructed to provide access when any of the rules apply. That is, the "Union" policy is the default policy for an LS with multiple sources of policy. An LS MAY choose to apply a more restrictive policy by ignoring some of the grants of permission in the privacy rules provided. The "Intersection" policy and both "Override" policies listed above are of this latter character.
複数のルールセットを受信LSのデフォルトの組み合わせポリシーは、RFC 4745のセクション10の手順に従って、それらを組み合わせることである[6]。プライバシールールは常にアクセス権を付与します。すなわち、デフォルトでは、アクセスを拒否することであり、アクセスが許可される条件を指定する規則。 LSが与えLOに適用される複数のポリシードキュメントを設けた場合従って、ルールのいずれかが適用されたときにアクセスを提供するように指示されました。それは、「連合」政策は、政策の複数のソースを持つLSのデフォルトポリシーである、です。 LSは、提供プライバシー規則で許可の助成金の一部を無視することによって、より制限の厳しいポリシーを適用することを選択するかもしれません。 「交差点」政策と、上記の両方の「オーバーライド」のポリシーは、この後者の文字です。
Protocols that are used for managing rules should allow an RM to retrieve from the LS the set of rules that will ultimately be applied. For example, in the basic HTTP-based protocol defined in [16], an RM can use a GET request to retrieve the policy being applied by the LS and a PUT request to specify new rules.
ルールを管理するために使用されるプロトコルは、RMはLSから最終的に適用されるルールのセットを取得できるようにする必要があります。例えば、[16]で定義された基本的なHTTPベースのプロトコルでは、RMは、LSと新しいルールを指定するPUT要求によって適用されるポリシーを取得するためのGETリクエストを使用することができます。
Different policies may be applicable in different scenarios. In cases where an external RM is more trusted than the source of the LO, the "RM Override" policy may be suitable (for example, if the external RM is the Target and the LO is provided by a third party). Conversely, the "LO Override" policy is better suited to cases where the LO provider is more trusted than the RM, for example, if the RM is the user of a mobile device LS and the LO contains Rules from the RM's parents or corporate security office. The "Intersection" policy takes the strictest view of the permission grants, giving equal weight to all RMs (including the LO creator).
異なるポリシーが異なるシナリオで適用することができます。 （外部RMが目標であり、LOは、第三者によって提供されている場合、例えば）外部RMはLOのソースよりも信頼されている場合には、「RMオーバーライド」ポリシーが適切であり得ます。逆に、「LOオーバーライド」政策は、RMは、モバイルデバイスのLSの利用者であるとLOは、RMの両親からのルールや企業のセキュリティが含まれている場合、LOプロバイダは、例えば、RMよりも信頼されている場合に適していオフィス。 「交差点」ポリシーが（LO作成者を含む）すべてのRMに等しい重みを与え、許可の付与の厳しいビューを取ります。
Each of these policies will also have different privacy consequences. Following the "Intersection" policy ensures that the most privacy-protective subset of all RMs' rules will be followed. The "Union" policy and both "Override" policies may defy the expectations of any RM (including, potentially, the Target) whose policy is not followed. For example, if a Target acting as an RM sets Rules and those Rules are overridden by the application of a more permissive LO Override policy that has been set by the Target's parent or employer acting as an RM, the retransmission or retention of the Target's data may come as a surprise to the Target. For this reason, it is RECOMMENDED that LSes provide a way for RMs to be able to find out which policy will be applied to the distribution of a given LO.
これらのポリシーのそれぞれは、異なるプライバシー影響を持つことになります。 「交差点」ポリシーに従うことで、すべてのRMのルールのほとんどのプライバシー保護のサブセットが続くされることを保証します。 「連合」政策との両方の「上書き」政策は、政策従わない（潜在的に、を含む、ターゲット）任意のRMの期待を無視することがあります。例えば、RMは、ルールを設定し、これらのルールは、より寛容なLOのアプリケーションによって上書きされているとして動作するターゲットは、ターゲットのデータの再送信または保持をRMとして動作する対象者の親または雇用者によって設定されたポリシーをオーバーライドする場合ターゲットには驚きとして来ることがあります。このため、小売り供給者は、RMSが所与LOの分布に適用されるポリシーを見つけることができるようにするための方法を提供することが推奨されます。
An LS's decisions about how to transmit a location are based on the identities of entities requesting information and other aspects of requests for a location. In order to ensure that these decisions are made properly, the LS needs assurance of the reliability of information on the identities of the entities with which the LS interacts (including LRs, LSes, and RMs) and other information in the request.
場所を送信する方法についてのLSの決定は、情報と場所の要求の他の側面を要求するエンティティのアイデンティティに基づいています。これらの決定が適切に行われていることを確実にするために、LSは（LRS、LSES、とRMを含む）とLSが相互作用エンティティの身元に関する情報やリクエストのその他の情報の信頼性の確保が必要です。
Protocols to convey LOs and protocols to convey Rules MUST provide information on the identity of the recipient of location information and the identity of the RM, respectively. In order to ensure the validity of this information, these protocols MUST allow for mutual authentication of both parties, and MUST provide integrity protection for protocol messages. These security features ensure that the LG has sufficient information (and sufficiently reliable information) to make privacy decisions.
ルールを搬送するLOSとプロトコルを搬送するプロトコルは、それぞれ、位置情報及びRMの同一の受信者のアイデンティティに関する情報を提供しなければなりません。この情報の妥当性を確保するために、これらのプロトコルは、両当事者の相互認証を可能にしなければならない、とプロトコルメッセージの完全性保護を提供しなければなりません。これらのセキュリティ機能は、LGはプライバシーの意思決定を行うために十分な情報（と十分に信頼できる情報を）持っていることを確認してください。
As they travel through the Internet, LOs necessarily pass through a sequence of intermediaries, ranging from layer-2 switches to IP routers to application-layer proxies and gateways. The ability of an LS to protect privacy by making access control decisions is reduced if these intermediaries have access to an LO as it travels between privacy-preserving entities.
彼らはインターネットを通って移動するように、LOSが必ずしもIPルータのレイヤ2スイッチからアプリケーション層プロキシ及びゲートウェイに至るまで、仲介のシーケンスを通過します。それはプライバシーの保存エンティティ間を移動するように、これらの仲介はLOへのアクセス権を持っている場合は、アクセス制御の決定を行うことによって、プライバシーを保護するために、LSの能力が低下しています。
Ideally, LOs SHOULD be transmitted with confidentiality protection end-to-end between an LS that transmits location information and the LR that receives it. In some cases, the protocol conveying an LO provides confidentiality protection as a built-in security solution for its signaling (and potentially its data traffic). In this case, carrying an unprotected LO within such an encrypted channel is sufficient. Many protocols, however, are offering communication modes where messages are either unprotected or protected on a hop-by-hop basis (for example, between intermediaries in a store-and-forward protocol). In such a case, it is RECOMMENDED that the protocol allow for the use of encrypted LOs, or for the transmission of a reference to a location in place of an LO [14].
理想的には、LOSが機密保護エンドツーエンドの位置情報とを受信するLRを送信LSとの間で送信されるべきです。いくつかのケースでは、LO搬送プロトコルは、内蔵のシグナリングのためのセキュリティソリューション（および潜在的にそのデータ・トラフィック）のような機密保護を提供します。この場合、暗号化されたチャネル内に保護されていないLOを搬送するのに十分です。多くのプロトコルは、しかし、メッセージが保護されていない又は（例えば、ストア・アンド・フォワードプロトコルで仲介間）ホップバイホップに基づいて保護されているか、通信モードを提供しています。このような場合には、プロトコルは、暗号化のLOを使用するため、またはLO [14]の代わりに、位置を参照の伝送を可能にすることが推奨されます。
The primary privacy requirement of an LR is to constrain its usage of location information to the set of uses authorized by the Rules in an LO. If an LR only uses an LO in ways that have minimal privacy impact -- specifically, if it does not transmit the LO to any other entity, and does not retain the LO for longer than is required to complete its interaction with the LS -- then no further action is necessary for the LR to comply with Geopriv requirements.
LRの主要プライバシー要件はLOのルールによって認可用途のセットに位置情報のその使用を制限することです。 LRは、最小限のプライバシー影響を与える方法でLOを使用している場合 - 具体的には、それは他のどのエンティティにLOを送信しない、とLSとの相互作用を完了するために必要とされるよりも長くLOを保持していない場合 - LRはGeopriv要件に準拠するために、その後それ以上のアクションは必要ありません。
As an example of this simplest case, if an LR (a) receives a location, (b) immediately provides to the Target information or a service based on the location, (c) does not retain the information, and (d) does not retransmit the location to any other entity, then the LR will comply with any set of Rules that are permissible under Geopriv. Thus, a service that, for example, only provides directions to the closest bookstore in response to an input of a location, and promptly then discards the input location, will be in compliance with any Geopriv Rule set.
この最も簡単な場合の例として、LRは（a）の位置を受信した場合、（b）は、直ちに、対象情報又は位置に基づくサービスを提供する（C）情報を保持しない、および（d）ありません任意の他のエンティティに位置を再送信し、その後、LRはGeopriv下許容されるルールのセットに準拠します。従って、例えば、位置のみの入力に応答して最も近い書店に指示を提供し、速やかに、入力位置を破棄し、サービスは、任意Geoprivルール・セットに準拠するであろう。
LRs that make other uses of an LO (e.g., those that store LOs or send them to other service providers to obtain location-based services) MUST meet the requirements below to assure that these uses are authorized.
LOの他の用途を作るのLRは、これらの使用が許可されていることを保証するために、次の要件を満たさなければならない（例えば、ロスを保存したりするものは、ロケーションベースのサービスを得るために、他のサービスプロバイダに送信します）。
The principal privacy requirement for LRs is to follow usage rules. Any LR that wants to retransmit or retain the LO is REQUIRED to examine the rules included with that LO. Any usage the LR makes of the LO MUST be explicitly authorized by these Rules. Since Rules are positive grants of permission, any action not explicitly authorized is denied by default.
LRのための主要なプライバシーの要件は、使用規則に従うことです。再送またはLOを保持したい任意のLRは、そのLOに含まれているルールを検討する必要があります。 LRは、LOの作る任意の使用は、明示的にこれらの規則によって承認されなければなりません。ルールは、許可の正の補助金であるため、明示的に許可されていない任意のアクションは、デフォルトで拒否されます。
Since the LR role does not involve transmission of location information, there are no protocol security considerations required to support privacy, other than ensuring that data does not leak unintentionally due to security breaches.
LR役割は、位置情報の送信を必要としないので、データが原因セキュリティ侵害に意図せずに漏れないことを確実にすること以外にプライバシーをサポートするために必要ないかなるプロトコルセキュリティ問題は存在しません。
Aside from privacy, LRs often require some assurance that an LO is reliable (assurance of the integrity, authenticity, and validity of an LO), since LRs use LOs in order to deliver location-based services. Threats against this reliability, and corresponding mitigations, are discussed in "Security Considerations" below.
LRは、ロケーションベースのサービスを提供するためにのLOを使用するので、別にプライバシーから、LRのは、多くの場合、LOが信頼性があることを、いくつかの保証（LOの整合性、信頼性、および有効性の保証）が必要です。この信頼性に対する脅威、および対応する緩和策は、以下の「セキュリティに関する考慮事項」で説明されています。
Security considerations related to the privacy of LOs are discussed throughout this document. In this section, we summarize those concerns and consider security risks not related to privacy.
LOのプライバシーに関連するセキュリティ上の考慮事項は、本書で説明されています。このセクションでは、これらの懸念を要約して、プライバシーに関連していないセキュリティリスクを考慮してください。
The life cycle of an LO often consists of a series of location transmissions. Protocols that carry location information can provide strong assurances, but only for a single segment of the LO's life cycle. In particular, a protocol can provide integrity protection and confidentiality for the data exchanged, and mutual authentication of the parties involved in the protocol, by using a secure transport such as IPSec [17] or Transport Layer Security (TLS) [18].
LOのライフサイクルは、多くの場合、位置送信のシリーズで構成されています。位置情報を運ぶプロトコルがのみLOのライフサイクルの単一セグメントのための、強力な保証を提供することができます。特に、プロトコルは、IPSecの[17]またはTLS（Transport Layer Security）[18]などのセキュアトランスポートを使用することにより、プロトコルに関係する当事者の完全性保護と機密データの交換、および相互認証を提供することができます。
Additionally, if (1) the protocol provides mutual authentication for every segment, and (2) every entity in the location distribution chain exchanges information only with entities with whom it has a trust relationship, entities can transitively obtain assurances regarding the origin and ultimate destination of the LO. Of course, direct assurances are always preferred over assurances requiring transitive trust, since they require fewer assumptions.
（1）プロトコルは、それが信頼関係を持っている人のみエンティティと位置分布鎖交換情報に相互各セグメントのための認証、及び（2）すべてのエンティティを提供する場合、さらに、エンティティが推移原点と最終目的地に関する保証を得ることができLOの。彼らは少数の仮定を必要とするので、もちろん、直接の保証は常に、推移的な信頼を必要とする保証よりも優先されます。
Using protocol mechanisms alone, the entities can receive assurances only about a single hop in the distribution chain. For example, suppose that an LR receives location information from an LS over an integrity- and confidentiality-protected channel. The LR knows that the transmitted LO has not been modified or observed en route. However, the assurances provided by the protocol do not guarantee that the transmitted LO was not corrupted before it was sent to the LS (by a previous LS, for example). Likewise, the LR can verify that the LO was transmitted by the LS, but cannot verify the origin of the LO if it did not originate with the LS.
単独プロトコルメカニズムを使用して、エンティティは、流通チェーン内の単一のホップについての保証を受けることができます。例えば、LRは、・インテグリティおよび機密保護チャネルを介してLSから位置情報を受信すると仮定する。 LRは、送信LOが変更または途中で観察されていないことを知ります。しかしながら、プロトコルによって提供される保証は、それが（例えば、前LSにより）LSに送信される前に送信されたLOが壊れなかったことを保証するものではありません。同様に、LRは、LOは、LSによって送信されたことを確認することができますが、それはLSに発信しなかった場合、LOの起源を確認することはできません。
Security mechanisms in protocols are thus unable to provide direct assurances over multiple transmissions of an LO. However, the transmission of a location "by reference" can be used to effectively turn multi-hop paths into single-hop paths. If the multiple transmissions of an LO are replaced by multiple transmissions of a URI (a multi-hop dissemination channel), the LO need only traverse a single hop, namely the dereference transaction between the LR and the dereference server. The requirements for securing a location passed by reference [14] are applicable in this case.
プロトコルのセキュリティメカニズムは、LOの複数の送信を直接保証を提供することができません。しかし、「参照によって」位置の伝送を効果的にシングルホップ経路にマルチホップ経路を有効に使用することができます。 LOの複数の送信がURI（マルチホップ普及チャネル）の複数の送信によって置き換えられる場合、LOはLRと間接参照サーバとの間の単一のホップ、すなわち間接参照トランザクションを横切るだけ必要。参考文献[14]によって渡される場所を確保するための必要条件は、この場合に適用可能です。
The major threats to the security of LOs can be grouped into two categories. First, threats against the integrity and authenticity of LOs can expose entities that rely on LOs. Second, threats against the confidentiality of LOs can allow unauthorized access to location information.
LOのセキュリティに対する主要な脅威は、2つのカテゴリに分類することができます。まず、ロスの整合性と信頼に対する脅威はロスに依存しているエンティティを公開することができます。第二に、ロスの機密性に対する脅威は、位置情報への不正アクセスを許可することができます。
An LO contains four essential types of information: identifiers for the described Target, location information, timestamps, and Rules. By grouping values of these various types together within a single structure, an LO encodes a set of bindings among them. That is, the LO asserts that the identified Target was present at the given location at the given time and that the given Rules express the Target's desired policy at that time for the distribution of his location. Below, we provide a description of the assurances required by each party involved in the location distribution in order to mitigate the possible attacks on these bindings.
説明対象の識別子、ロケーション情報、タイムスタンプ、およびルール：LOは、情報の4つの必須のタイプを含みます。単一構造内で一緒にこれらの様々なタイプの値をグループ化することによって、LOは、それらの間のバインディングのセットを符号化します。すなわち、LOは、識別されたターゲットは所定の時間に所定の位置に存在し、指定されたルールは、彼の位置の分布のために、その時点で対象者の所望のポリシーを発現することを主張します。以下では、これらのバインディング上の攻撃の可能性を軽減するために、位置分布に関係する各当事者が必要な保証の説明を提供します。
Rule Maker: The Rule Maker is responsible for creating the Target's Privacy Rules and for uploading them to the LSes. The primary assurance required by the Rule Maker is that the Target's Privacy Rules are correctly associated with the Target's identity when they are conveyed to each LS that handles the LO. Ensuring the integrity of the Privacy Rules distributed to the LSes prevents rule-tampering attacks. In many circumstances, the privacy policy of the Target may itself be sensitive information; in these cases, the Rule Maker also requires the assurance that the binding between the Target's identity and the Target's Privacy Rules are not deducible by anyone other than an authorized LS.
ルールメーカー：ルールのメーカーは、対象者のプライバシー規則を作成するとLSESにアップロードする責任があります。ルールメーカーによって必要な主な保証は、それらがLOを扱う各LSに搬送される際に対象者のプライバシールールが正しく対象者のアイデンティティに関連付けられていることです。 LSESに配布プライバシールールの整合性を保証することは、ルール・改ざん攻撃を防ぐことができます。多くの状況では、ターゲットのプライバシーポリシーは、それ自体が機密情報であってもよいです。これらのケースでは、ルールメーカーもターゲットのIDと対象者のプライバシールール間の結合が許可LS以外の者によって推論されないという保証が必要です。
Location Server: The Location Server is responsible for enforcing the Target's Privacy Rules. The first assurance required by the LS is that the binding between the Target's Privacy Rules and the Target's identity is authentic. Authenticating and authorizing the Rule Maker who creates, updates, and deletes the Privacy Rules prevents rule-tampering attacks. The LS has to ensure that the authorization policies are not exposed to third parties, if so desired by the Rule Maker and when the rules themselves are privacy-sensitive.
ロケーションサーバ：ロケーションサーバは、対象者のプライバシー規則を施行する責任があります。 LSで必要とされる最初の保証は対象者のプライバシールール間の結合及び対象者の身元が本物であるということです。 、更新情報を作成し、個人情報保護ルールはルール・改ざん攻撃を防ぎ削除ルールメーカーの認証と承認。 LSは、そのルールのメーカーとルール自体がプライバシーに敏感であるときが希望する場合には、認可ポリシーは、第三者に公開されていないことを保証しなければなりません。
Location Recipient: The Location Recipient is the consumer of the LO. The LR thus requires assurances about the authenticity of the bindings between the Target's location, the Target's identity, and the time. Ensuring the authenticity of these bindings helps to prevent various attacks, such as falsifying the location, modifying the timestamp, faking the identity, and replaying LOs.
場所受信者：場所の受信者は、LOの消費者です。 LRは、このようにターゲットの場所、対象者の身元、および時間の間のバインディングの信憑性についての保証を必要とします。これらのバインディングの信頼性を確保することなど、場所を偽造タイムスタンプを変更し、アイデンティティを偽造、ロスを再生するなど、さまざまな攻撃を、防ぐことができます。
Location Generator: The primary assurance required by the Location Generator is that the LS to which the LO is initially published is one that is trusted to enforce the Target's Privacy Rules. Authenticating the trusted LS mitigates the risk of server impersonation attacks. Additionally, the LG is responsible for the location determination process, which is also sensible from a security perspective because wrong input provided by external entities can lead to undesirable disclosure or access to location information.
場所ジェネレータ：場所ジェネレータによって必要とされる主な保証はLOが最初に公開されているために、LSは対象者のプライバシー規則を施行するために、信頼されているものであるということです。信頼されたLSを認証するサーバーの偽装攻撃のリスクを軽減します。また、LGは、外部エンティティによって提供される間違った入力が望ましくない開示又は位置情報へのアクセスをもたらすことができるため、セキュリティの観点から賢明である位置決意プロセスの責任です。
Assurances as to the integrity and confidentiality of a Location Object can be provided directly through the LO format. RFC 4119 [19] provides a description for the usage of Secure/Multipurpose Internet Mail Extensions (S/MIME) to integrity and confidentiality protection. Although such direct, end-to-end assurances are desirable, and these mechanisms should be used whenever possible, there are many deployment scenarios where directly securing an LO is impractical. For example, in some deployment scenarios a direct trust relationship may not exist between the creator of the Location Object and the recipient. Additionally, in a scenario where many recipients are authorized to receive a given LO, the creator of the LO cannot guarantee end-to-end confidentiality without knowing precisely which recipient will receive the LO. Many of these cases can, however, be addressed by the usage of a location-by-reference mechanism, possibly combined with an LO.
Locationオブジェクトの完全性と機密性についての保証は、LO形式で直接提供することができます。 RFC 4119 [19]の完全性と機密性の保護に/セキュア多目的インターネットメール拡張（S / MIME）の使用方法の説明を提供します。そのような直接的、エンド・ツー・エンドの保証が望まれ、そして可能な限り、これらのメカニズムが使用されるべきであるが、直接LOは非現実的である固定多くの展開シナリオがあります。例えば、いくつかの展開シナリオに直接の信頼関係は、Locationオブジェクトの作成者と受信者の間に存在しない場合があります。さらに、多数の受信者が指定したLOを受信することを許可されているシナリオでは、LOの作成者は、受信者がLOを受けるであろう正確に知らなくても、エンドツーエンドの機密性を保証することはできません。これらのケースの多くは、しかし、おそらくLOと組み合わさ位置ごとの基準機構の使用によって対処することができます。
This section contains a set of examples of how the Geopriv architecture can be deployed in practice. These examples are meant to illustrate key points of the architecture, rather than to form an exhaustive set of use cases.
このセクションでは、Geoprivアーキテクチャを実際に展開することができる方法の例のセットが含まれています。これらの実施例は、使用事例の網羅的セットを形成するのではなく、アーキテクチャのキーポイントを示すことを意味します。
For convenience and clarity in these examples, we assume that the Privacy Rules that an LO carries are equivalent to those in a Presence Information Data Format Location Object (PIDF-LO) [19] -- namely, that the principal Rules that can be set are limits on the retransmission and retention of the LO. While these two Rules are the most well-known and important examples, the specific types of Rules an LS or LR must consider will in general depend on the types of LOs it processes.
主要なルールを設定することができること、すなわち、 - これらの実施例に便宜及び明確にするために、我々は、プライバシーLOが担持プレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）[19]のものと同等であることをルールと仮定しますLOの再送と保持に限界があります。これらの二つのルールが最もよく知られており、重要な例ですが、LSやLRを考慮しなければならないルールの具体的な種類は、一般的に、処理するのLOの種類に依存します。
One of the simplest scenarios in the Geopriv architecture is when a Device determines its own location and uses that LO to request a service (e.g., by including the LO in an HTTP POST request [20] or SIP INVITE message [21]), and the server delivers that service immediately (e.g., in a 200 OK response in HTTP or SIP), without retaining or retransmitting the Device's location. The Device acts as an LG by using a Device-based positioning algorithm (e.g., manual entry) and as an LS by interpreting the rule and transmitting the LO. The Target acts as a Rule Maker by specifying that the location should be sent to the server. The server acts as an LR by receiving and using the LO.
デバイスが自身の位置を決定し、LOがサービスを要求することを使用する場合Geoprivアーキテクチャの最も単純なシナリオの一つは、（例えば、HTTP POSTリクエストでLOを含めることによって、[20]またはSIP INVITEメッセージを[21]）、及びサーバは、デバイスの位置を保持または再送信せずに、すぐに（例えば、HTTPまたはSIP 200 OK応答して）、そのサービスを提供しています。デバイスは、デバイスベースの測位アルゴリズム（例えば、手動入力）を使用して、ルールを解釈し、LOを送信することによってLSとしてLGとして作用します。ターゲット場所がサーバに送信されるべきであることを指定することによって、ルールメーカーとして作用します。サーバは、受信及びLOを使用してLRとして作用します。
In this case, the privacy of location information is maintained in two steps: The first step is that the location is only transmitted as directed by the single Rule Maker, namely the Target. The second step is simply the fact that the server, as LR, does not do anything that creates a privacy risk -- it does not retain or retransmit the location. Because the server limits its behavior in this way, it does not need to read the Rules in the LO, even though they were provided -- no Rule would prevent it from using the location in this safe manner.
この場合、位置情報のプライバシーは、2つのステップで維持されている：最初のステップは、単一のルールメーカー、すなわちターゲットの指示に従って位置のみ送信されることです。それが保持するか、または場所を再送しません - 第二段階は、単にサーバは、LRとして、プライバシーのリスクを作成する何もしないという事実です。サーバは、このようにその動作を制限しているので、それは彼らが提供されていても、LOにルールを読む必要はありません - 何のルールは、この安全な方法で場所を使用してからそれを防ぐないだろう。
The following outline summarizes this scenario:
以下の概要では、このシナリオをまとめたものです。
o Positioning: Device-based, Device=LG
位置決めO：デバイスベース、デバイス= LG
o Distribution hop 1: HTTP User Agent (UA) --> Ephemeral Web service, privacy via user indication
O分散ホップ1：HTTPユーザーエージェント（UA） - >エフェメラルWebサービス、プライバシーのユーザ表示を経由して
o Use: Ephemeral Web service delivers response without retaining or retransmitting location
Oの使用：エフェメラルWebサービスが保持または場所を再送信せずにレスポンスを実現します
o Key point:
Oキーポイント：
* LRs that do not behave in ways that risk privacy are Geopriv-compliant by default. No further action is necessary.
*プライバシーを危険な方法で行動しないのLRは、デフォルトではGeoprivに準拠しています。これ以上の操作は必要ありません。
Many location-based services are delivered over the Web, using Javascript code to orchestrate a series of HTTP requests for location-specific information. To support these applications, browser extensions have been developed that support Device-based positioning (manual entry and Global Positioning System (GPS)) and network-assisted positioning (via Assisted GPS (AGPS), and multilateration with 802.11 and cellular signals), exposing a location to Web pages through Javascript APIs.
多くのロケーションベースのサービスは、場所固有の情報については、HTTPリクエストのシリーズを編成するためにJavaScriptコードを使用して、Web上で配信されます。これらのアプリケーションをサポートするために、ブラウザ拡張機能が開発されている（802.11及びセルラ信号にアシストGPS（AGPSを介して）、及びマルチラテ）支持装置ベースのポジショニング（手動入力及び全地球測位システム（GPS））とネットワーク支援ポジショニング、露光JavascriptのAPIを介してWebページへの場所。
In this scenario, we consider a Target that uses a browser with a network-assisted positioning extension. When the Target uses this browser to request location-based services from a Web page, the browser prompts the user to grant the page permission to access the user's location. If the user grants permission, the browser extension sends 802.11 signal strength measurements to a positioning server, which then returns the position of the host. The extension constructs an LO with this location and Rules set by the user, then passes the LO to the page through its Javascript API. The page then obtains location-relevant information using an XMLHttpRequest [22] to a server in the same domain as the page and renders this information to the user.
このシナリオでは、ネットワークに支援される測位拡張子を持つブラウザを使用してターゲットを検討します。ターゲットは、Webページからのロケーションベースのサービスを要求するために、このブラウザを使用すると、ブラウザがユーザーの位置にアクセスするためのページ権限を付与するようにユーザに要求します。ユーザが許可を与える場合は、ブラウザ拡張機能は、ホストの位置を返し、測位サーバ、802.11信号強度測定値を送信します。拡張は、その後、この場所及びユーザによって設定されたルールとLOを構築し、そのJavascriptのAPIを介してページにLOを渡します。ページは、そのページと同じドメイン内のサーバにXMLHttpRequestの[22]を用いて位置関連情報を取得し、この情報をユーザにレンダリングします。
At first blush, this scenario seems much more complicated than the minimal scenario above. However, most of the privacy considerations are actually the same.
一見、このシナリオは、はるかに複雑上記最小限のシナリオよりも思えます。しかし、プライバシーの考慮事項のほとんどは、実際には同じです。
The positioning phase in this scenario begins when the browser extension contacts the positioning server. The positioning server acts as an LG.
このシナリオでは、位置決め相は、ときに、ブラウザの拡張機能に接触測位サーバを開始します。測位サーバは、LGとして機能します。
The distribution phase actually occurs entirely within the Target host. This phase begins when the positioning server, now acting as an LS, follows the LCP policy by providing the location only to the Target. The next hop in distribution occurs when the browser extension (an entity under the control of the Target) passes an LO to the Web page (an entity under the control of its author). In this phase, the browser extension acts as an LS, with the Target as the sole Rule Maker; the user interface for rule-making is effectively a protocol for conveying Rules, and the extension's API effectively defines a way to communicate LOs and an LO format. The Web site acts as an LR when the Web page accepts the LO.
分布相は、実際に対象ホスト内に完全に起こります。測位サーバは、今LSとして動作する、唯一のターゲットに場所を提供することにより、LCPの方針を、以下の場合に、このフェーズが開始されます。ブラウザ拡張機能（対象の制御下のエンティティ）は、Webページ（その作者の制御下のエンティティ）にLOを通過する際に分布の次のホップが生じます。このフェーズでは、ブラウザの拡張機能は、唯一のルールメーカーとしてターゲットに、LSとして機能します。ルール作りのためのユーザインタフェースを効果的ルールを搬送するためのプロトコルであり、拡張機能のAPIを効果的にLOSとLO形式を通信する方法を定義します。 WebページがLOを受け入れたときに、Webサイトは、LRとして機能します。
The use phase encompasses the Web site's use of the LO. In this context, the phrase "Web site" encompasses not only the Web page, but also the dedicated supporting logic behind it. Considering the entire Web site as a recipient, rather than a single page, it becomes clear that sending the LO in an XMLHttpRequest to a back-end server is like passing it to a separate component of the LR, as opposed to retransmitting it to another entity. Thus, even in this case, where location-relevant information is obtained from a back-end server, the LR does not retain or retransmit the location, so its behavior is "privacy-safe" -- it doesn't need to interpret the Rules in the LO.
使用段階は、LOのWebサイトの使用を包含する。この文脈では、語句「Webサイトには、」Webページだけでなく、その背後にある専用サポートロジックだけでなく、を含みます。受信者としてのWebサイト全体ではなく、単一のページを考慮すると、バックエンドサーバへのXMLHttpRequestでLOを送信する他にそれを再送信とは対照的に、LRの別個のコンポーネントに渡すようなものであることが明らかとなりますエンティティ。したがって、でも場所関連情報は、バックエンドサーバーから取得され、この場合、には、LRは保持または場所を再送信するので、その動作は「プライバシー・安全」ではありません - それは解釈する必要はありません。 LOでのルール。
However, consider a variation on this scenario where the Web page requests additional information (a map, for instance) from a third-party site. In this case, since location information is being transmitted to a third party, the Web site (either in the Web page or in a back-end server) would need to verify that this transmission is allowed by the LO's Privacy Rules. Similarly, if the site wanted to log the user's location information, then it would need to examine the LO to determine how long this information can be retained. In such a case, if the LR needs to do something that is not allowed by the Rules, it may have to deny service to the user, while hopefully providing a message with the reason. Nonetheless, if the Rules permit retention or retransmission, even if this retransmission is limited by access control rules, then the LR may do so to the extent the Rules allow.
Webページは、サードパーティのサイトから（例えば、マップ）の追加情報を要求したところただし、このシナリオのバリエーションを検討してください。位置情報が第三者に送信されているので、この場合は、Webサイトには、（Webページまたはバックエンドサーバーのいずれかで）、この送信はLOのプライバシー規則によって許可されていることを確認する必要があります。サイトは、ユーザーの位置情報を記録したい場合は同様に、それは、この情報を保持することができますどのくらいかを決定するためにLOを検討する必要があります。 LRは、ルールで許可されていない何かをする必要がある場合、そのような場合には、それがうまくいけば理由でメッセージを提供しながら、利用者へのサービスを拒否することがあります。ルールが保持または再送信を許可する場合はそれにもかかわらず、この再送信は、アクセス制御規則によって制限されている場合でも、その後、LRはルールが許す範囲でそのようにすることができます。
The following outline summarizes this scenario:
以下の概要では、このシナリオをまとめたものです。
o Positioning: Network-assisted, positioning server=LG
Oポジショニング：ネットワーク支援、測位サーバ= LG
o Rule installation: RM (=Target) gives permission to sites and sets LO Rules
Oルールのインストール：RM（=目標）は、サイトに許可を与え、LOのルールを設定し、
o Distribution hop 1: positioning server=LS --> Target, privacy via LCP policy
O分散ホップ1：測位サーバ=のLS - >ターゲット、LCPポリシー経由プライバシー
o Distribution hop 2: Browser=LS --> Web site=LR, privacy via user confirmation
O分散ホップ2：ブラウザの=のLS - >ウェブサイト= LR、ユーザー確認を経由して、プライバシー
o Use: Back-end server delivers location-relevant information without further retransmission, then deletes location; privacy via safe behavior
Oの使用：バックエンドサーバーは場所を削除し、その後、さらに再送信することなく、位置関連情報を配信します。安全な行動を経由して、プライバシー
o Key points:
Oキーポイント：
* Privacy in this scenario is provided by a combination of explicit user direction and Rules in an LO.
*このシナリオではプライバシーは、明示的なユーザの方向とLOのルールの組み合わせによって提供されます。
* Distribution can occur within a host, between components that do not trust each other.
*ディストリビューションは、お互いを信頼していないコンポーネント間で、ホスト内で発生することができます。
* Some transmissions of the location are actually internal to an LR.
*場所のいくつかの送信は、実際にLRの内部にあります。
* LRs that do things that might be constrained by Rules need to verify that these actions are allowed for a particular LO.
*規則によって制約される可能性がありますことを行うのLRは、これらのアクションは、特定のLOに許可されていることを確認する必要があります。
Support for emergency calls by Voice-over-IP devices is a critical use case for location information about Internet hosts. The details of the Internet architecture for emergency calling are described in [23] [24]. In this architecture, there are three critical steps in the placement of an emergency call, each involving location information:
ボイスオーバーIPデバイスによる緊急コールのサポートは、インターネットホストの位置情報のための重要なユースケースです。緊急通話のためのインターネットアーキテクチャの詳細は[23] [24]で説明されています。このアーキテクチャでは、緊急コール、各関係する位置情報の配置における3つの重要なステップがあります：
2. Determine the proper Public Safety Answering Point (PSAP) for the caller's location.
2.発信者の場所のポイント（PSAP）に答える適切な公共安全を確認します。
3. Send a SIP INVITE message, including the caller's location, to the PSAP.
3. PSAPに、発信者の位置を含むメッセージを、SIP INVITEを送ります。
The first step in an emergency call is to determine the location of the caller. This step is the positioning phase of the location life cycle. The location is determined by whatever means are available to the caller's device, or to the network, if this step is being done by a proxy. The entity doing the positioning, whether the caller or a proxy, acts as an LS, preserving the privacy of location information by only including it in emergency calls.
緊急呼の最初のステップは、発信者の位置を決定することです。このステップは、位置ライフサイクルの位置決め相です。場所は、どのような手段によって決定され、このステップは、プロキシによって行われている場合、発信者のデバイスに、またはネットワークに利用可能です。ポジショニングを行うエンティティは、発信者またはプロキシかどうか、だけで緊急通話に含めて位置情報のプライバシーを保護、LSとして機能します。
The second step in an emergency call encompasses location distribution and use. The entity that is routing the emergency call sends location information through the Location-to-Service Translation (LoST) Protocol [15] to a mapping server. In this role, the routing entity acts as an LS and the LoST server acts as an LR. The LO format within LoST does not allow Rules to be sent along with the location, but because LoST is an application-specific protocol, the sending of the location within a LoST message authorizes the LoST server to use the location to complete the protocol, namely to route the message as necessary through the LoST mapping architecture [25]. That is, the LoST server is authorized to complete the LoST protocol, but to do nothing else.
緊急呼の第2のステップは、位置分布および使用を包含する。緊急呼をルーティングしているエンティティは、マッピング・サーバにロケーション・ツー・サービス翻訳（LOST）プロトコル[15]を介して位置情報を送信します。この役割では、ルーティング・エンティティは、LSとLRとして失わサーバ作用として働きます。失われた内LO形式、すなわち、失われたサーバープロトコルを完了するために位置を使用する許可規則が位置とともに送信されることを可能にするが、失われたアプリケーション固有のプロトコルであるので、失われたメッセージ内の位置を送信しませんルートのために失わマッピング・アーキテクチャを介して必要に応じてメッセージ[25]。それは、失われたサーバーは、失われたプロトコルを完了するために、それ以外何もしないように許可されています。
The third step in an emergency call is again a combination of distribution and use. The caller, or another entity that inserts the caller's location, acts as an LS, and the PSAP acts as an LR. In this specific example, the caller's location is transmitted either as a PIDF-LO or as a reference that returns a PIDF-LO, or both; in the latter case, the reference should be appropriately protected so that only the PSAP has access. In any case, the receipt of an LO implies that the PSAP should obey the Rules in those LOs in order to preserve privacy. Depending on the regulatory environment, the PSAP may have the option to ignore those constraints in order to respond to an emergency, or it may be bound to respect these Rules in spite of the emergency situation.
緊急呼における第3のステップは、再び配布及び使用の組み合わせです。発信者、または発呼者の場所を挿入する別のエンティティは、LS、及びLRとしてPSAP作用として働きます。この具体例では、発信者の位置は、PIDF-LOとして、またはPIDF-LO、または両方を返す参照のいずれかと伝達されます。唯一PSAPがアクセスを有するように、後者の場合には、参照が適切に保護されなければなりません。いずれの場合においても、LOの受信は、PSAPがプライバシーを維持するために、これらのLOのルールに従わなければならないことを意味します。規制環境によっては、PSAPは、緊急事態に対応するために、これらの制約を無視するオプションを有していてもよく、または緊急事態にもかかわらず、これらのルールを尊重するために結合させることができます。
The following outline summarizes this scenario:
以下の概要では、このシナリオをまとめたものです。
o Positioning: Any
Oのポジショニング：任意
o Distribution/use hop 1: Target=LS --> LoST infrastructure (no Rules), privacy via authorization implicit in protocol
O配布/使用ホップ1：ターゲット= LS - >失われたインフラ（NOルール）、プロトコルにおける暗黙の承認を介してプライバシ
o Distribution/use hop 2: Target=LS --> PSAP, privacy via Rules in LO
O配布/使用ホップ2：ターゲット=のLS - > PSAP、LOのルールを介してプライバシ
o Use: PSAP uses location to deliver emergency services
Oを使用しますPSAPは、緊急サービスを提供する場所を使用しています
o Key points:
Oキーポイント：
* Privacy in this scenario is provided by a combination of explicit user direction, implicit authorization particular to a protocol, and Rules in an LO.
*このシナリオではプライバシーは、明示的なユーザの方向、プロトコルに特定の暗黙の承認、およびLOのルールの組み合わせによって提供されます。
* LRs may be constrained to respect or ignore Privacy Rules by local regulation.
*のLRは、ローカル規制によってプライバシールールを尊重するか、無視するように制約されてもよいです。
In modern Internet applications, users frequently receive information via one channel and broadcast it via another. In this sense, both users and channels (e.g., Web services) become LSes. Here we consider a more complex example that illustrates this pattern across multiple logical hops.
現代のインターネットアプリケーションでは、ユーザーが頻繁に1つのチャネルを介して情報を受信し、別のを経由して、それを放送しています。この意味で、両方のユーザおよびチャネル（例えば、ウェブサービス）がLSESなります。ここでは、複数の論理ホップ全体でこのパターンを示し、より複雑な例を考えてみましょう。
Suppose Alice as the Target subscribes to a wireless ISP that determines her location using a network-based positioning technique, e.g., via the location of the base station serving the Target, and provides that information directly to a location-enhanced presence provider. This presence provider might use SIP, the Extensible Messaging and Presence Protocol (XMPP) [26], or another protocol). The location-enhanced presence provider allows Alice to specify Rules for how this location is distributed: which friends should receive Alice's location and what Rules they should get with it. Alice uses a few other location-enhanced services as well, so she sends Rules that allow her location to be shared with those services, and that allow those services to retain and retransmit her location.
ターゲットは、ターゲットのサービング基地局の位置を介して、例えば、ネットワークベースの測位技術を使用して彼女の位置を決定する無線ISPに加入し、そして位置増強プレゼンスプロバイダに直接その情報を提供するように、アリスと仮定する。このプレゼンスプロバイダ）はSIP、拡張可能なメッセージングおよびプレゼンスプロトコル（XMPP）[26]、または別のプロトコルを使用するかもしれません。友人がアリスの場所とどのような彼らはそれを取得する必要がありますルールを受け取る必要があります。場所が強化されたプレゼンスプロバイダは、アリスは、この場所がどのように分配されるかのルールを指定することができます。アリスは、同様に他のいくつかの場所が強化されたサービスを使用していますので、彼女は彼女の場所がそれらのサービスと共有することを可能にするルールを送信し、それはそれらのサービスが彼女の場所を保持して再送信することができます。
Bob is one of Alice's friends, and he receives her location via this location-enhanced presence service. Noting that she's at their favorite coffee shop, Bob wants to upload a photo of the two of them at the coffee shop to a photo-sharing site, along with an LO that marks the location. Bob checks the Rules in Alice's LO and verifies that the photo-sharing site is one of the services that Alice authorized. Seeing that Alice has authorized him to give the LO to the photo-sharing site, he attaches it to the photo and uploads it.
ボブはアリスの友人の一人で、彼はこの場所が強化されたプレゼンスサービスを介して自分の位置を受け取ります。彼女は自分の好きなコーヒーショップでだということに留意し、ボブは場所をマークLOとともに、写真共有サイトへのコーヒーショップでそれらの2の写真をアップロードしたいと考えています。ボブはアリスのLOでのルールをチェックし、写真共有サイトはアリスが認可サービスの一つであることを確認します。アリスは、写真共有サイトにLOを与えるために彼を許可していることを見て、彼は写真とアップロード、それにそれを添付します。
Once the geo-tagged photo is uploaded, the photo-sharing site reads the Rules in the LO and verifies that the site is authorized to store the photo and to share it with others. Since Alice has allowed the site to retransmit and retain without any constraints, the site fulfills Bob's request to make the geo-tagged photo publicly accessible.
地理タグ付けされた写真がアップロードされると、写真共有サイトでは、LOでルールを読み取り、サイトが写真を保存し、他のユーザーと共有することが許可されていることを確認します。アリスはサイトが制約なしに再送信し、維持することができましたので、サイトには、地理タグ付けされた写真が公にアクセスできるようにするボブの要求を満たしています。
Eve, another user of the photo-sharing site, downloads the photo of Alice and Bob at the coffee shop and receives Alice's LO along with it. Eve posts the photo and location to her public page on a social networking site without checking the Rules, even though the LO doesn't allow Eve to send the location anywhere else. The social networking site, however, observes that no retransmission or retention are allowed, both of which it needs for a public posting, and rejects the upload.
イブ、写真共有サイトの他のユーザは、コーヒーショップで、アリスとボブの写真をダウンロードし、それに伴いアリスのLOを受けます。イブはLOはイブはどこか他の場所を送信することはできませんが、ルールを確認することなく、ソーシャルネットワーキングサイト上で彼女の公開ページに写真と場所をポストします。ソーシャルネットワーキングサイトは、しかし、それは公共の投稿のために必要どちらも、再送または保持が許可されていないことを観察し、アップロードを拒否します。
In terms of the location life cycle, this scenario consists of a positioning step, followed by four distribution hops and use. Positioning is the simplest step: An LG in Alice's ISP monitors her location and transmits it to the presence service, maintaining privacy by only transmitting the location information to a single entity to which Alice has delegated privacy responsibilities.
位置のライフサイクルの観点から、このシナリオでは、4つの分配ホップ及び使用続い位置決め工程、から成ります。位置決めは、最も単純なステップである：アリスのISPでLGは、彼女の位置を監視し、のみアリスはプライバシーの責任を委任しているために単一のエンティティへ位置情報を送信することにより、プライバシーを維持し、プレゼンスサービスに送信します。
The first distribution hop occurs when the presence server sends the location to Bob. In this transaction, the presence server acts as an LS, Alice acts as an RM, and Bob acts as an LR. The privacy of this transaction is assured by the fact that Alice has installed Rules on the presence server that dictate who it may allow to access her location. The second distribution hop is when Bob uploads the LO to the photo-sharing site. Here Bob acts as an LS, preserving the privacy of location information by verifying that the Rules in the LO allow him to upload it. The third distribution hop is when the photo-sharing site sends the LO to Eve, likewise following the Rules -- but a different set of Rules than for Bob, since an LO can specify different Rule sets for different LSes.
プレゼンスサーバは、ボブに位置を送信するときに最初の分布ホップが発生します。この取引では、LSとしてプレゼンスサーバ行為は、アリスはRMとして機能し、ボブはLRとして機能します。この取引のプライバシーはアリスはそれが彼女の場所にアクセスすることを可能にする人口述プレゼンス・サーバ上のルールをインストールしているという事実によって保証されています。ボブは写真共有サイトにLOをアップロードするときに、第2の分布ホップです。ここでボブはLOでのルールは、彼にそれをアップロードできるようにすることを確認することによって位置情報のプライバシーを保護、LSとして機能します。 LOは、異なる小売り供給者のための異なるルールセットを指定することができるので、しかし、ボブのためのより規則の異なるセット - 写真共有サイトは、同様に規則に従って、イブにLOを送信するときに第三の分布ホップです。
Eve is the fourth LS in the chain, and fails to comply with Geopriv by not checking the Rules in the LO prior to uploading the LO to the social networking site. The site, however, is a responsible LR -- it checks the Rules in the LO, sees that they don't allow it to use the location as it needs to, and discards the LO.
イヴは、チェーン内の第四LSで、前のソーシャルネットワーキングサイトにLOをアップロードするにはLOでのルールをチェックしないことにより、Geoprivを遵守していません。サイトは、しかし、責任LRである - それはLOでルールをチェックし、彼らはそれが必要として、それは場所を使用することを許可しないことを見て、LOを破棄します。
The following outline summarizes this scenario:
以下の概要では、このシナリオをまとめたものです。
o Positioning: Network-based, LG in network, privacy via exclusive relationship with presence service
Oポジショニング：ネットワークにおけるネットワークベース、LG、プレゼンスサービスとの排他的な関係を経由して、プライバシー
o Distribution/use hop 1: Presence server --> Bob, privacy via Alice's access control rules
アリスのアクセス制御ルールを経て>ボブ、プライバシ - Presenceサーバ：O分散/ホップ1を使用します
o Distribution/use hop 2: Bob --> photo-sharing site, privacy via Rules for Bob in LO
O配布/利用ホップ2：ボブ - >写真共有サイト、LOでボブのルールを経由して、プライバシー
o Distribution/use hop 3: Photo-sharing site --> Eve, privacy via Rules for site in LO
LOで、サイトのルールを介した>イブ、プライバシ - 写真共有サイト：O分散/利用ホップ3
o Distribution/use hop 4: Eve --> Social networking site, violates privacy by retransmitting
O配布/使用のホップ4：イブ - >ソーシャルネットワーキングサイトでは、再送信することによってプライバシーを侵害します
o Use: Social networking site, privacy via checking Rules and discarding
Oの使用：ソーシャルネットワーキングサイト、ルールをチェックし、廃棄経由プライバシー
o Key points:
Oキーポイント：
* Privacy can be preserved through multiple hops.
*プライバシーは複数のホップを通じて保存することができます。
* An LO can specify different Rules for different entities.
* LOは異なるエンティティごとに異なるルールを指定することができます。
* An LS can still disobey the Rules, but even then, the architecture still works in some cases.
* LSはまだルールに背くことができますが、その後も、アーキテクチャは、まだいくつかのケースで動作します。
Various security-related terms not defined here are to be understood in the sense defined in RFC 4949 [27].
ここで定義されていない様々なセキュリティ関連の用語は、RFC 4949 [27]で定義された意味で理解されるべきです。
$ Access Control Rule
$アクセス制御ルール
A rule that describes which entities may receive location information and in what form.
位置情報を受信し、どのような形態で得るエンティティ説明ルール。
$ civic location
$市民の場所
The geographic position of an entity in terms of a postal address or civic landmark. Examples of such data are room number, street number, street name, city, postal code, county, state, and country.
住所や市民のランドマークの点では、エンティティの地理的な位置。このようなデータの例には、部屋番号、街路番号、通りの名前、都市、郵便番号、郡、州、および国です。
$ Device
$デバイス
The physical device, such as a mobile phone, PC, or embedded micro-controller, whose location is tracked as a proxy for the location of a Target.
物理デバイス、例えばその位置が標的の位置のためのプロキシとして追跡され、携帯電話、PC、または組み込みマイクロコントローラ、など。
$ geodetic location
$測地場所
The geographic position of an entity in a particular coordinate system, for example, a latitude-longitude pair.
具体的にはエンティティの地理的位置は、例えば、緯度・経度のペアを座標系。
$ Local Rule
$ローカルルール
A Privacy Rule that directs a Location Server about how to treat a Target's location information. Local Rules are used internally by a Location Server to handle requests from Location Recipients. They are not distributed to Location Recipients.
対象者の位置情報を扱う方法についてのロケーションサーバに指示プライバシールール。ローカルルールは、場所の受信者からの要求を処理するためにロケーションサーバによって内部的に使用されています。彼らは場所の受信者に配布されていません。
$ Location Generator (LG)
$場所ジェネレーター（LG）
Performs the role of initially determining or gathering the location of a Target. Location Generators may be any sort of software or hardware used to obtain a Target's location. Examples include GPS chips and cellular networks.
最初に決定または標的の位置を収集する役割を行います。場所ジェネレータは、ターゲットの位置を取得するために使用されるソフトウェアまたはハードウェアの任意の並べ替えかもしれません。例としては、GPSチップとセルラーネットワークを含みます。
$ Location Information Server (LIS)
$場所情報サーバー（LIS）
An entity responsible for providing devices within an access network with information about their own locations. A Location Information Server uses knowledge of the access network and its physical topology to generate and distribute location information to devices.
自分の場所についての情報をアクセスネットワーク内のデバイスを提供する責任を負うエンティティ。場所情報サーバーは、デバイスに位置情報を生成して配布するために、アクセスネットワークとその物理的なトポロジーの知識を使用しています。
$ Location Object (LO)
$場所オブジェクト（LO）
A data unit that conveys location information together with Privacy Rules within the Geopriv architecture. A Location Object may convey geodetic location data (latitude, longitude, altitude), civic location data (street, city, state, etc.), or both.
Geoprivアーキテクチャ内プライバシールールと一緒に位置情報を伝えるデータユニット。 Locationオブジェクトは測地位置データ（緯度、経度、高度）、市民の位置データ（通り、市、州、等）、または両方を伝えることができます。
$ Location Recipient (LR)
$場所受信者（LR）
An ultimate end-point entity to which a Location Object is distributed. Location Recipients request location information about a particular Target from a Location Server. If allowed by the appropriate Privacy Rules, a Location Recipient will receive Location Objects describing the Target's location from the Location Server.
ロケーション・オブジェクトが分散された最終的なエンドポイントエンティティ。場所受信者は、ロケーションサーバから特定のターゲットの位置情報を要求します。適切なプライバシールールで許可されている場合は、場所の受信者は、ロケーションサーバからの標的の位置を記述する場所オブジェクトを受け取ります。
$ Location Server (LS)
$のロケーションサーバ（LS）
An entity that receives Location Objects from Location Generators, Privacy Rules from Rule Makers, and location requests from Location Recipients. A Location Server applies the appropriate Privacy Rules to a Location Object received from a Location Generator and may disclose the Location Object, in compliance with the Rules, to Location Recipients.
場所ジェネレータ、ルールメーカーからのプライバシー規則、および場所の受信者からのロケーション要求からロケーションオブジェクトを受信するエンティティ。ロケーションサーバは、場所の受信者に、ルールを遵守して、場所ジェネレータから受け取ったロケーションオブジェクトに適切な個人情報保護のルールを適用し、Locationオブジェクトを開示することがあります。
Location Servers may not necessarily be "servers" in the colloquial sense of hosts in remote data centers servicing requests. Rather, a Location Server can be any software or hardware component that receives and distributes location information. Examples include a positioning server (with a location interface) in an access network, a presence server, or a Web browser or other software running on a Target's device.
ロケーションサーバは、必ずしも要求にサービスを提供し、リモートデータセンターでホストの口語意味での「サーバー」ではないかもしれません。むしろ、ロケーションサーバは、受信した位置情報を配信する任意のソフトウェアまたはハードウェアコンポーネントとすることができます。例としては、対象者のデバイス上のアクセスネットワークにおける（位置・インターフェースを有する）測位サーバ、プレゼンスサーバ、またはWebブラウザまたは他のソフトウェアの実行を含みます。
$ Privacy Rule
$プライバシールール
A directive that regulates an entity's activities with respect to a Target's location information, including the collection, use, disclosure, and retention of the location information. Privacy Rules describe how location information may be used by an entity, the level of detail with which location information may be described to an entity, and the conditions under which location information may be disclosed to an entity. Privacy Rules are communicated from Rule Makers to Location Servers and conveyed in Location Objects throughout the Geopriv architecture.
収集、使用、開示、および位置情報の保持など、対象者の位置情報、に関して、企業の活動を規制する指令。プライバシールールは、位置情報は、エンティティによって使用されてもよい、詳細レベルの情報がエンティティに説明することができる場所で、位置情報は、エンティティに公開することができる条件の下でその方法について説明します。プライバシールールは、ロケーションサーバにルールメーカーから通信とGeoprivアーキテクチャ全体ロケーションオブジェクトに搬送されます。
$ Rule
$ルール
See Privacy Rule.
プライバシー規則を参照してください。
$ Rule Maker (RM)
$ルールメーカー（RM）
An individual or entity that is authorized to set Privacy Rules for a Target. In some cases, a Rule Maker and a Target will be the same individual or entity, and in other cases they will be separate. For example, a parent may serve as the Rule Maker when the Target is his child. The Rule Maker is also not necessarily the owner of a Target device. For example, a corporation may own a device that it provides to an employee but permit the employee to serve as the Rule Maker and set her own Privacy Rules. Rule Makers provide the Privacy Rules associated with a Target to Location Servers.
ターゲットのプライバシー規則を設定することが許可された個人またはエンティティ。いくつかのケースでは、ルールメーカーとターゲットは、同じ個人または団体となり、それ以外の場合には、それらは別々になります。ターゲットは彼の子であるとき例えば、親がルールメーカーとしての役割を果たすことができます。ルールのメーカーは必ずしもまた、ターゲットデバイスの所有者ではありません。例えば、企業は、それが従業員に提供するデバイスを所有しているが、ルールメーカーとして機能し、彼女自身の個人情報保護のルールを設定し、従業員を許可することができます。ルールのメーカーは、ロケーションサーバへのターゲットに関連付けられている個人情報保護規則を提供します。
$ Forwarded Rule
$転送されたルール
A Privacy Rule that travels inside a Location Object. Forwarded Rules direct Location Recipients about how to handle the location information they receive. Because the Forwarded Rules themselves may reveal potentially sensitive information about a Target, only the minimal subset of Forwarded Rules necessary for a Location Recipient to handle a Location Object is distributed to the Location Recipient.
場所オブジェクトの内部を進むプライバシールール。彼らは受信場所の情報を処理する方法についての転送ルールの直接の場所受信者。転送されたルール自体はターゲットに関する機密情報を明らかにすることができるので、ロケーション・オブジェクトを処理するための場所受信者のために必要な転送されたルールの最小限のサブセットは、位置受信者に分配されます。
$ Target
$ターゲット
An individual or other entity whose location is sought in the Geopriv architecture. In many cases, the Target will be the human user of a Device, or it may be an object such as a vehicle or shipping container to which a Device is attached. In some instances, the Target will be the Device itself. The Target is the entity whose privacy Geopriv seeks to protect.
その位置Geoprivアーキテクチャで求められている個人またはその他のエンティティ。多くの場合、対象は、装置の人間のユーザであるか、またはそのようなデバイスが取り付けられた車両又は輸送コンテナなどのオブジェクトであってもよいです。いくつかの例では、ターゲットは、デバイス自体になります。ターゲットは、そのプライバシーGeoprivを保護しようとする実体です。
$ Usage Rule
$の使用ルール
A rule that describes what uses of location information are authorized.
位置情報を使用するものについて説明したルールは、許可されています。
Section 5 is largely based on the security investigations conducted as part of the Geopriv Layer-7 Location Configuration Protocol design team, which produced [9]. We would like to thank all the members of the design team.
第5節は、主に[9]生産Geoprivレイヤ7場所構成プロトコルの設計チームの一環として行われたセキュリティ調査に基づいています。私たちは、設計チームのすべてのメンバーに感謝したいと思います。
We would also like to thank Marc Linsner and Martin Thomson for their contributions regarding terminology and LCPs.
我々はまた、専門用語とのLCPに関する彼らの貢献のためのMarc Linsnerとマーティン・トムソンに感謝したいと思います。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1]ブラドナーのは、S.は、BCP 14、RFC 2119、1997年3月の "RFCsにおける使用のためのレベルを示すために"。
[2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[2]クエリャル、J.、モリス、J.、マリガン、D.、ピーターソン、J.、およびJ.ポーク、 "Geopriv要件"、RFC 3693、2004年2月。
[3] Danley, M., Mulligan, D., Morris, J., and J. Peterson, "Threat Analysis of the Geopriv Protocol", RFC 3694, February 2004.
[3] Danley、M.、マリガン、D.、モリス、J.、およびJ.ピーターソン、 "Geoprivプロトコルの脅威分析"、RFC 3694、2004年2月。
[4] U.S. Department of Defense, "National Industrial Security Program Operating Manual", DoD 5220-22M, January 1995.
[4]米国国防総省の、「国家産業セキュリティプログラム運用マニュアル」、国防総省5220-22M、1995年1月を。
[5] 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.
[5]ウィンター、J.、トムソン、M.、およびH. Tschofenig、 "GEOPRIVプレゼンス情報データフォーマット位置オブジェクト（PIDF-LO）使用解明、考慮事項、および推奨事項"、RFC 5491、2009年3月。
[6] 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.
[6] Schulzrinneと、H.、Tschofenig、H.、モリス、J.、クエリャル、J.、ポーク、J.、およびJ.ローゼンバーグ、 "共通ポリシー：プライバシー設定を表現するためのドキュメントフォーマット"、RFC 4745、2月2007。
[7] Schulzrinne, H., Ed., Tschofenig, H., Ed., Morris, J., Cuellar, J., and J. Polk, "Geolocation Policy: A Document Format for Expressing Privacy Preferences for Location Information", Work in Progress, March 2011.
[7] Schulzrinneと、H.、エド、Tschofenig、H.、エド、モリス、J.、クエリャル、J.、およびJ.ポーク、 "ジオロケーション・ポリシー：位置情報のためのプライバシー設定を表現するためのドキュメントフォーマット"。。、進歩、2011年3月に働いています。
[8] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[8]ローゼンバーグ、J.、 "拡張マークアップ言語（XML）設定アクセスプロトコル（XCAP）"、RFC 4825、2007年5月。
[9] Tschofenig, H. and H. Schulzrinne, "GEOPRIV Layer 7 Location Configuration Protocol: Problem Statement and Requirements", RFC 5687, March 2010.
[9] Tschofenig、H.およびH. Schulzrinneと、 "GEOPRIVレイヤ7場所構成プロトコル：問題文と要件"、RFC 5687、2010年3月。
[10] Polk, J., Schnizlein, J., and M. Linsner, "Dynamic Host Configuration Protocol Option for Coordinate-based Location Configuration Information", RFC 3825, July 2004.
[10]ポーク、J.、Schnizlein、J.、およびM. Linsner、 "座標ベースのロケーションの設定については、動的ホスト構成プロトコル・オプション"、RFC 3825、2004年7月。
[11] Schulzrinne, H., "Dynamic Host Configuration Protocol (DHCPv4 and DHCPv6) Option for Civic Addresses Configuration Information", RFC 4776, November 2006.
[11] Schulzrinneと、H.、RFC 4776、2006年11月 "シビック用動的ホスト構成プロトコル（DHCPv4とDHCPv6の）オプションは、構成情報をアドレス"。
[12] Polk, J., "Dynamic Host Configuration Protocol (DHCP) IPv4 and IPv6 Option for a Location Uniform Resource Identifier (URI)", Work in Progress, February 2011.
[12]、進歩、2011年2月における作業ポーク、J.、 "場所のURI（Uniform Resource Identifier）のための動的ホスト構成プロトコル（DHCP）IPv4とIPv6オプション"。
[13] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[13]バーンズ、M.編、 "HTTP対応ロケーション配信（保持）"、RFC 5985、2010年9月。
[14] Marshall, R., Ed., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010.
[14]マーシャル、R.、エド。、 "場所・バイ・リファレンス・メカニズムのための要件"、RFC 5808、2010年5月。
[15] Hardie, T., Newton, A., Schulzrinne, H., and H. Tschofenig, "LoST: A Location-to-Service Translation Protocol", RFC 5222, August 2008.
[15]ハーディ、T.、ニュートン、A.、Schulzrinneと、H.、およびH. Tschofenig、 "失われた：場所・ツー・サービス翻訳・プロトコル"、RFC 5222、2008年8月。
[16] Barnes, R., Thomson, M., Winterbottom, J., and H. Tschofenig, "Location Configuration Extensions for Policy Management", Work in Progress, June 2011.
[16]バーンズ、R.、トムソン、M.、ウィンターボトム、J.、およびH. Tschofenig、 "ポリシー管理のためのロケーションの設定拡張機能"、進歩、2011年6月での作業。
[17] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[17]ケント、S.とK. Seo、 "インターネットプロトコルのためのセキュリティアーキテクチャ"、RFC 4301、2005年12月。
[18] Dierks, T. and E. Rescorla, "The Transport Layer Security (TLS) Protocol Version 1.2", RFC 5246, August 2008.
[18]ダークス、T.およびE.レスコラ、 "トランスポート層セキュリティ（TLS）プロトコルバージョン1.2"、RFC 5246、2008年8月。
[19] Peterson, J., "A Presence-based GEOPRIV Location Object Format", RFC 4119, December 2005.
[19]ピーターソン、J.、 "プレゼンスベースGEOPRIVロケーション・オブジェクト・フォーマット"、RFC 4119、2005年12月。
[20] 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.
[20]フィールディング、R.、ゲティス、J.、モーグル、J.、Frystyk、H.、Masinter、L.、リーチ、P.、およびT.バーナーズ - リー、 "ハイパーテキスト転送プロトコル - HTTP / 1.1" 、RFC 2616、1999年6月。
[21] 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.
[21]ローゼンバーグ、J.、Schulzrinneと、H.、カマリロ、G.、ジョンストン、A.、ピーターソン、J.、スパークス、R.、ハンドレー、M.、およびE.学生、 "SIP：セッション開始プロトコル" 、RFC 3261、2002年6月。
[22] World Wide Web Consortium, "The XMLHttpRequest Object", W3C document http://www.w3.org/TR/XMLHttpRequest/, August 2010.
[22]ワールド・ワイド・ウェブ・コンソーシアム、 "XMLHttpRequestオブジェクト"、W3Cドキュメントhttp://www.w3.org/TR/XMLHttpRequest/、2010年8月。
[23] Rosen, B., Schulzrinne, H., Polk, J., and A. Newton, "Framework for Emergency Calling Using Internet Multimedia", Work in Progress, October 2010.
[23]ローゼン、B.、Schulzrinneと、H.、ポーク、J.、およびA.ニュートン、 "インターネットマルチメディアを使用して緊急コールのためのフレームワーク"、進歩、2010年10月ワーク。
[24] Rosen, B. and J. Polk, "Best Current Practice for Communications Services in support of Emergency Calling", Work in Progress, March 2011.
[24]ローゼン、B.とJ.ポーク、「緊急コールのサポートにおける通信サービスのための最も良い現在の練習」、進歩、2011年3月に作業。
[25] Schulzrinne, H., "Location-to-URL Mapping Architecture and Framework", RFC 5582, September 2009.
[25] Schulzrinneと、H.、 "場所・ツー・URLのマッピングのアーキテクチャとフレームワーク"、RFC 5582、2009年9月。
[26] Saint-Andre, P., "Extensible Messaging and Presence Protocol (XMPP): Core", RFC 6120, March 2011.
[26]サンアンドレ、P.、 "拡張メッセージングおよびプレゼンスプロトコル（XMPP）：コア"、RFC 6120、2011年3月。
[27] Shirey, R., "Internet Security Glossary, Version 2", FYI 36, RFC 4949, August 2007.
[27] Shirey、R.、 "インターネットセキュリティ用語集、バージョン2"、FYI 36、RFC 4949、2007年8月。
[28] <http://creativecommons.org/>
「２８」 ＜ｈっｔｐ：／／ｃれあちゔぇこっもんｓ。おｒｇ／＞
Authors' Addresses
著者のアドレス
Richard Barnes BBN Technologies 9861 Broken Land Pkwy, Suite 400 Columbia, MD 21046 USA
リチャード・バーンズBBNテクノロジーズ9861ブロークン・ランドパークウェイ、スイート400コロンビア、MD 21046 USA
Phone: +1 410 290 6169 EMail: rbarnes@bbn.com
電話：+1 410 290 6169 Eメール：rbarnes@bbn.com
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
マット・Lepinski BBNテクノロジーズ10モールトンセントケンブリッジ、MA 02138 USA
Phone: +1 617 873 5939 EMail: mlepinski@bbn.com
電話：+1 617 873 5939 Eメール：mlepinski@bbn.com
Alissa Cooper Center for Democracy & Technology 1634 I Street NW, Suite 1100 Washington, DC USA
民主主義とテクノロジー1634 IストリートNWのためのアリッサ・クーパーセンター、スイート1100ワシントンD.C. USA
EMail: acooper@cdt.org
メールアドレス：acooper@cdt.org
John Morris Center for Democracy & Technology 1634 I Street NW, Suite 1100 Washington, DC USA
民主主義とテクノロジー1634 IストリートNW、スイート1100のためのジョン・モリスセンターワシントンD.C. USA
EMail: jmorris@cdt.org
メールアドレス：jmorris@cdt.org
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
ハンネスTschofenigノキアシーメンスネットワークスLinnoitustie 6 02600エスポー、フィンランド
Phone: +358 (50) 4871445 EMail: Hannes.Tschofenig@gmx.net URI: http://www.tschofenig.priv.at
電話番号：+358（50）4871445 Eメール：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 US
コンピュータサイエンス450コンピュータサイエンスビル、ニューヨーク、NY 10027米国のヘニングSchulzrinneとコロンビア大学学部
Phone: +1 212 939 7004 EMail: hgs@cs.columbia.edu URI: http://www.cs.columbia.edu
電話：+1 212 939 7004 Eメール：hgs@cs.columbia.edu URI：http://www.cs.columbia.edu