[要約] RFC 6280は、インターネットアプリケーションにおける位置情報と位置プライバシーのためのアーキテクチャに関するものです。このRFCの目的は、位置情報の取得、共有、保護に関するガイドラインを提供することです。
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.
このドキュメントの現在のステータス、任意のERRATA、およびそのフィードバックを提供する方法に関する情報は、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.
Copyright（c）2011 IETF Trustおよび文書著者として特定された人。全著作権所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
このドキュメントは、BCP 78およびIETFドキュメント（http://trustee.ietf.org/license-info）に関連するIETF Trustの法的規定の対象となります。この文書に関するあなたの権利と制限を説明するので、これらの文書を注意深く確認してください。このドキュメントから抽出されたコードコンポーネントには、セクション4.Eで説明されている法的規定のセクション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アーキテクチャについて説明します。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アーキテクチャが、以来発生しているユースケースにどのように適用されるかを明確にするために、基本的なGEOPRIV要件[2] [3]を修正および拡大するアーキテクチャです。これらの文書の公開。第二に、このドキュメントは、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.
機密情報への使用規則の拘束力は、情報を保護する一般的な方法です。著作権情報を表現するためのいくつかの新たなスキームは、著作権で保護された作品とともに伝達されるルールを提供します。Creative Commons [28]モデルは最も顕著な例であり、作業の所有者が4種類のルール（「帰属」、「非営利」、「派生作品なし」、「Sharealike」）を設定できるようにします。作品。著者がこれらのルールを設定した後、すべての受信者が著作権条件を認識できるように、ルールは作業自体とともに伝えられます。
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.
組織内の機密文書を制御するための分類システムも別の例です。これらのシステムでは、ドキュメントが作成されると、「秘密」や「独自」などの分類がマークされています。ドキュメントの各受信者は、このマーキングから、ドキュメントがそのマークでドキュメントにアクセスすることを許可されている他の人とのみ共有されるべきであることを知っています。分類マーキングは、マーキングが有効な時間（機密解除日）の仕様など、他の種類のルールを伝えることもできます。米国防衛局の分類ガイドライン[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].
「必須」、「そうしない」、「必須」、「必要」、「しない」、「そうしない」、「そうではない」、「そうでない」、「推奨」、「5月」、および「オプション」は、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).
これらの2つの目標が満たされている場合、位置情報を受け取るすべての関係者は、その情報をどのように使用できるかについての指令も受け取ります。プライバシーを提供するエンティティは、許可された使用のみに従事し、プライバシーに違反するエンティティは、許可されていること（したがって、暗黙的に、そうでないものについて）を通知されているため、故意にそうします。
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つの目標は、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).
アリスの友人の何人かは、たとえば彼女と会うか、時間の経過とともに彼女の場所をプロットするために、自分の目的のためだけにアリスの場所を使用することに興味があります。彼らが受け取ることができるかどうかについて彼らが指示するという使用規則（たとえば、アリスは、たとえば2週間以上にわたって彼女の位置を維持したくないかもしれません）。
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.
アリスの場所を友人の何人かに送りたい友人のボブを考えてみましょう。プライバシーを保護する方法で動作するために、ボブは自分自身の使用ルールだけでなく、誰に情報を送信できるかを記載して受信者に提供できるルールを説明するアクセス制御ルールを必要とします。彼がプレゼンスサーバーから受け取ったルールが彼にアリスの場所を他の人に与えることを許可した場合、彼はそうするかもしれません。そうでなければ、彼は彼女の場所を配布することを許可される前に、アリスからの追加の規則を必要とします。ボブからアリスの場所を受け取った受信者が位置情報をさらに配布したい場合、ボブと同じプロセスを経る必要があります。
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.
Location Server（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.
Location Recipient（LR）：[位置情報]の受信の役割を実行します。場所の受信者は、（ロケーションサーバーにクエリを送信することにより）明示的に場所を要求するか、非同期にロケーションを受信する場合があります。プレゼンスサービス、Bob、Friend-1、およびFriend-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:
このアーキテクチャ内では、2つのデータ形式が必要です。
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.
Location Object（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. 配布：ロケーションサーバーは、ロケーションレシピエントに位置情報を送信します。これは、ロケーションサーバーとして機能し、場所を他の場所の受信者にさらに数回配布する場合があります。
3. Use: A Location Recipient receives the location and uses it.
3. 使用：場所の受信者が場所を受け取り、それを使用します。
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など）と物理的な関係を持つエンティティです。有線ネットワークでは、WireMapベースの場所はネットワークベースのテクニックです。ワイヤレスネットワークでは、ベースステーションからの測定値を使用するタイミングおよび信号強度ベースの手法は、ネットワークベースと見なされます。大規模な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間の通信のためのプロトコルは厳密に必要ではありません（たとえば、ネットワークスタックの下層層で、）。これは、ポジショニングプロセスへの入力を収集するための他のインターネットプロトコル（Simple Network Management Protocol（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）アドレスの最初のルーターのアドレスに至るまで、デバイスの環境に関する観察であると理解されています。「支援」は、測定の補完、つまり測定に基づいて位置の計算を可能にする位置決め情報です。ワイヤレスベースステーションの場所（またはワイヤレスキャリブレーション情報）のセットは、企業キャンパス内の建物にルーターをマッピングするテーブルと同様に、支援データムです。
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ポジショニングシステムでは、デバイスは測定値（MACアドレスと信号強度など）をLGに送信し、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.)
余談ですが、「Assisted GPS」（「Assisted GNSS」がより広く「Assisted GNS」）には、測定値と支援データの両方を送信する技術が実際に含まれます。デバイスが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の間の測定データまたは位置決めデータの交換には、情報が伝達されるプロトコルが必要です。このプロトコルの構造は、ネットワーク支援スキームが次の2つのパターンのどれに依存します。逆に、プロトコルの構造は、プロトコルの相互作用の最後にあるデバイスの位置を認識している2つの当事者（デバイス、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.
位置は、場所が特定のデバイスに関連付けられ、ターゲットのIDに関連付けられる可能性がある最初のポイントです。ターゲットの実際のアイデンティティにリンクされていないローカル識別子、リンクされていない仮名、またはプライベート識別子は、可能な限りアイデンティティの形式として使用する必要があります。これにより、ターゲットのIDが分散される前に場所を分離することにより、プライバシー保護が提供されます。
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を使用して複数のLSEを使用）。プライバシーに不満のLGがプライバシーを維持しながらこれらのLSEに位置情報を配布できるようにするために、LGとそのLSEのセットとの関係を厳密に制約する必要があります（効果的に「ハードワイヤード」）。つまり、LGはLSEの小さな固定セットに位置情報のみを提供する必要があり、これらの各LSEはセクション4.2.4の要件に準拠する必要があります。
Manipulation of the positioning process can expose location information through two mechanisms:
ポジショニングプロセスの操作は、2つのメカニズムを介して位置情報を公開できます。
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として機能します。場所の配布とは、1つ以上のLSEがプライバシーを提供する方法でLRSにLOSを提供するプロセスです。
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内、LOSを運ぶプロトコル内、またはルールを運ぶ別のプロトコルを介して伝達できます。第二に、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種類の相互作用があります。つまり、LOSを受け取り、送信します。LSは、オプションで3番目の相互作用を実装して、ルールメーカーがルールでそれをプロビジョニングできるようにすることができます。これらの2つのケースの区別は実際に重要です。これは、LSがルールメーカーと直接的な関係を持っているかどうかを決定するため、ルールメーカーから直接ルールを受け入れるLSがそのような関係を持っていますが、LSはすべてのルールを獲得するLSをロスはそうではありません。
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.
プライバシールールは、ターゲットのプライバシーを維持するためのGEOPRIVの中心的なメカニズムです。これは、LO（LSまたはLR）の受信者にLOの使用方法に関する情報を提供するためです。
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.
o example.comから要求された場合、位置情報を再送信します。
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.
LSEは、プライバシールールを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.
LSEは、「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.
プライバシールールは、LSEとLRの両方の動作を管理できます。ターゲットの位置情報をどのように扱うかについてLSEを指示するルールは、ローカルルールとして知られています。ローカルルールは、LSからのリクエストを処理するためにLSによって内部的に使用されます。それらはLRSに配布されていません。
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を移動し、受信した位置情報を処理する方法についてLSEと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は、アリスの正確な場所をボブに再送信することがあります。
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サイトに再送信することができます。これは、1年間の位置情報を保持し、要求者に再送信することが許可されています。
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は、制約された処理機能を備えたデバイスでも使用できるように設計されています。制約されたデバイスで転送されたルールを処理できるようにするために、LOSは、より堅牢な外部ルールのセットを参照するオプションを備えた限られた一連の転送ルールのみを搭載する必要があります。限られたルールセットは、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内でロケーション構成として知られています。「Location Information Server」（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を介して処理された場所の要求と応答が実際にターゲットから/にあることを信頼できるようにします。Geopriv [10] [11] [12] [13]内でいくつかのLCPが開発されています。
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の分布）には、いくつかの利点があります。URISは通常LOSよりも小さいため、ロケーション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.
ポジショニングの観点から見ると、場所ごとに「Just In Time」ポジショニングの追加の利点を提供できます。場所が参照によって配布されている場合、レシピエントが以前に分散したURIを宣告した場合、LG/LSの合計として機能するエンティティはポジショニング操作を実行する必要があります。
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.
プライバシーの観点からは、LOとしてではなくURIとして場所を配布すると、各受信者に参照されたLSからロケーション情報を要求することにより、プライバシーを保護するのに役立ち、各受信者に個別にアクセスコントロールを適用できます。しかし、ここで提供される利点は、アクセス制御を適用するLSを条件としています。LSがロケーションURIのリクエストにアクセス制御ポリシーを適用しない場合（言い換えれば、[14]で定義されている「所有モデル」を実施する場合）、URIを送信すると、URIがLOを送信するのと同じプライバシーリスクを提示します。自体。さらに、アクセス制御のないロケーションURIの使用は、追加のプライバシーリスクを導入できます。URIが予測可能である場合、URIが送信されていない攻撃者がURIを推測し、参照されるLOを取得するためにそれを使用できる場合があります。これを緩和するには、アクセス制御のない場所を構築する必要があります。これにより、推測を実行不可能にするのに十分なエントロピーを備えたランダムコンポーネントが含まれています。
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は、承認されたルールメーカーからのルールのみを受け入れる必要があります。LOSのみでルールを受信し、ルールメーカーと直接的な関係を持たないLSの場合、この要件は、LOで提供されたルールをそのLOの分布に適用することにより満たされます。ルールメーカーとの直接的な関係を持つLSの場合、この要件は、LSがRM認証ポリシーで構成可能でなければならないことを意味します。LSは、特定のターゲットまたはLOのルールを提供できるRMSの規定されたセットを定義する必要があります。たとえば、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.
LOSのみを介してルールを受信する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:
1つ以上のルールメーカーから直接ルールを受け取るLSとLOSを介して、特定のLOのルールをRMSから受け取ったルールと組み合わせる必要があります。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 Override：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はGETリクエストを使用して、LSによって適用されるポリシーを取得し、新しいルールを指定するPUTリクエストを使用できます。
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オーバーライド」ポリシーが適切な場合があります（たとえば、外部RMがターゲットであり、LOが第三者によって提供される場合）。逆に、「LOオーバーライド」ポリシーは、RMがモバイルデバイスLSのユーザーであり、LOにRMの両親または企業セキュリティのルールが含まれている場合、RMがRMよりも信頼できる場合により適しています。オフィス。「交差」ポリシーは、許可補助金の最も厳格な見解を取り、すべてのRMS（LO Creatorを含む）に等しい重みを与えます。
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.
これらの各ポリシーには、プライバシーの結果も異なります。「交差」ポリシーに従って、すべてのRMSのルールの中で最もプライバシーに対応するサブセットに従うことが保証されます。「組合」ポリシーと両方の「上書き」ポリシーは、ポリシーに従わないRM（潜在的にはターゲットを含む）の期待に反する可能性があります。たとえば、RMとして機能するターゲットがルールを設定し、それらのルールがRMとして機能するターゲットの親または雇用主によって設定されたより寛容なLOオーバーライドポリシーの適用、ターゲットのデータの再送信または保持によって上書きされた場合ターゲットにとって驚きとして来るかもしれません。このため、LSEが特定のLOの分布にどのポリシーを適用するかをRMSが検索できる方法を提供することをお勧めします。
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は、LSが相互作用するエンティティ（LR、LSE、RMSを含む）およびその他の情報に関する情報の信頼性の保証を必要とします。
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のIDのIDのIDに関する情報を提供する必要があります。この情報の有効性を確保するために、これらのプロトコルは両当事者の相互認証を可能にし、プロトコルメッセージの整合性保護を提供する必要があります。これらのセキュリティ機能により、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は必然的にレイヤー2スイッチからIPルーター、アプリケーション層プロキシやゲートウェイに至るまで、一連の仲介者を通過します。これらの仲介業者がプライバシーを提供するエンティティ間を移動する際に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は、位置情報を送信するLSとそれを受け取るLRの間にエンドツーエンドの機密保護を備えている必要があります。場合によっては、LOを伝えるプロトコルは、そのシグナリング（および潜在的にはデータトラフィック）のための組み込みセキュリティソリューションとして機密保護を提供します。この場合、このような暗号化されたチャネル内で保護されていないLOを運ぶだけで十分です。ただし、多くのプロトコルは、メッセージがホップバイホップベースで保護されていないか保護されている通信モードを提供しています（たとえば、ストアアンドフォワードプロトコルの仲介者間）。そのような場合、プロトコルでは、暗号化されたLOSの使用、または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（たとえば、LOSを保存したり、他のサービスプロバイダーに送信してロケーションベースのサービスを取得したりする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.
LRSの主要なプライバシー要件は、使用規則に従うことです。LOを再送信または保持したいLRは、そのLOに含まれるルールを調べる必要があります。LOのLRが作成する使用は、これらのルールによって明示的に承認されなければなりません。ルールは許可の肯定的な助成金であるため、明示的に承認されていないアクションはデフォルトで拒否されます。
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.
プライバシーとは別に、LRSは、LOがロケーションベースのサービスを提供するためにLOSを使用するため、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.
LOSのプライバシーに関連するセキュリティ上の考慮事項については、このドキュメント全体で説明します。このセクションでは、これらの懸念を要約し、プライバシーに関連しないセキュリティリスクを検討します。
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）[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.
プロトコルメカニズムのみを使用して、エンティティは配布チェーンのほぼ1つのホップのみを保証することができます。たとえば、LRが整合性および機密保護されたチャネルを介してLSから位置情報を受信しているとします。LRは、送信されたLOが途中で変更または観察されていないことを知っています。ただし、プロトコルによって提供される保証は、送信されたLOがLSに送信される前に破損していないことを保証しません（たとえば、以前のLSにより）。同様に、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.
LOSのセキュリティに対する主要な脅威は、2つのカテゴリにグループ化できます。第一に、LOSの完全性と信ity性に対する脅威は、LOSに依存しているエンティティを暴露する可能性があります。第二に、LOSの機密性に対する脅威により、位置情報への不正アクセスが可能になります。
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.
ルールメーカー：ルールメーカーは、ターゲットのプライバシールールを作成し、LSEにアップロードする責任があります。ルールメーカーが必要とする主な保証は、ターゲットのプライバシールールが、LOを処理する各LSに伝えられると、ターゲットのIDに正しく関連付けられていることです。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が必要とする最初の保証は、ターゲットのプライバシールールとターゲットのIDとの間の拘束力が本物であることです。プライバシールールを作成、更新、削除するルールメーカーの認証と承認により、ルールを増やす攻撃が防止されます。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は、ターゲットの位置、ターゲットのアイデンティティ、および時間の間のバインディングの信頼性に関する保証を必要とします。これらのバインディングの信頼性を確保することは、場所の偽造、タイムスタンプの変更、アイデンティティの偽造、LOSのリプレイなど、さまざまな攻撃を防ぐのに役立ちます。
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.
ロケーションオブジェクトの整合性と機密性に関する保証は、LO形式を介して直接提供できます。RFC 4119 [19]は、Secure/Multipurpose Internet Mail Extensions（S/MIME）の使用に関する説明を提供し、整合性と機密保護を保護します。このような直接的なエンドツーエンドの保証は望ましいものであり、これらのメカニズムは可能な限り使用する必要がありますが、LOを直接固定することは非現実的である多くの展開シナリオがあります。たとえば、一部の展開シナリオでは、ロケーションオブジェクトの作成者と受信者の間に直接的な信頼関係が存在しない場合があります。さらに、多くの受信者が特定の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の再送信と保持の制限です。これらの2つのルールは最もよく知られた重要な例ですが、LSまたはLRが考慮しなければならない特定のタイプのルールは、一般的にITプロセスのタイプに依存します。
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.
Geoprivアーキテクチャの最も単純なシナリオの1つは、デバイスが独自の場所を決定し、そのLOを使用してサービスを要求する場合です（たとえば、HTTP Postリクエスト[20]またはSIP Inviteメッセージ[21]にLOを含めること）、およびサーバーは、デバイスの場所を保持または再送信することなく、そのサービスをすぐに（例えば、HTTPまたはSIPで200 OK応答で）配信します。デバイスは、デバイスベースの位置決めアルゴリズム（手動入力など）を使用してLGとして機能し、ルールを解釈してLOを送信することによりLSとして機能します。ターゲットは、場所をサーバーに送信する必要があることを指定することにより、ルールメーカーとして機能します。サーバーは、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つのステップで維持されます。最初のステップは、場所が単一のルールメーカー、つまりターゲットの指示に従ってのみ送信されることです。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） - > Ephemeral Webサービス、ユーザー表示によるプライバシー
o Use: Ephemeral Web service delivers response without retaining or retransmitting location
o 使用：Ephemeral 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.
* リスクのあるプライバシーがデフォルトでGeoprivに準拠しているように振る舞わないLR。それ以上のアクションは必要ありません。
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.
JavaScriptコードを使用して、ロケーション固有の情報の一連のHTTP要求を調整するために、多くのロケーションベースのサービスがWebを介して配信されます。これらのアプリケーションをサポートするために、デバイスベースのポジショニング（手動入力およびグローバルポジショニングシステム（GPS））とネットワーク支援ポジショニング（ASSISTED GPS（AGP）を介して、および802.11とセルラーシグナルを備えた多層）をサポートするブラウザ拡張機能が開発されました。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サイトは、WebページがLOを受け入れると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.
使用フェーズには、WebサイトのLOの使用が含まれます。これに関連して、「Webサイト」というフレーズには、Webページだけでなく、その背後にある専用のサポートロジックも含まれます。Webサイト全体を1ページではなく受信者として考慮すると、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-> webサイト= 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:
Voice-Over-IPデバイスによる緊急通話のサポートは、インターネットホストに関する位置情報の重要なユースケースです。緊急通話のためのインターネットアーキテクチャの詳細は、[23] [24]に記載されています。このアーキテクチャでは、緊急通話の配置には3つの重要な手順があります。それぞれが位置情報を含みます。
1. Determine the location of the caller.
1. 発信者の場所を決定します。
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. 発信者の場所を含むSIP InviteメッセージをPSAPに送信します。
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番目のステップには、場所の配布と使用が含まれます。緊急通話をルーティングしているエンティティは、場所からサービスへの翻訳（失われた）プロトコル[15]を通じて位置情報をマッピングサーバーに送信します。この役割では、ルーティングエンティティはLSとして機能し、失われたサーバーはLRとして機能します。Lost内のLO形式では、ルールを場所とともに送信することは許可されていませんが、Lostはアプリケーション固有のプロトコルであるため、Lostメッセージ内の場所を送信すると、失われたサーバーがその場所を使用してプロトコルを完了することを許可します。失われたマッピングアーキテクチャ[25]を介して必要に応じてメッセージをルーティングする。つまり、Lost ServerはLost Protocolを完了することを許可されていますが、他に何もしません。
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として機能し、PSAPはLRとして機能します。この具体的な例では、発信者の位置は、PIDF-LOまたはPIDF-LOを返す参照として送信されます。後者の場合、PSAPのみがアクセスできるように、参照を適切に保護する必要があります。いずれにせよ、LOの受領は、PSAPがプライバシーを維持するためにそれらのLOSの規則に従うべきであることを意味します。規制環境に応じて、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->失われたインフラストラクチャ（ルールなし）、プロトコルに暗黙的に承認を介したプライバシー
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つのチャネルを介して情報を受け取り、別のチャネルを介してブロードキャストします。この意味で、ユーザーとチャネル（例：Webサービス）の両方がLSEになります。ここでは、複数の論理ホップにわたってこのパターンを示すより複雑な例を検討します。
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.
ボブはアリスの友人の一人であり、彼はこの場所が強化されたプレゼンスサービスを通じて彼女の場所を受け取ります。彼女がお気に入りのコーヒーショップにいることに注目して、ボブはコーヒーショップで2人の写真を写真共有サイトにアップロードし、その場所をマークするLOをアップロードしたいと考えています。ボブはアリスのLOのルールをチェックし、写真共有サイトがアリスが許可したサービスの1つであることを確認します。アリスが彼に写真を共有するサイトに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.
最初のディストリビューションホップは、プレゼンスサーバーが場所をBOBに送信するときに発生します。このトランザクションでは、プレゼンスサーバーはLSとして機能し、アリスはRMとして機能し、ボブはLRとして機能します。このトランザクションのプライバシーは、アリスが彼女の場所に誰がアクセスできるかを指示するプレゼンスサーバーにルールをインストールしたという事実によって保証されています。2番目のディストリビューションホップは、ボブがLOを写真共有サイトにアップロードするときです。ここで、ボブはLSとして機能し、LOのルールが彼がそれをアップロードできることを確認することにより、位置情報のプライバシーを維持します。3番目のディストリビューションホップは、写真共有サイトがLOをイブに送信する場合、同様にルールに従っていますが、LOは異なるLSEに対して異なるルールセットを指定できるため、ボブとは異なるルールのセットです。
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.
イブはチェーンの4番目の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
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
o 配布/使用ホップ3：写真共有サイト - >イブ、LOのサイトのルールによるプライバシー
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 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 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は、主に、Geopriv Layer-7位置構成プロトコル設計チームの一部として実施されたセキュリティ調査に基づいており、生産しました[9]。デザインチームのすべてのメンバーに感謝します。
We would also like to thank Marc Linsner and Martin Thomson for their contributions regarding terminology and LCPs.
また、用語とLCPに関する貢献について、Marc LinsnerとMartin Thomsonに感謝します。
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[2] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[2] Cuellar、J.、Morris、J.、Mulligan、D.、Peterson、J。、およびJ. Polk、「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.、Mulligan、D.、Morris、J。、およびJ. Peterson、「Geoprivプロトコルの脅威分析」、RFC 3694、2004年2月。
[4] U.S. Department of Defense, "National Industrial Security Program Operating Manual", DoD 5220-22M, January 1995.
[4] 米国国防総省、「National Industrial Security Program Operating Manual」、DOD 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] Winterbottom、J.、Thomson、M。、およびH. Tschofenig、「Geopriv Presence情報データフォーマットロケーションオブジェクト（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.、Morris、J.、Cuellar、J.、Polk、J。、およびJ. Rosenberg、「共通政策：プライバシーの好みを表現するためのドキュメント形式」、RFC 4745、2007年2月。
[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.、Ed。、Tschofenig、H.、Ed。、Morris、J.、Cuellar、J.、およびJ. Polk、「Geolocation Policy：A Location Exprienceのプライバシー設定を表現するためのドキュメント形式」、進行中の作業、2011年3月。
[8] Rosenberg, J., "The Extensible Markup Language (XML) Configuration Access Protocol (XCAP)", RFC 4825, May 2007.
[8] Rosenberg、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 Layer 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] Polk、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。、「Civicアドレス構成情報の動的ホスト構成プロトコル（DHCPV4およびDHCPV6）オプション」、RFC 4776、2006年11月。
[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] POLK、J。、「ダイナミックホスト構成プロトコル（DHCP）IPv4およびIPv6オプションの位置ユニフォームリソース識別子（URI）」、2011年2月、Work in Progress。
[13] Barnes, M., Ed., "HTTP-Enabled Location Delivery (HELD)", RFC 5985, September 2010.
[13] Barnes、M.、ed。、「HTTP対応の位置配信（保有）」、RFC 5985、2010年9月。
[14] Marshall, R., Ed., "Requirements for a Location-by-Reference Mechanism", RFC 5808, May 2010.
[14] Marshall、R.、ed。、「場所ごとのメカニズムの要件」、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] Hardie、T.、Newton、A.、Schulzrinne、H。、およびH. Tschofenig、「Lost：A Location-s-Service Translation Protocol」、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] Barnes、R.、Thomson、M.、Winterbottom、J。、およびH. Tschofenig、「ポリシー管理のための位置構成拡張機能」、2011年6月の作業。
[17] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[17] Kent、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] Dierks、T。およびE. Rescorla、「The Transport Layer Security（TLS）Protocolバージョン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] Fielding、R.、Gettys、J.、Mogul、J.、Frystyk、H.、Masinter、L.、Leach、P。、およびT. Berners-Lee、 "HyperText Transfer Protocol-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] Rosenberg、J.、Schulzrinne、H.、Camarillo、G.、Johnston、A.、Peterson、J.、Sparks、R.、Handley、M。、およびE. Schooler、「SIP：SESSION INITIATION Protocol」、RFC 3261、2002年6月。
[22] World Wide Web Consortium, "The XMLHttpRequest Object", W3C document http://www.w3.org/TR/XMLHttpRequest/, August 2010.
[22] World Wide Webコンソーシアム、「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] Rosen、B.、Schulzrinne、H.、Polk、J。、およびA. Newton、「Internet Multimediaを使用した緊急通話のフレームワーク」、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] Rosen、B。およびJ. Polk、「緊急通話を支援するコミュニケーションサービスの最良の現在の実践」、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] Saint-Andre、P。、「拡張可能なメッセージとプレゼンスプロトコル（XMPP）：Core」、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壊れた土地PKWY、スイート400コロンビア、MD 21046 USA
Phone: +1 410 290 6169
EMail: rbarnes@bbn.com
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge, MA 02138 USA
Matt Lepinski BBN Technologies 10 Moulton St. Cambridge、MA 02138 USA
Phone: +1 617 873 5939 EMail: mlepinski@bbn.com Alissa Cooper Center for Democracy & Technology 1634 I Street NW, Suite 1100 Washington, DC USA
電話：1 617 873 5939メール：mlepinski@bbn.com Alissa Cooper for Democracy＆Technology 1634 I Street NW、Suite 1100 Washington、DC USA
EMail: acooper@cdt.org
John Morris Center for Democracy & Technology 1634 I Street NW, Suite 1100 Washington, DC USA
ジョン・モリス・センター・フォー・デモクラシー・テクノロジー1634 I Street NW、Suite 1100 Washington、DC USA
EMail: jmorris@cdt.org
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600 Finland
Hannes Tschofenig Nokia Siemens Networks Linnoitustie 6 Espoo 02600フィンランド
Phone: +358 (50) 4871445
EMail: Hannes.Tschofenig@gmx.net
URI: http://www.tschofenig.priv.at
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 US
ヘニングシュルツリンコロンビア大学コンピュータサイエンス学科450コンピューターサイエンスビル、ニューヨーク州ニューヨーク10027米国
Phone: +1 212 939 7004
EMail: hgs@cs.columbia.edu
URI: http://www.cs.columbia.edu