Network Working Group J. Cuellar
Request for Comments: 3693 Siemens AG
Category: Informational J. Morris
Center for Democracy & Technology
D. Mulligan
Samuelson Law, Technology & Public Policy Clinic
J. Peterson
NeuStar
J. Polk
Cisco
February 2004
Geopriv Requirements
Status of this Memo
このメモの位置付け
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
このメモはインターネットコミュニティのための情報を提供します。それはどんな種類のインターネット標準を指定しません。このメモの配布は無制限です。
Copyright Notice
著作権表示
Copyright (C) The Internet Society (2004). All Rights Reserved.
著作権（C）インターネット協会（2004）。全著作権所有。
Abstract
抽象
Location-based services, navigation applications, emergency services, management of equipment in the field, and other location-dependent services need geographic location information about a Target (such as a user, resource or other entity). There is a need to securely gather and transfer location information for location services, while at the same time protect the privacy of the individuals involved.
ロケーションベースのサービス、ナビゲーションアプリケーション、緊急サービス、フィールド内の機器の管理、および他の位置依存サービスは、（例えば、ユーザ、リソースまたは他のエンティティのような）ターゲットに関する地理的位置情報を必要とします。同時に、関係者のプライバシーを保護しながら、安全に、ロケーションサービスのための位置情報を収集して転送する必要があります。
This document focuses on the authorization, security and privacy requirements for such location-dependent services. Specifically, it describes the requirements for the Geopriv Location Object (LO) and for the protocols that use this Location Object. This LO is envisioned to be the primary data structure used in all Geopriv protocol exchanges to securely transfer location data.
この文書では、このような位置依存サービスの認可、セキュリティやプライバシーの要件に焦点を当てています。具体的には、Geopriv場所オブジェクト（LO）のためにこの場所のオブジェクトを使用するプロトコルのための要件を記述する。このLOを確実に位置データを転送するために、すべてのGeoprivプロトコル交換に使用される主要なデータ構造であることが想定されます。
Table of Contents
目次
1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Conventions Used in this Document. . . . . . . . . . . . . . . 4
3. Glossary . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4. Primary Geopriv Entities . . . . . . . . . . . . . . . . . . . 6
5. Further Geopriv Terminology. . . . . . . . . . . . . . . . . . 7
5.1. Location Information and Sighting. . . . . . . . . . . . 7
5.2. The Location Object and Using Protocol . . . . . . . . . 9
5.3. Trusted vs. Non-trusted Data Flows . . . . . . . . . . . 10
5.4. Further Geopriv Principals . . . . . . . . . . . . . . . 10
5.5. Privacy Rules. . . . . . . . . . . . . . . . . . . . . . 12
5.6. Identifiers, Authentication and Authorization. . . . . . 13
6. Scenarios and Explanatory Discussion . . . . . . . . . . . . . 15
7. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 19
7.1. Location Object. . . . . . . . . . . . . . . . . . . . . 19
7.2. The Using Protocol . . . . . . . . . . . . . . . . . . . 21
7.3. Rule based Location Data Transfer. . . . . . . . . . . . 21
7.4. Location Object Privacy and Security . . . . . . . . . . 22
7.4.1. Identity Protection. . . . . . . . . . . . . . . 22
7.4.2. Authentication Requirements. . . . . . . . . . . 23
7.4.3. Actions to be secured. . . . . . . . . . . . . . 23
7.5. Non-Requirements . . . . . . . . . . . . . . . . . . . . 24
8. Security Considerations. . . . . . . . . . . . . . . . . . . . 24
8.1. Traffic Analysis . . . . . . . . . . . . . . . . . . . . 24
8.2. Securing the Privacy Rules . . . . . . . . . . . . . . . 24
8.3. Emergency Case . . . . . . . . . . . . . . . . . . . . . 24
8.4. Identities and Anonymity . . . . . . . . . . . . . . . . 25
8.5. Unintended Target. . . . . . . . . . . . . . . . . . . . 26
9. Protocol and LO Issues for later Consideration . . . . . . . . 26
9.1. Multiple Locations in one LO . . . . . . . . . . . . . . 26
9.2. Translation Fields . . . . . . . . . . . . . . . . . . . 26
9.3. Truth Flag . . . . . . . . . . . . . . . . . . . . . . . 27
9.4. Timing Information Format. . . . . . . . . . . . . . . . 27
9.5. The Name Space of Identifiers. . . . . . . . . . . . . . 27
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 28
11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28
11.1. Normative Reference . . . . . . . . . . . . . . . . . . 28
11.2. Informative References . . . . . . . . . . . . . . . . . 28
12. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . 29
13. Full Copyright Statement . . . . . . . . . . . . . . . . . . . 30
Location-based services (applications that require geographic location information as input) are becoming increasingly common. The collection and transfer of location information about a particular Target can have important privacy implications. A key goal of the protocol described in this document is to facilitate the protection of privacy pursuant to Privacy Rules set by the "user/owner of the Target" (or, more precisely in the terminology of this document given in Section 3 and 5.4 below, the "Rule Maker").
ロケーションベースのサービス（入力としての地理的位置情報を必要とするアプリケーション）は、ますます一般的になっています。特定のターゲットの位置情報の収集と転送は、重要なプライバシーの意味を持つことができます。この文書に記載されているプロトコルの主要な目標は、第3節以下5.4で与えられたこの文書の用語で、より正確には、「ターゲットの利用者/所有者」で設定された（またはプライバシー規則の定めるところにより、プライバシーの保護を容易にすることです「ルールメーカー」）。
The ability to gather and generate a Target's location, and access to the derived or computed location, are key elements of the location-based services privacy equation. Central to a Target's privacy are (a) the identity of entities that have access to raw location data, derive or compute location, and/or have access to derived or computed location information, and (b) whether those entities can be trusted to know and follow the Privacy Rules of the user.
ターゲットの位置を収集し、生成する機能、および派生または計算された場所へのアクセスは、ロケーションベースのサービスのプライバシー方程式の重要な要素です。対象者のプライバシーの中心である（a）は、生の位置データへのアクセス権を持って引き出すか、位置を計算、および/または派生または計算された位置情報へのアクセス権を持っていると、（b）それらのエンティティが信頼できるかどうかを知るために、エンティティのアイデンティティそして、ユーザーのプライバシー規則に従ってください。
The main principles guiding the requirements described in this document are:
本書に記載されている要件を導く主な原則は以下のとおりです。
1) Security of the transmission of Location Object is essential to guarantee the integrity and confidentiality of the location information. This includes authenticating the sender and receiver of the Location Object, and securing the Location Object itself.
1）場所オブジェクトの送信のセキュリティは、位置情報の完全性と機密性を保証するために不可欠です。このロケーション・オブジェクトの送信者と受信者の認証、およびロケーションオブジェクト自体を固定含みます。
2) A critical role is played by user-controlled Privacy Rules, which describe the restrictions imposed or permissions given by the "user" (or, as defined below, the "Rule Maker"). The Privacy Rules specify the necessary conditions that allow a Location Server to forward Location Information to a Location Recipient, and the conditions and purposes for which the Location Information can be used.
2）重要な役割は、「ユーザ」（又は、以下に定義されるように、「ルールメーカー」）によって与えられた制約または許可を記述するユーザ制御プライバシー規則によって再生されます。プライバシールールは、位置情報を使用できるためにロケーションサーバは、場所の受信者に位置情報を転送することができるように必要な条件、および条件や目的を指定します。
3) One type of Privacy Rules specify how location information should be filtered, depending on who the recipient is. Filtering is the process of reducing the precision or resolution of the data. A typical rule may be of the form: "my location can only be disclosed to the owner of such credentials in such precision or resolution" (e.g., "my co-workers can be told the city I am currently in").
3）プライバシーの一つのタイプは、受信者が誰であるかに応じて、位置情報をフィルタリングする方法を指定する規則。フィルタリングは、データの精度または分解能を減少させるプロセスです。一般的なルールは次の形式のものであってもよい：（例えば、「私の同僚は、私は現在、午前街に語ったことができる」）「私の場所でのみ、そのような精度や解像度でこのような資格情報の所有者に開示することができ」。
4) The Location Object should be able to carry a limited but core set of Privacy Rules. The exact form or expressiveness of those Rules in the core set or in the full set is not further discussed in this document, but will be discussed more extensively in future documents produced by this working group.
4）Locationオブジェクトは、プライバシー規則の限られたが、コアセットを運ぶことができなければなりません。正確な形式又はコアセットまたはフルセットにおけるこれらの規則の表現はさらに、本書で議論されていないが、このワーキンググループによって生成される将来の文書でより広範囲に説明します。
5) Whenever appropriate, the location information should not be linked to the real identity of the user or a static identifier easily linked back to the real identity of the user (i.e., Personally Identifiable Information such as a name, mailing address, phone number, social security number, or email address or username). Rather, the user should be able to specify which local identifier, unlinked pseudonym, or private identifier is to be bound to the location information.
5）適切なときに、位置情報を利用者の正体や簡単に使用者の正体（に戻ってリンクされ、静的な識別子にリンクしてはならない、すなわち、名前、メールアドレス、電話番号などの個人情報、社会保障番号、または電子メールアドレスまたはユーザ名）。むしろ、ユーザはローカル識別子、リンクされていない偽名、またはプライベート識別子は、位置情報に結合されるかを指定することができなければなりません。
6) The user may want to hide the real identities of himself and his partners, not only to eavesdroppers but also to other entities participating in the protocol.
6）ユーザーは、盗聴者にもプロトコルに参加している他のエンティティにするだけでなく、彼自身と彼のパートナーの本当のアイデンティティを非表示にすることがあります。
Although complete anonymity may not be appropriate for some applications because of legal constraints or because some location services may in fact need explicit identifications, most often the location services only need some type of authorization information and/or perhaps anonymous identifiers of the entities in question.
完全な匿名性があるため、法的な制約のか、いくつかのロケーションサービスは、実際には、明示的な識別を必要とする可能性があるため、ほとんどの場合、ロケーションサービスは、唯一の認証情報および/または問題のエンティティの、おそらく匿名IDのいくつかのタイプを必要とするいくつかのアプリケーションには適切でないかもしれないが。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
この文書のキーワード "MUST"、 "MUST NOT"、 "REQUIRED"、、、、 "べきではない" "べきである" "ないもの" "ものとし"、 "推奨"、 "MAY"、および "OPTIONAL" はあります[RFC2119]に記載されているように解釈されます。
Note that the requirements discussed here are requirements on the generic Location Object and on using protocols for location services. Thus, for the most part, the requirements discussed in this document refer to capabilities that are mandatory-to-implement. For example, requiring that implementations support integrity is not the same thing as requiring that all protocol traffic be authenticated. In contrast, an example of a mandatory-to-use (not just mandatory-to-implement) requirement might be one that states that the user always receives a notice when his location data was not authenticated. This practice is mandatory-to-use, not just to implement.
ここで説明する要件は、一般的な場所のオブジェクト上とロケーションサービスのためのプロトコルを使用して上の要件であることに注意してください。このため、ほとんどの部分は、本ドキュメントに記載の要件は、実装に必須のある機能を参照してください。例えば、実装が整合性をサポートすることを要求すると、すべてのプロトコルのトラフィックを認証することを要求することと同じものではありません。対照的に、必須のに使用できる（だけでなく、強制的に実装）要件の一例は、彼の位置データが認証されなかった場合、ユーザは常に通知を受信することを述べて1かもしれません。この練習は必須に使用できるだけでなく、実装するのです。
For easy reference and readability, below are basic terms that will be defined more formally and fully later in this document.
簡単に参照し、読みやすくするために、以下のこのドキュメントの後半より正式かつ完全に定義される基本的な用語です。
Location Generator (LG): The entity that initially determines or gathers the location of the Target and creates Location Objects describing the location of the Target.
位置ジェネレータ（LG）：最初に決定するか、または標的の位置を収集し、ターゲットの位置を記述する位置オブジェクトを作成するエンティティ。
Location Object (LO): An object conveying location information (and possibly privacy rules) to which Geopriv security mechanisms and privacy rules are to be applied.
位置オブジェクト（LO）：Geoprivセキュリティメカニズムとプライバシールールが適用される先の位置情報（及びおそらくプライバシー規則）を搬送するオブジェクト。
Location Recipient (LR): The entity that receives location information. It may have asked for this location explicitly (by sending a query to a location server), or it may receive this location asynchronously.
位置受信者（LR）：ロケーション情報を受信エンティティ。これは、（ロケーションサーバへのクエリを送信することにより）明示的にこの場所を求めている場合もあれば、非同期的にこの場所を受け取ることができます。
Location Server (LS): The entity to which a LG publishes location objects, the recipient of queries from location receivers, and the entity that applies rules designed by the rule maker.
ロケーションサーバ（LS）：LGがロケーションオブジェクト、位置受信機からの問い合わせの受信者、およびルールメーカーによって設計ルールを適用するエンティティを発行したエンティティ。
Precision: The number of significant digits to which a value has been reliably measured.
精度：値が確実に測定された有効桁数。
Principal: The holder/subject of the credentials, e.g., a workstation user or a network server.
プリンシパル：クレデンシャルの所有者/被検体、例えば、ワークステーションのユーザまたはネットワーク・サーバ。
Resolution: The fineness of detail that can be distinguished in a measured area. Applied to Geopriv this means the finite area within provided and closed borders (ex. Latitude and Longitude boundaries).
解像度：測定領域に区別することができる詳細の細かさ。これが提供され、閉じた国境（例：緯度と経度の境界）内の有限の面積を意味するGeoprivに適用されます。
Rule Holder: The entity that provides the rules associated with a particular target for the distribution of location information. It may either 'push' rules to a location server, or a location server may 'pull' rules from the Rule Holder.
ルールホルダー：位置情報の配信のために特定のターゲットに関連する規則を提供するエンティティ。これは、ロケーションサーバのいずれかに「プッシュ」ルールたり、ロケーションサーバは、ルールホルダーからのルール「を引く」ことがあります。
Rule Maker: The authority that creates rules governing access to location information for a target (typically, this it the target themselves).
ルールメーカー：ターゲットの位置情報へのアクセスを管理する規則を作成する権限が（一般的に、これはターゲット自身がそれ）。
Rule, or Privacy Rule: A directive that regulates an entity's activities with respect to location information, including the collection, use, disclosure, and retention of location information.
ルール、またはプライバシールール：収集、使用、開示、および位置情報の保持などの位置情報、に関して、企業の活動を規制する指令。
Target: A person or other entity whose location is communicated by a Geopriv Location Object.
ターゲット：その場所Geopriv場所オブジェクトによって通信される個人またはその他のエンティティ。
Using Protocol: A protocol that carries a Location Object.
Locationオブジェクトを運ぶプロトコル：プロトコルを使用しました。
Viewer: A Principal that consumes location information that is communicated by a Geopriv Location Object, but does not pass this information further.
ビューア：Geoprivロケーションオブジェクトによって伝達される位置情報を消費するが、さらにこの情報を渡さないプリンシパル。
Resolution and Precision are very close terms. Either quality can be 'reduced' to coarsen location information: 'resolution' by defining a off-center perimeter around a user's location or otherwise enlarging the area in consideration (from state to country, say) and 'precision' by discarding significant digits of positioning information (rounding off longitude and latitude from seconds to minutes, say). Another WG document discusses this topic in much more detail.
解像度と精度が非常に近い用語です。の有効桁数を廃棄することによって（状態から国へ、言う）ユーザの位置の周りに中心を外れた周囲を画定するか、そうでなければ考慮して面積を拡大して「解像度」と「精度」：いずれかの品質は、位置情報を粗大化するために「縮小」することができます情報を配置（秒単位から分単位に経度と緯度を丸め、言います）。別のWGの文書は、はるかに詳細に、このトピックについて説明します。
The following picture shows the primary Geopriv entities in a simple and basic architecture, without claim of completeness or any suggestion that the entities identified must in all cases be physically separate entities.
次の絵は、完全または識別されたエンティティは、すべての場合において、物理的に別個のエンティティである必要があることを示唆任意の請求なしに、単純かつ基本的なアーキテクチャの主要Geoprivエンティティを示しています。
+----------+
| Rule |
| Holder |
| |
+----+-----+
|
rule|interface
V
+----------+ +----------+ +----------+
|Location | publication | Location | notification |Location |
|Generator +-------------->| Server +-------------->|Recipient |
| | interface | | interface | |
+----------+ +----------+ +----------+
The four primary Entities are described as follows:
以下のような4つの主要事業体が記述されています。
Location Generator (LG): The entity that initially determines or gathers the location of the Target and creates Location Objects describing that location. LGs publish Location Objects to Location Servers. The manner in which the Location Generator learns of Location Information is outside the scope of the Geopriv Protocol.
位置ジェネレータ（LG）：最初に決定するか、または標的の位置を収集し、その位置を記述する位置オブジェクトを作成するエンティティ。 LGSは、ロケーションサーバにロケーションオブジェクトを公開します。ロケーションジェネレータ位置情報を学習する方法はGeopriv議定書の範囲外です。
Location Server (LS): The LS is an element that receives publications of Location Objects from Location Generators and may receive subscriptions from Location Recipients. The LS applies the rules (which it learns from the Rule Holder) to LOs it receives from LGs, and then notifies LRs of resulting LOs as necessary.
ロケーションサーバ（LS）：LSは、ロケーションジェネレータから位置オブジェクトの刊行物を受信し、位置受信者からのサブスクリプションを受信することができる元素です。 LSは、LGSから受信し、必要に応じてのLOを得られるの尤度比を通知LOSが（それがルールホルダから学習する）ルールを適用します。
Location Recipient (LR): The LR is an element that receives notifications of Location Objects from Location Servers. The LR may render these LOs to a user or automaton in some fashion.
場所受信者（LR）：LRは、ロケーションサーバからロケーションオブジェクトの通知を受け取る要素です。 LRは、何らかの方法でユーザやオートマトンにこれらのLOをレンダリングすることがあります。
Rule Holder (RH): The RH is an element that houses Privacy Rules for receiving, filtering and distributing Location Objects for specific Targets. An LS may query an RH for a set of rules, or rules may be pushed from the RH to an LS. The rules in the Rule Holder are populated by the Rule Maker.
ルールホルダー（RH）：RHは、特定のターゲットのための場所のオブジェクトを、受信フィルタリングおよび配布するための個人情報保護規程を収容する要素です。 LSは、ルールのセットに対してRHを照会することができる、またはルールがLSにRHからプッシュされてもよいです。ルールホルダーのルールは、ルールメーカーによって移入されています。
Thus Location Generation is the process of gathering Location Information, perhaps from multiple sources, at an IP-based Geopriv Entity, the LG, which communicates with other Geopriv Entities.
従って場所生成は他のGeoprivエンティティと通信IPベースGeoprivエンティティ、LG、で、おそらく複数のソースから、位置情報を収集する処理です。
Rules MUST be authenticated and protected. How this is done and in particular how to distribute the keys to the RM and other authorities is outside of the scope of this document. See also Section 8.2, "Securing the Privacy Rules".
ルールは、認証され、保護されなければなりません。どのようにこれが行われ、特にRMおよびその他の当局への鍵を配布する方法は、この文書の範囲外です。 「個人情報保護規則の保護」、また、8.2節を参照してください。
The interfaces between the Geopriv entities are not necessarily protocol interfaces; they could be internal interfaces within a single composed device. In some architectures, the Location Generator, Rule Holder, and Location Server might all be implemented in the same device. There may be several Rule Holders that enforce the Privacy Rules at a particular Location Server.
Geoprivエンティティ間のインターフェイスは、必ずしもプロトコルインタフェースではありません。彼らは、単一の合成装置内の内部インタフェースであってもよいです。いくつかのアーキテクチャでは、場所ジェネレーター、ルールホルダー、およびロケーションサーバはすべて同じデバイスに実装される可能性があります。特定のロケーションサーバでプライバシー規則を施行するいくつかのルールホルダーがあるかもしれません。
The terminology and definitions detailed below include both terms that, besides the primary Geopriv entities, (1) are used in the requirements section of this document, and (2) provide additional detail about the usage model envisioned for the Geopriv Location Object. These latter terms will be utilized in a separate scenarios document and elsewhere.
以下に詳述する用語及び定義は、両方の用語を含むことが、一次Geoprivエンティティに加え、（1）本文書の要件セクションで使用され、（2）Geoprivロケーションオブジェクトの想定使用モデルに関する追加の詳細を提供します。これらの後者の条件は、個別のシナリオ文書と他の場所で利用されるであろう。
The focus of the Geopriv working group is on information about a Target's location that is NOT based on generally or publicly available sources, but instead on private information provided or created by a Target, a Target's Device, or a Target's network or service provider. Notwithstanding this focus on private location information, the Geopriv Location Object could certainly be used to convey location information from publicly available sources.
Geoprivワーキンググループの焦点は、一般的にまたは公に利用可能なソースに基づいて、その代わりに、個人情報にターゲット、ターゲットのデバイス、または対象のネットワークやサービスプロバイダによって提供されるか、または作成されていない対象者の位置情報にあります。プライベートな位置情報でこのフォーカスにもかかわらず、Geopriv場所オブジェクトは確かに公に利用可能なソースからの位置情報を伝えるために使用することができます。
Location Information: A relatively specific way of describing where a Device is located.
位置情報：デバイスがどこにある記述の比較的特異的な方法。
This Location Information may have been determined in many different ways, including:
この位置情報を含む多くの異なる方法で決定されている場合があります。
(a) derived or computed from information generally not available to the general public (such as information mainly available to a network or service provider), (b) determined by a Device that may not be generally publicly addressable or accessible, or (c) input or otherwise provided by a Target.
（A）（B）は、一般に公にアドレス可能又はアクセス可能である、または（c）ではないことがあり、デバイスによって決まる（例えば、ネットワークまたはサービスプロバイダに主に利用可能な情報など）は、一般公衆に利用可能ではない一般情報から導出又は計算入力または他のターゲットによって提供されます。
As examples, the Location Information could include (a) information calculated by triangulating on a wireless signal with respect to cell phone towers, (b) longitude and latitude information determined by a Device with GPS (global positioning satellite) capabilities, (c) information manually entered into a cell phone or laptop by a Target in response to a query, or (d) automatically delivered by some other IP protocol, such as at device configuration via DHCP.
例として、位置情報は、GPS（全地球測位衛星）機能、（c）の情報を有する装置によって決定（a）は携帯電話塔に対して無線信号を三角測量によって計算された情報、（b）は、経度と緯度の情報を含むことができます手動でクエリに応答して対象者の携帯電話やノートパソコンに入力され、または（d）のように自動的にDHCPを介して装置構成でのように、いくつかの他のIPプロトコルによって配信。
Excluded from this definition is the determination of location information wholly without the knowledge or consent of the Target (or the Target's network or access service provider), based on generally available information such as an IP or e-mail address. In some cases, information like IP address can enable someone to estimate (at least roughly) a location. Commercial services exist that provide rough location information based on IP addresses. Currently, this type of location information is typically less precise than the type of location information addressed in this document. Although this type of location computation still raises significant potential privacy and public privacy concerns, such scenarios are generally outside the scope of this document.
この定義から、このようなIPや電子メールアドレスなどの一般的に入手可能な情報に基づいて、対象（又は対象者のネットワークまたはアクセス・サービス・プロバイダ）の知識や同意なしに完全に位置情報の決意である除外。いくつかのケースでは、IPアドレスのような情報は、（少なくともおおよそ）位置を推定するために誰かを可能にすることができます。商用サービスは、IPアドレスに基づいて、大まかな位置情報を提供する存在します。現在、位置情報のこのタイプは、典型的には、本文書にアドレスされた位置情報の種類よりも少ない正確です。位置計算のこのタイプは、まだ大きな潜在的可能性、プライバシーや公共プライバシーの問題を提起するが、このようなシナリオは、この文書の範囲外で、一般的です。
Within any given location-based transaction, the INITIAL determination of location (and thus the initial creation of Location Information) is termed a Sighting:
任意の所与のロケーションベースのトランザクション内で、最初の位置の決意（したがって、位置情報の初期の作成）が照準と呼ばれます。
Sighting: The initial determination of location based on non-public information (as discussed in the definition of Location Information), and the initial creation of Location Information.
照準：非公開情報（位置情報の定義で説明したように）、及び位置情報の初期の作成に基づいて位置の初期決意。
Some variant of the sighting information is included in the Location Object. Abstractly, it consists of two separate data fields:
目撃情報の一部の変異体は、場所オブジェクトに含まれています。抽象的に、それは、2つの個別のデータフィールドで構成されています。
(Identifier, Location)
（識別子、場所）
where Identifier is the identifier assigned to a Target being sighted, and Location is the current position of that Target being sighted. Not all entities may have access to exactly the same piece of sighting information. A sighting may be transformed to a new sighting pair:
識別子が目撃される標的に割り当てられた識別子であり、場所はそのターゲットの現在位置が照準されている場合。いないすべてのエンティティは、情報を照準の正確に同じ部分にアクセスすることができます。目撃情報は、新しい照準ペアに変換することができます。
(Identifier-1, Location-1)
（特定-1レント1）
before it is provided by a Location Generator or Location Server to Location Recipient. In this case, Identifier-1 may be a Pseudonym, and Location-1 may have less precision or resolution than the original value.
それは場所の受信者に場所ジェネレータまたはロケーションサーバによって提供される前に。この場合、識別子-1は、偽名であってもよく、ロケーション1は、元の値よりも低い精度または分解能を有していてもよいです。
A main goal of the Geopriv working group is to define a Location Object (LO), to be used to convey both Location Information and basic privacy-protecting instructions:
Geoprivワーキンググループの主な目標は、位置情報及び基本的なプライバシー保護命令の両方を伝えるために使用される場所オブジェクト（LO）を定義することです。
Location Object (LO): This data contains the Location Information of the Target, and other fields including an identity or pseudonym of the Target, time information, core Privacy Rules, authenticators, etc. Most of the fields are optional, including the Location Information itself.
場所オブジェクト（LO）：このデータは、ターゲットの位置情報が含まれており、同一性または仮名対象の、時間情報、コア個人情報保護規程、認証トークンなどを含む他のフィールドは、フィールドのほとんどは、位置情報を含め、オプションであります自体。
Nothing is said about the semantics of a missing field. For instance, a partially filled object MAY be understood implicitly as a request to complete it. Or, if no time information is included, this MAY implicitly mean "at the current time" or "at a very recent time", but it could be interpreted in a different way, depending on the context.
何も不足しているフィールドの意味については述べられていません。例えば、部分的に充填されたオブジェクトは、それを完了するための要求として暗黙的に理解することができます。またはNO時刻情報が含まれていない場合、これは暗黙的に「非常に最近の時」または「現時点で」を意味するかもしれないが、それは、コンテキストに応じて、異なる方法で解釈することができます。
The "using protocol" is the protocol that uses (reads or modifies) the Location Object. A protocol that just transports the LO as a string of bits, without looking at them (like an IP storage protocol could do), is not a using protocol, but only a transport protocol. Nevertheless, the entity or protocol that caused the transport protocol to move the LO is responsible for the appropriate distribution, protection, usage, retention, and storage of the LO based on the rules that apply to that LO.
「プロトコルを使用する」（読み取りまたは変更）ロケーションオブジェクトを使用するプロトコルです。ちょうどビット列としてLOを搬送するプロトコルは、（IPストレージプロトコルと同様に行うことができ）、それらを見ることなく、使用したプロトコルが、唯一のトランスポートプロトコルではありません。それにもかかわらず、トランスポートプロトコルはLOを移動させるエンティティまたはプロトコルが適切な分布、保護、使用、保持、およびそのLOに適用されるルールに基づいて、LOの記憶を担っています。
The security and privacy enhancing mechanisms used to protect the LO are of two types: First, the Location Object definition MUST include the fields or mechanisms used to secure the LO as such. The LO MAY be secured, for example, using cryptographic checksums or encryption as part of the LO itself. Second, the using protocol may also provide security mechanisms to securely transport the Location Object.
LOを保護するために使用されるセキュリティおよびプライバシー強化メカニズムは、2つのタイプがある：まず、ロケーション・オブジェクト定義のようなLOを固定するために使用されるフィールドまたは機構を含まなければなりません。 LOは、LO自体の一部として、暗号チェックサムまたは暗号化を使用して、例えば、固定されてもよいです。第二に、使用プロトコルは、安全場所オブジェクトを転送するセキュリティメカニズムを提供してもよいです。
When defining the LO, the design should observe that the security mechanisms of the Location Object itself are to be preferred. Thus the definition of the LO MUST include some minimal crypto functionality (Req. 14 and 15). Moreover, if the RM specifies the use of a particular LO security mechanism, it MUST be used (Req. 4).
LOを定義する場合、設計は、位置オブジェクト自体のセキュリティメカニズムが好ましいことがあることを観察すべきです。従ってLOの定義は、いくつかの最小暗号機能（必須14および15）を含まなければなりません。 RMは、特定のLOのセキュリティメカニズムの使用を指定している場合また、それを使用しなければならない（必須4）。
Location information can be used in very different environments. In some cases, the participants will have longstanding relationships, while in others the participants may have discrete interactions with no prior contractual or other contact.
位置情報は非常に異なる環境で使用することができます。他の人の参加者がいない前に、契約またはその他の連絡先との個別の相互作用を持っているかもしれないが、いくつかのケースでは、参加者は、長年の関係を持っています。
The different relationships raise different concerns for the implementation of privacy rules, including the need to communicate Privacy Rules. A public Rule Holder, for example, may be unnecessary in a trusted environment where more efficient methods of addressing privacy issues exist. The following terms distinguish between the two basic types of data flows:
別の関係は、個人情報保護のルールを通信する必要性を含むプライバシー規則の実施のためのさまざまな懸念を上げます。公共のルールホルダーは、例えば、プライバシーの問題に対処するより効率的な方法が存在する信頼できる環境でなくてもよいです。次の用語は、データフローの2つの基本的な種類を区別します：
Trusted Data Flow: A data flow that is governed by a pre-existing contractual relationship that addresses location privacy.
信頼できるデータフロー：ロケーションプライバシーを扱う既存の契約関係によって支配されたデータの流れ。
Non-trusted Data Flow: The data flow is not governed by a pre-existing contractual relationship that addresses location privacy.
非信頼できるデータフロー：データフローは、位置プライバシーを扱う既存の契約関係によって支配されていません。
Target:
The entity whose location is desired by the Location Recipient.
In many cases the Target will be the human "user" of a Device
or an object such as a vehicle or shipping container to which
the Device is attached. In some instances the Target will be
the Device itself.
Device: The technical device whereby the location is tracked as a proxy for the location of a Target.
装置：位置がターゲットの場所のためのプロキシとして追跡される技術的装置。
A Device might, for example, be a cell phone, a Global Positioning Satellite (GPS) receiver, a laptop equipped with a wireless access Device, or a transmitter that emits a signal that can be tracked or located. In some situations, such as when a Target manually inputs location information (perhaps with a web browser), the Target is effectively performing the function of a Device.
装置は、例えば、携帯電話、全地球測位衛星（GPS）受信機、無線アクセス装置を備えたラップトップ、または追跡又は配置することができる信号を発する送信機であるかもしれません。このような標的は、手動で（おそらくWebブラウザで）位置情報を入力するようないくつかの状況では、対象を効果的に装置の機能を実行しています。
Rule Maker (RM): The individual or entity that has the authorization to set the applicable Privacy Rules for a potential Geopriv Target. In many cases this will be the owner of the Device, and in other cases this may be the user who is in possession of the Device. For example, parents may control what happens to the location information derived from a child's cell phone. A company, in contrast, may own and provide a cell phone to an employee but permit the employee to set the privacy rules.
ルールメーカー（RM）：潜在的なGeoprivターゲットに適用可能なプライバシー規則を設定する権限を持っている個人または法人。多くの場合、これは、デバイスの所有者となり、他の場合にはこれは、デバイスの所有しているユーザであってもよいです。例えば、親が子供の携帯電話から得られる位置情報に何が起こるかを制御することができます。同社は、対照的に、所有して従業員に携帯電話を提供しますが、プライバシー規則を設定するために従業員を許可します。
There are four scenarios in which some form of constraint or override might be placed on the Privacy Rules of the Rule Maker:
制約またはオーバーライドのいくつかのフォームは、ルールメーカーのプライバシー規則に置かれるかもしれない4つのシナリオがあります。
1. In the case of emergency services (such as E911 within the United States), local or national laws may require that accurate location information be transmitted in certain defined emergency call situations. The Geopriv Working Group MUST facilitate this situation.
（例えば米国内E911など）緊急サービス、地域または国の法律の場合1.正確な位置情報を特定の定義緊急通報の状況で送信することを要求することができます。 Geoprivワーキンググループは、このような状況を容易にしなければなりません。
2. In the case of legal interception, the RM may not be aware of an override directive imposed by a legal authority. It is not the expectation of the Working Group that a particular accommodation will be made to facilitate this situation.
法的傍受の場合は2、RMは法的権限によって課さoverride指令を認識しないかもしれません。これは、特定の宿泊この状況を容易にするために行われることを作業部会の期待ではありません。
3. In the context of an employment relationship or other contractual relationship, the owner of a particular location (such as a corporate campus) may impose constraints on the use of Privacy Rules by a Rule Maker. It is not the expectation of the Working Group that a particular accommodation will be made to facilitate this situation.
雇用関係または他の契約関係の文脈において3、（例えば、企業の構内のような）特定の場所の所有者は、ルールメーカーによるプライバシー規則の使用に制約を課すことができます。これは、特定の宿泊この状況を容易にするために行われることを作業部会の期待ではありません。
4. It is conceivable that a governmental authority may seek to impose constraints on the use of Privacy Rules by a Rule Maker in non-emergency situations. It is not the expectation of the Working Group that a particular accommodation will be made to facilitate this situation.
4.政府当局は、非緊急事態におけるルールメーカーによる個人情報保護ルールの使用上の制約を課すことを求めることができると考えられます。これは、特定の宿泊この状況を容易にするために行われることを作業部会の期待ではありません。
Viewer: An individual or entity who receives location data about a Target and does not transmit the location information or information based on the Target's location (such as driving directions to or from the Target) to any party OTHER than the Target or the Rule Maker.
ビューア：ターゲットに関する位置データを受信して、ターゲットの位置に基づいて位置情報や情報を送信しない個人や組織目標やルールのメーカー以外の第三者に（例えば、標的へまたはからの指示を運転など）。
Data Transporter: An entity or network that receives and forwards data without processing or altering it. A Data Transporter could theoretically be involved in almost any transmission between a Device and a Location Server, a Location Server and a second Location Server, or a Location Server and a Viewer. Some location tracking scenarios may not involve a Data Transporter.
データトランスポーター：処理又はそれを変更することなく、受信し、転送するデータエンティティ又はネットワーク。データトランスポーターは、理論的デバイスとロケーションサーバ、ロケーションサーバと第2ロケーションサーバまたはロケーションサーバとビューアとの間のほぼすべての伝達に関与することができます。いくつかの位置追跡のシナリオは、データのトランスポーターが関与しないことがあります。
Access Provider (AP): The domain that provides the initial network access or other data communications services essential for the operation of communications functions of the Device or computer equipment in which the Device operates. Often, the AP -- which will be a wireless carrier, an Internet Service Provider, or an internal corporate network -- contains the LG. Sometimes the AP has a "dumb" LG, one that transmits Geopriv LOs but does not use any part of the Geopriv Location Object. Other cases may not involve any AP, or the AP may only act as a Data Transporter.
アクセス・プロバイダ（AP）：デバイスが動作するデバイスまたはコンピュータ機器の通信機能の動作に不可欠な初期ネットワークアクセスまたは他のデータ通信サービスを提供するドメイン。多くの場合、AP - 無線キャリア、インターネット・サービス・プロバイダー、または社内ネットワークになります - LGが含まれています。時には、APは「ダム」LG、GeoprivのLOを送信しますがGeopriv場所オブジェクトのどの部分を使用していないものを持っています。他の例には、任意のAPを伴わないこと、またはAPは、データのみのトランスポーターとして作用することができます。
Location Storage: A Device or entity that stores raw or processed Location Information, such as a database, for any period of time longer than the duration necessary to complete an immediate transaction regarding the Location Information.
位置記憶：長い位置情報に関する直接の取引を完了するために必要な時間よりも任意の期間のために、データベースなどの生又は加工位置情報を、格納デバイスまたはエンティティ。
The existence and data storage practices of Location Storage is crucial to privacy considerations, because this may influence what Location Information could eventually be revealed (through later distribution, technical breach, or legal processes).
この場所の情報は、最終的に（後に配布、技術的な違反、または法的プロセスを通じて）明らかにすることができるもの影響を及ぼす可能性があるので、場所ストレージの有無やデータストレージ慣行は、プライバシーの配慮に不可欠です。
Privacy Rules are rules that regulate an entity's activities with respect to location and other information, including, but not limited to, the collection, use, disclosure, and retention of location information. Such rules are generally based on fair information practices, as detailed in (for example) the OECD Guidelines on the Protection of Privacy and Transporter Flows of Personal Data [OECD].
プライバシールールは、場所とを含む他の情報、に関して、企業の活動を規制するルールですが、収集、使用、開示、および位置情報の保持、これらに限定されません。個人データのプライバシー及びトランスポーターフローの保護[OECD]上の（例えば）OECDガイドラインに詳述するように、そのようなルールは、一般的に、公正な情報プラクティスに基づいています。
Privacy Rule: A rule or set of rules that regulate an entity's activities with respect to location information, including the collection, use, disclosure, and retention of location information. In particular, the Rule describes how location information may be used by an entity and which transformed location information may be released to which entities under which conditions. Rules must be obeyed; they are not advisory.
プライバシールール：ルールや収集、使用、開示、および位置情報の保持などの位置情報、に関して、企業の活動を規制するルールのセット。具体的には、ルールは、位置情報は、エンティティによって使用されることができる方法について説明した情報がへ条件下エンティティに放出することができる場所を変えています。ルールは従わなければなりません。彼らは助言ではありません。
A full set of Privacy Rules will likely include both rules that have only one possible technical meaning, and rules that will be affected by a locality's prevailing laws and customs. For example, a distribution rule of the form "my location can only be disclosed to the owner of such credentials and in such precision or resolution" has clear-cut implications for the protocol that uses the LO. But other rules, like retention or usage Rules, may have unclear technical consequences for the protocol or for the involved entities. For example, the precise scope of a retention rule stating "you may not store my location for more than 2 days" may in part turn on local laws or customs.
プライバシールールのフルセットは、おそらく唯一の可能な技術的な意味を持ち、ルール、および地域の現行の法律や習慣によって影響されるルールの両方が含まれます。例えば、「私の位置のみ、このようなクレデンシャルの所有者に、そのような精度または解像度に開示されていることができる」フォームの分布ルールがLOを使用するプロトコルの明確な意味を有します。しかし、他のルールは、保持または使用ルールのように、プロトコルまたは関与するエンティティのための不明瞭な技術的な結果をもたらす可能性があります。たとえば、保持ルールの正確な範囲は、現地の法律や慣習上のかもしれない部分でターン「あなたは2日以上のための私の場所を格納しないかもしれません」述べました。
Anonymity is the property of being not identifiable (within a set of subjects). Anonymity serves as the base case for privacy: without the ability to remain anonymous, individuals may be unable to control their own privacy. Unlinkability ensures that a user may make multiple uses of resources or services without others being able to link these uses to each other. Unlinkability requires that entities be unable to determine whether the same user caused certain specific operations in the system. [ISO99] A pseudonym is simply a bit string which is unique as an ID and is suitable to be used for end-point authentication.
匿名性は、（サブジェクトのセット内で）識別可能でないという特性です。匿名性は、プライバシーのためのベースケースとして機能します：匿名のままにする能力なしに、個人が自分のプライバシーを制御することができない場合があります。リンク不能性は、ユーザーが他の人がお互いにこれらの用途をリンクできず、リソースやサービスの複数使用を行うことができることを保証します。リンク不能性は、エンティティが同一のユーザがシステム内の特定の具体的な動作を引き起こしか否かを決定することができないことを要求します。 [ISO99] A偽名は、単にIDとしてユニークであり、エンドポイント認証に使用するのに適しているビット列です。
Unlinked Pseudonym: A pseudonym where the linking between the pseudonym and its holder is, at least initially, not known to anybody with the possible exception of the holder himself or a trusted server of the user. See [Pfi01] (there the term is called Initially Unlinked Pseudonym).
リンクされていないペンネーム：仮名とそのホルダとの間の連結は、少なくとも最初は、ホルダ自身またはユーザの信頼されたサーバーの可能性を除いて誰にも知られていない仮名。 （そこ用語が最初にリンクされていないペンネームと呼ばれている）[Pfi01]を参照してください。
The word authentication is used in different manners. Some require that authentication associates an entity with a more or less well-known identity. This basically means that if A authenticates another entity B as being "id-B", then the label "id-B" is a well-known, or at least a linkable identity of the entity. In this case, the label "id-B" is called a publicly known identifier, and the authentication is "explicit":
ワード認証は異なる方法で使用されています。いくつかは、認証が多かれ少なかれ、よく知られたアイデンティティを持つエンティティを関連付けることが必要です。これは基本的にAが「ID-B」であるような別のエンティティBを認証する場合、ラベル「ID-B」がよく知られている、またはエンティティの少なくとも架橋性同一であることを意味します。この場合、ラベル「ID-B」は、公知の識別子と呼ばれ、認証が「明示的」です。
Explicit Authentication: The act of verifying a claimed identity as the sole originator of a message (message authentication) or as the end-point of a channel (entity authentication). Moreover, this identity is easily linked back to the real identity of the entity in question, for instance being a pre-existing static label from a predefined name space (telephone number, name, etc.)
明示的な認証：メッセージ（メッセージ認証）の唯一の発信元として主張する識別情報を検証する行為またはチャネルのエンドポイントとして（エンティティ認証）。また、この識別は容易に、例えば、当該エンティティの正体に戻るリンクされている事前定義された名前空間（電話番号、名前、等）から既存の静的ラベルであります
Authorization: The act of determining if a particular right, such as access to some resource, can be granted to the presenter of a particular credential.
認証：あれば、このようないくつかのリソースへのアクセスなど、特定の権利を、決定の行為は、特定の資格のプレゼンターに付与することができます。
Depending on the type of credential, authorization may or may not imply Explicit Authentication.
資格の種類に応じて、許可がまたは明示的な認証を意味するものではない場合があります。
In this subsection we introduce short scenarios to illustrate how these terms and attributes describe location information transactions. Additional illustrative scenarios are discussed in a separate document.
このサブセクションでは、これらの用語および属性は、位置情報の取引を記述する方法を説明するために、短いシナリオを紹介します。追加の説明のシナリオは別の文書で説明されています。
SCENARIO 1: GPS Device with Internal Computing Power: Closed System
シナリオ1：内部コンピューティングパワーを持つGPSデバイス：クローズドシステム
In this example, the Target wishes to know his/her location using the Global Positioning System (GPS) and the Device is capable of independently processing the raw data to determine its location. The location is derived as follows: the Device receives transmissions from the GPS satellites, internally computes and displays location. This is a closed system. For the purpose of this and subsequent examples, it is assumed that the GPS satellite broadcasts some signal, and has no information about the identity or whereabouts of Devices using the signal.
この例では、ターゲットは、全地球測位システム（GPS）を使用して、彼/彼女の位置を知ることを望むデバイスは、独立してその位置を決定するために、生データを処理することができます。デバイスは、内部計算し、位置を表示、GPS衛星からの送信を受信する次のように位置が導出されます。これはクローズドシステムです。これとその後の例の目的のためには、GPS衛星は、いくつかの信号をブロードキャストし、同一性または信号を使用してデバイスの所在に関する情報がありませんと仮定しています。
GPS Satellite
|
| Sighting (not a Geopriv Interface)
|
|
|
V GPS Device
--------------------------------------------------
/ \
| Location ----- Location ----- Location |
| Generator Server Storage |
\ | /
-------------------------------------------|------
|
| Notification
| Interface
|
------------|------
/ V \
/ Target Location \
| Recipient |
| |
\ Rule Maker /
\ /
-------------------
In this scenario the GPS Device is both the AP and the LG. The interaction occurs in a Trusted environment because it occurs in the Rule Maker's Device.
このシナリオでは、GPSデバイスは、APとLGの両方です。それはルールメーカーのデバイスで発生するため、相互作用は、信頼できる環境で発生します。
SCENARIO 2: Cell Phone Roaming
シナリオ2：携帯電話のローミング
In this example, a cell phone is used outside its home service area (roaming). Also, the cell phone service provider (cell phone Corp 2) outsourced the accounting of cell phone usage. The cell phone is not GPS-enabled. Location is derived by the cell phone network in which the Target and Device are roaming. When the Target wishes to use the cell phone, cell phone Corp 1 (AP) provides the roaming service for the Target, which sends the raw data about usage (e.g., duration of call, location in the roaming network, etc.) to cell phone Corp 2, the home service provider. Cell phone Corp 2 submits the raw data to the accounting company, which processes the raw data for the accounting statements. Finally, the raw data is sent to a data warehouse where the raw data is stored in a Location Server (e.g., computer server).
この例では、携帯電話は、そのホームサービスエリア（ローミング）外で使用されています。また、携帯電話サービスプロバイダ（携帯電話コープ2）は、携帯電話の使用の会計処理を外部に委託しました。携帯電話はGPS対応ではありません。ロケーションは、ターゲットデバイスがローミングしている携帯電話ネットワークによって導出されます。ターゲットは、携帯電話を使用したい場合、携帯電話社1（AP）は、使用（例えば、通話時間、ローミングネットワーク、等に位置）に関する生データを送信し、ターゲットに対するローミングサービスを提供するセルへ電話コープ2、ホームサービスプロバイダ。携帯電話コープ2は、会計書類の生データを処理し、会計会社、に生データを送信します。最後に、生データは、生データをロケーションサーバ（例えば、コンピュータサーバ）に格納されたデータウェアハウスに送られます。
Cell Phone Corp 1 Cell Phone Corp 2
----------------- -----------------
Sighting / \ Publish / \
Device ----- | Data Transporter | --------- | Data Transporter |
Target \ / Interface \ /
----------------- / -----------------
/ |
/ | Notification
/ | Interface
----------- |
/ V
------------ / ----------
/ \ / / \
/ Location \ / | Location |
| Storage | Location Info | Storage |
| |<----------------- | |
| Location | | Location |
| Recipient | | Recipient |
\ / \ /
------------- ----------
Here, cell phone Corp 1 is the AP and the LG. In this scenario, Cell phone Corp 2 is likely to be a Trusted entity, but cell phone Corp 1 may be Non-trusted.
ここでは、携帯電話のコープ1は、APとLGです。このシナリオでは、携帯電話のコープ2は、信頼できるエンティティである可能性が高いですが、携帯電話のコープ1は、非信頼できるかもしれません。
SCENARIO 3: Mobile Communities and Location-Based Services
シナリオ3：モバイルコミュニティとロケーションベースのサービス
The figure below shows a common scenario, where a user wants to find his friends or colleagues or wants to share his position with them or with a Location-Based Service Provider. Some of the messages use a Location Object to carry, for instance, identities or pseudonyms, credentials and proof-of-possession of them, Rules and Location Data Information, including Data Types and Precision or Resolution. Messages that do not use the Location Object and are outside of the scope of the Geopriv WG, but should be mentioned for understandability, are shown in the figure as starred arrows ("***>").
下の図は、ユーザーが自分の友人や同僚を見つけたいか、彼らと一緒にまたはロケーションベースサービスプロバイダとの彼の位置を共有することを望んでいる一般的なシナリオを示しています。メッセージのいくつかは、例えば、アイデンティティや仮名、資格情報と実証の所持データ型と精度や解像度など、ルールと場所データ情報、彼らのために、実行する場所オブジェクトを使用しています。場所オブジェクトを使用して外部Geopriv WGの範囲であるが、わかりやすさのために言及されるべきでないメッセージは、主演の矢印（「***>」）として図に示されています。
+---------+ +------------+
| | | |
| Location|<** | Public |
|Generator| * | Rule Holder|
| | * | |
+---------+\ * +------------+
\ *3 1a* *
\ * * *
\ ** *
\ * * *1a
\* * *
* \ * *
* \ * *
* \4 * *
* \ * V
* \->+-----------+
+----------+ 1 | Location |
| Rule |--------------------->| Server + |
| Maker | | Private |
+----------+ |Rule Holder|
+-----------+
^ |
3| |5
| V
+----------+
| Location |
| Recipient|
+----------+
Assume that the Rule Maker and the Target are registered with the Location Server. The RM has somehow proven to the LS that he indeed is the owner of the privacy rights of the Target (the Target is usually a Device owned by the Rule Maker). The Rule Maker and the Location Server have agreed on the set of keys or credentials and cryptographic material that they will use to authenticate each other, and in particular, to authenticate or sign the Rules. How this has been done is outside of the scope of the document.
ルールメーカーとターゲットがロケーションサーバに登録されていることを前提としています。 RMは何とか彼は確かに（ターゲットは通常ルールのメーカーが所有するデバイスである）ターゲットのプライバシーの権利の所有者であることをLSに証明されています。ルールメーカーとロケーションサーバは、キーまたは資格情報のセットと、彼らは互いを認証し、特に、ルールを認証または署名するために使用する暗号化材料に合意しました。これはどのように行われている文書の範囲外です。
1: Rule Transfer: The Rule Maker sends a Rule to the Location Server. This Rule may or may not be a field in a Location Object.
1：ルールの転送：ルールメーカーロケーションサーバにルールを送信します。このルールは、または場所のオブジェクト内のフィールドであってもなくてもよいです。
1a:Signed Rule: As an alternative, the Rule Maker may write a Rule and place it in a Public Rule Holder. The entities access the repository to read the signed Rules.
図1a：署名ルール：別の方法として、ルールのメーカーは、ルールを記述することができ、公開ルールのホルダーに入れてください。エンティティが署名したルールを読み取るためのリポジトリにアクセスします。
2: Location Information Request: The Location Recipient requests location information for a Target. In this request, the Location Recipient may select which location information data type it prefers. One way of requesting Location Information MAY be sending a partially filled Location Object, including only the identities of the Target and Location Recipient and the desired Data Type and precision or resolution, and providing proof of possession of the required credentials. But whether or not the using protocol understands this partially filled object as a request MAY depend on the using protocol or on the context. The Location Recipient could also specify the need for periodic location information updates, but this is probably out of the scope of Geopriv.
2：位置情報要求：場所の受信者は、ターゲットの位置情報を要求します。この要求では、位置受信者は、それが好むた位置情報データタイプを選択することができます。位置情報を要求する一つの方法は、ターゲットと場所受信者の所望のデータ・タイプと精度や解像度の同一性のみを含む、部分的に満たされた場所のオブジェクトを送信し、必要な資格情報を所有していることの証明を提供するかもしれません。しかし、使用するプロトコルが理解するかどうかを要求として、この部分的に満たされたオブジェクトが使用してプロトコルや文脈に依存してもよいです。場所受信者はまた、定期的位置情報の更新の必要性を指定することができますが、これはGeoprivの範囲外である可能性があります。
3: Locate: When a Location Server receives a Location Information Request for a Target which has no current location information, the server may ask the Location Generator to locate the Target.
3：見つけます。ロケーションサーバは何の現在の位置情報を持っていないターゲットのための位置情報要求を受信すると、サーバがターゲットを見つけるために場所ジェネレーターを求めることができます。
4: Location Information: The Location Generator sends the "full" location information to the Location Server. This Location Information may or may not be embedded in a Location Object.
4：場所の情報：場所ジェネレーターは、ロケーションサーバへの「フル」位置情報を送信します。この位置情報は、または場所のオブジェクトに埋め込まれていてもいなくてもよいです。
5: Filtered Location Information: The Location Server sends the location information to the Location Recipient. The information may be filtered in the sense that in general a less precise or a computed version of the information is being delivered.
5：フィルタ場所の情報：ロケーションサーバは、場所の受信者に位置情報を送信します。情報は、一般的にあまり正確または情報の計算されたバージョンが配信されているという意味で濾過してもよいです。
Remember that this document is primarily specifying requirements on the definition of the LO. Some Requirements read like this: "The LO definition MUST contain Field 'A' as an optional field." This requirement states that
この文書は主にLOの定義上の要件を指定していることを覚えておいてください。いくつかの要件は、次のように読んで：「LOの定義は、オプションのフィールドとしてフィールド 『A』を含まなければなりません。」この要件は、と述べています
o the document that defines the LO MUST define the LO field 'A',
LOを定義文書は「A」LOフィールドを定義しなければならないO、
o the field 'A' MUST be defined as optional to use (an instance of a LO MAY or may not contain the field 'A').
フィールドO「」を使用するオプションとして定義されなければならない（LO MAYのインスタンスまたはフィールド「A」を含んでいてもよいです）。
Some Requirements read like this: "The LO definition MUST contain Field 'A', which MAY be an optional field." This requirement states that
いくつかの要件は、次のように読んで：「LOの定義はオプションのフィールドかもしれフィールド 『A』を含まなければなりません。」この要件は、と述べています
o the document that defines the LO MUST define the LO field 'A',
LOを定義文書は「A」LOフィールドを定義しなければならないO、
o the field 'A' MAY be defined as optional or not to use. If it is defined as optional to use, any instance of an LO MAY or may not contain the field 'A'; if it is not optional, all instances of LOs MUST contain the field 'A'.
フィールド「A」は使用するオプションやないとして定義することができるO。それはオプションとして定義されている場合、LO MAYの任意のインスタンスを使用するか、フィールド「A」を含んでいてもよいです。それがオプションでない場合は、ロスのすべてのインスタンスは、フィールド「A」を含まなければなりません。
Req. 1. (Location Object generalities)
必須。 1.（Locationオブジェクトの一般論）
1.1) Geopriv MUST define one Location Object (LO) -- both in syntax and semantics -- that must be supported by all Geopriv entities.
1.1）Geoprivは1つの場所オブジェクト（LO）を定義しなければならない - の両方の構文と意味で - すべてのGeoprivエンティティによってサポートされなければならないこと。
1.2) Some fields of the Location Object MAY be optional. This means that an instance of a Location Object MAY or may not contain the fields.
1.2）Locationオブジェクトの一部のフィールドは任意です。これは、場所オブジェクトのインスタンスがまたはフィールドを含んでも含まなくてもよいことを意味します。
1.3) Some fields of the Location Object MAY be defined as "extensions". This means that the syntax or semantics of these fields is not fully defined in the basic Location Object definition, but their use may be private to one or more of the using protocols.
1.3）Locationオブジェクトの一部のフィールドは、「エクステンション」として定義することができます。これは、これらのフィールドの構文や意味論は完全に基本的な場所オブジェクト定義で定義されていませんが、その使用は、使用してプロトコルの1つ以上にプライベートな可能性があることを意味します。
1.4) The Location Object MUST be extensible, allowing the definition of new attributes or fields.
1.4）ロケーション・オブジェクトは、新しい属性またはフィールドの定義を可能にする、拡張可能でなければなりません。
1.5) The object MUST be suitable for requesting and receiving a location.
1.5）オブジェクトは、ロケーションを要求し、受信に適していなければなりません。
1.6) The object MUST permit (but not require) the Privacy Rules to be enforced by a third party.
1.6））プライバシー規則を許可する（ただし、要求してはなりませんオブジェクトが第三者によって強制されます。
1.7) The object MUST be usable in a variety of protocols, such as HTTP and SIP, as well as local APIs.
1.7）オブジェクトは、HTTPやSIPなどのプロトコル、ならびにローカルのAPIの様々な使用可能でなければなりません。
1.8) The object MUST be usable in a secure manner even by applications on constrained devices.
1.8）オブジェクトも制約のあるデバイス上でアプリケーションが安全な方法で使用可能でなければなりません。
Req. 2. (Location Object fields) The Location Object definition MUST contain the following Fields, which MAY be optional to use:
必須。 2.（Locationオブジェクトフィールド）ロケーション・オブジェクト定義が使用するオプションとすることができる次のフィールドが、含まれている必要があります
2.1) Target Identifier
2.1）ターゲット識別子
2.2) Location Recipient Identity This identity may be a multicast or group identity, used to include the Location Object in multicast-based using protocols.
2.2）位置受信者アイデンティティは、この識別は、マルチキャストベースのプロトコルを使用して場所のオブジェクトを含めるために使用されるマルチキャストまたはグループIDであってもよいです。
2.3) Location Recipient Credential
2.3）場所受信者の資格
2.4) Location Recipient Proof-of-Possession of the Credential
2.4）場所受信者証明-の所持資格の
2.5) Location Field
2.5）ロケーションフィールド
2.5.1) Motion and direction vectors. This field MUST be optional.
2.5.1）の動きと方向ベクトル。このフィールドはオプションでなければなりません。
2.6) Location Data Type
2.6）位置データの種類
When transmitting the Location Object, the sender and the receiver must agree on the data type of the location information. The using protocol may specify that the data type information is part of the Location Object or that the sender and receiver have agreed on it before the actual data transfer.
Locationオブジェクトを送信する際、送信者と受信者は、位置情報のデータタイプに同意しなければなりません。用いたプロトコルは、データ型情報は、位置オブジェクトの一部であるか、または送信側と受信側が実際のデータ転送前に合意したことをことを指定することができます。
2.7) Timing information: (a) When was the Location Information accurate? (sighting time) (b) Until when considered current? TTL (Time-to-live) (This is different than a privacy rule setting a limit on data retention)
2.7）タイミング情報：（a）の場合には位置情報が正確でしたか？現在考慮されるときまで（照準時間）（b）は？ TTL（有効期間）（これは、データ保持の制限を設定するプライバシー規則とは異なります）
2.8) Rule Field: this field MAY be a referral to an applicable Rule (for instance, a URI to a full Rule), or it MAY contain a Limited Rule (see Req. 11), or both.
2.8）ルールフィールド：このフィールドはインスタンスの適用ルール（に紹介してもよいし、完全なルールへのURI）は、またはそれは（必須11参照）リミテッドルールが含まれている、またはその両方かもしれません。
2.9) Security-headers and -trailers (for instance encryption information, hashes, or signatures) (see Req. 14 and 15).
2.9）セキュリティヘッダと-trailers（例えば、暗号化情報、ハッシュ、または署名）（図14及び15のReqを参照されたいです）。
2.10) Version number
2.10）のバージョン番号
Req. 3. (Location Data Types)
必須。 3.（所在地データ型）
3.1) The Location Object MUST define at least one Location Data Type to be supported by all Geopriv receivers (entities that receive LOs).
3.1）ロケーションオブジェクトは、すべてのGeoprivレシーバ（LOSを受信エンティティ）によってサポートされる少なくとも一つの位置データタイプを定義しなければなりません。
3.2) The Location Object SHOULD define two Location Data Types: one for latitude / longitude / altitude coordinates and one for civil locations (City, Street, Number) supported by all Geopriv receivers (entities that receive LOs).
3.2）ロケーションオブジェクトは、二つの位置データ型を定義する必要があり：緯度/経度/高度座標用と市民の位置（都市、ストリート、数）のための1つは、すべてのGeoprivレシーバ（LOSを受信エンティティ）によって支持されています。
3.3) The latitude / longitude / altitude Data Type SHOULD also support a delta format in addition to an absolute one, used for the purpose of reducing the size of the packages or the security and confidentiality needs.
3.3）緯度/経度/高度データ型はまた、パッケージやセキュリティおよび機密性のニーズの大きさを減少させる目的で使用される絶対的なものに加えて、デルタ・フォーマットをサポートすべきです。
3.4) The Location Object definition SHOULD agree on further Location Data Types supported by some Geopriv entities and defined by other organizations.
3.4）Locationオブジェクト定義は、いくつかのGeoprivエンティティによってサポートされており、他の組織によって定義され、さらに場所データ型に合意すべきです。
Req. 4. The using protocol has to obey the privacy and security instructions coded in the Location Object and in the corresponding Rules regarding the transmission and storage of the LO.
必須。 4.使用してプロトコルは、ロケーション・オブジェクトおよびLOの伝送及び貯蔵に関する対応するルールで符号化されたプライバシーおよびセキュリティの命令に従うことを有しています。
Req. 5. The using protocol will typically facilitate that the keys associated with the credentials are transported to the respective parties, that is, key establishment is the responsibility of the using protocol.
必須。前記使用プロトコルは、典型的には、資格情報に関連付けられたキーがそれぞれの者に輸送されることを容易にする、つまり、鍵確立は、使用プロトコルの責任です。
Req. 6. (Single Message Transfer) In particular, for tracking of small target devices, the design should allow a single message/packet transmission of location as a complete transaction.
必須。 6.特に、（単一のメッセージの転送）は、小さなターゲットデバイスの追跡のために、設計は、完全なトランザクションとして位置の単一のメッセージ/パケットの送信を可能にすべきです。
Other requirements on the using protocol are out of the scope of this document, but might be the subject of future efforts from this working group. See also Section 9 (Protocol and LO Issues for later Consideration).
使用してプロトコル上のその他の要件は、この文書の範囲外であるが、このワーキンググループからの今後の取り組みの対象となるかもしれません。また、（後で検討のためのプロトコルとLOの問題）セクション9を参照してください。
Req. 7. (LS Rules) The decision of a Location Server to provide a Location Recipient access to Location Information MUST be based on Rule Maker-defined Privacy Rules.
必須。 7.（LSルール）位置情報を位置情報受信者のアクセスを提供するために、ロケーションサーバの決定は、ルールメーカーに定義された個人情報保護規程に基づいていなければなりません。
It is outside of our scope how Privacy Rules are managed and how a Location Server has access to the Privacy Rules. Note that it might be that some rules contain private information not intended for untrusted parties.
これは、個人情報保護のルールの管理方法を私たちの範囲の外にあり、ロケーションサーバは、プライバシー規則へのアクセス権を持っていますか。それはいくつかのルールは、信頼できない、当事者のために意図していない個人情報が含まれていることであるかもしれないことに注意してください。
Req. 8. (LG Rules) Even if a Location Generator is unaware of and lacks access to the full Privacy Rules defined by the Rule Maker, the Location Generator MUST transmit Location Information in compliance with instructions set by the Rule Maker. Such compliance MAY be accomplished by the Location Generator transmitting the LO only to a URI designated by the Rule Maker.
必須。 8.（LGルール）場所Generatorはを認識しないとルールメーカーによって定義された完全なプライバシー規則へのアクセスを欠いている場合でも、場所ジェネレータは、ルールメーカーによって設定された指示を遵守して位置情報を送信しなければなりません。そのようなコンプライアンスロケーションジェネレータのみルールメーカーにより指定されたURIにLOを送信することによって達成することができます。
Req. 9. (Viewer Rules) A Viewer does not need to be aware of the full Rules defined by the Rule Maker (because a Viewer SHOULD NOT retransmit Location Information), and thus a Viewer SHOULD receive only the subset of Privacy Rules necessary for the Viewer to handle the LO in compliance with the full Privacy Rules (such as, instruction on the time period for which the LO can be retained).
必須。 9.（ビューアルール）Viewerは（ビューアは位置情報を再送べきではないから）ルールメーカーによって定義された完全なルールを意識する必要はありませんので、ビューアはプライバシーのサブセットのみを受けるべきではビューアーのために必要なルール（例えば、LOを保持できる時間の期間に、命令のような）完全なプライバシー規則に準拠してLOを処理します。
Req. 10. (Full Rule language) Geopriv MAY specify a Rule language capable of expressing a wide range of privacy rules concerning location information. This Rule language MAY be an existing one, an adaptation of an existing one or a new Rule language, and it SHOULD be as simple as possible.
必須。 10.（フルルール言語）Geoprivは位置情報に関するプライバシー規則の広い範囲を発現することができるルール言語を指定するかもしれません。このルール言語は、既存の、既存のものか、新しいルール言語の適応であってもよく、それは可能な限りシンプルであるべきです。
Req. 11. (Limited Rule language) Geopriv MUST specify a limited Rule language capable of expressing a limited set of privacy rules concerning location information. This Rule language MAY be an existing one, an adaptation of an existing one or a new Rule language. The Location Object MUST include sufficient fields and data to express the limited set of privacy rules.
必須。 11.（限定ルール言語）Geoprivは位置情報に関するプライバシー規則の限られたセットを発現することができる限られたルール言語を指定しなければなりません。このルール言語は、既存の、既存のものか、新しいルール言語の適応かもしれ。 Locationオブジェクトは、プライバシー規則の限られたセットを発現させるために十分なフィールドとデータを含まなければなりません。
Req. 12. (Identity Protection) The Location Object MUST support use of Unlinked Pseudonyms in the corresponding identification fields of Rule Maker, Target, Device, and Location Recipient. Since Unlinked Pseudonyms are simply bit strings that are not linked initially to a well-known identity, this requirement boils down to saying that the name space for Identifiers used in the LO has to be large enough to contain many unused strings.
必須。 12.（ID保護）位置オブジェクトルールメーカー、ターゲット、デバイス、および場所受信者の対応する識別フィールドにリンクされていない仮名の使用をサポートしなければなりません。リンクされていない仮名は、単に、よく知られたアイデンティティに最初にリンクされていないビット列をされているので、この要件はLOで使用される識別子の名前空間が十分に大きいことが多く使用されていない文字列が含まれていなければならないことを言っに沸きます。
Req. 13. (Credential Requirements) The using protocol and the Location Object SHOULD allow the use of different credential types, including privacy-enhancing credentials (for instance those described in [Bra00] or [Cha85]).
必須。 13（資格要件）を使用してプロトコルおよびロケーションオブジェクト（例えば、[Bra00]または[Cha85]に記載のもの）プライバシー強化信任状を含む異なるクレデンシャルタイプの使用を可能にすべきです。
Req. 14. (Security Features) The Location Object MUST support fields suitable for protecting the Object to provide the following security features:
必須。 14.（セキュリティ機能）ロケーションオブジェクトは、次のセキュリティ機能を提供することを目的とする保護するのに適しフィールドをサポートしなければなりません：
14.1) Mutual end-point authentication: the using protocol is able to authenticate both parties in a Location Object transmission,
14.1）相互エンドポイント認証：使用プロトコルロケーションオブジェクト伝送の両方の当事者を認証することができ、
14.2) Data object integrity: the LO is secured from modification by unauthorized entities during transmission and storage,
14.2）データオブジェクトの完全性：LOが送信及び貯蔵中に、不正なエンティティによって改変から保護され、
14.3) Data object confidentiality: the LO is secured from eavesdropping (unauthorized reading) during transmission and storage, and
14.3）データオブジェクトの機密性：LOが送信及び貯蔵中に盗聴（不正読み取り）から保護され、そして
14.4) Replay protection: an old LO may not be replayed by an adversary or by the same entity that used the LO itself (except perhaps during a small window of time that is configurable or accepted by the Rule Maker).
14.4）リプレイ保護：古いLOは、敵によって又は）構成またはルールメーカーによって受け入れられる時間の小さなウィンドウの間、おそらく以外LO自体を（使用したのと同じエンティティによって再生されなくてもよいです。
Req. 15. (Minimal Crypto)
必須。 15.（最小クリプト）
15.1) Geopriv MUST specify a minimum mandatory to implement Location Object security, including mandatory to implement crypto algorithms for digital signature algorithms and encryption algorithms.
15.1）Geoprivは、デジタル署名アルゴリズムと暗号化アルゴリズムのための暗号化アルゴリズムを実装するために必須含む、ロケーションオブジェクトのセキュリティを実装するための最小必須を指定しなければなりません。
15.2) It MAY also define further mandatory to implement Location Object security mechanisms for message authentication codes (MACs) or other purposes.
15.2）また、メッセージ認証コード（MAC）または他の目的のためにロケーションオブジェクトのセキュリティ・メカニズムを実装するためにさらに必須定義MAY。
15.3) The protocol SHOULD allow a bypass if authentication fails in an emergency call.
15.3認証が緊急呼び出しに失敗した場合）プロトコルは、バイパスを許可する必要があります。
The issue addressed in the last point is that an emergency call in some unfavorable situations may not be completed if the minimal authentication fails. This is probably not what the user would like to happen. The user may prefer an unauthenticated call to an unauthenticated emergency server over no call completion at all, even at the risk that he is talking to an attacker or that his information is not secured.
最後のポイントで対処問題は、最小限の認証に失敗した場合、いくつかの不利な状況での緊急呼び出しが完了しないことです。これは、ユーザが起こるしたいものを、おそらくではありません。ユーザーは、彼が攻撃者に、または自分の情報が確保されていないことを話していることにもリスクが、全くのコール完了上で認証されていない緊急サーバーへの認証されていない呼び出しを好むかもしれません。
Non-Req. 1. (Bridging to non-IP networks) The Geopriv specification SHOULD NOT specify the bridging to non-IP networks (PSTN, etc).
非必須。 1.（非IPネットワークにブリッジング）Geopriv仕様は、非IPネットワーク（PSTNなど）にブリッジを指定しないでください。
The purpose of the Geopriv Location Object and the requirements on the using protocol are to allow a Privacy Rule-controlled disclosure of location information for location services.
使用してプロトコルのGeopriv場所オブジェクトと要件の目的は、ロケーションサービスの位置情報のプライバシールール制御開示を可能にしています。
The information carried within the Location Object is secured in a way compliant with the privacy and security Rules of the Rule Maker, but other information, carried in other objects or headers are in general not secured in the same way. This means that Geopriv may not as a general matter, secure the Target against general traffic analysis attacks or other forms of privacy violations.
Locationオブジェクト内の情報は、ルールメーカーのプライバシーとセキュリティ規則に準拠した方法で確保されているが、他のオブジェクトやヘッダーで運ばその他の情報は、一般的には同じように保護されていません。これはGeoprivは、一般的な事項として、一般的なトラフィック分析攻撃やプライバシー侵害の他の形態に対して、ターゲットを固定しなくてもよいことを意味します。
The Privacy Rules of the Rule Maker regarding the location of the Target may be accessible to a Location Server in a public or non-public Rule Holder, or they may be carried by the Location Object, or they may be presented by the Location Recipient as capabilities or tokens. Each type of Rule has to be secured its own particular way.
ターゲットの位置に関するルールメーカーのプライバシー規則は、公開または非公開のルールホルダーにロケーションサーバへアクセスすることができる、またはそれらの場所オブジェクトによって実行することができる、またはそれらの場所受信者などによって提示されてもよいです機能またはトークン。ルールの各タイプには、独自の特定の方法を確保する必要があります。
The rules in a non-public Rule Holder are typically authenticated using a MAC (Message Authentication Code) or a signature, depending on the type of keys used. The rules in a public Rule Holder (one that in principle may be accessed directly by several entities, for instance several Location Servers) are typically digitally signed. Rule Fields in an LO are secured as part of the LO itself. A Geopriv Token (a token or ticket issued by the Rule Maker to a Location Recipient, expressing the explicit consent of the Rule Maker to access his location information) is authenticated or signed.
非公開ルールホルダーのルールは、一般的に使用されるキーの種類に応じて、MAC（メッセージ認証コード）または署名を使用して認証されています。パブリックルールホルダー（原理的にはいくつかのロケーションサーバ、例えば、いくつかのエンティティによって直接アクセスすることができる1つ）のルールは、典型的には、デジタル署名されています。 LOにおけるルールフィールドはLO自体の一部として固定されています。 Geoprivトークン（自分の位置情報にアクセスするためのルールメーカーの明示的な同意を表現する、場所の受信者にルールメーカーによって発行されたトークンまたはチケット）は、認証や署名されています。
Let us consider the situation where the authentication fails in an emergency call because the authentication center fails to authenticate itself. In this case, one way of implementing the authentication bypass for emergency calls (mentioned in Req 15.3) is to let the user have the choice of writing a Rule that says:
私たちは、認証センターが自身を認証するために失敗したため、認証が緊急呼び出しに失敗した状況を考えてみましょう。この場合、（必須15.3で述べた）緊急通話のための認証バイパスを実施する1つの方法は、ユーザが言うルールを書くの選択肢を持っているようにすることです：
- "If the emergency server does not authenticate itself, send the location information anyway", or
- 「緊急サーバは自身を認証しない場合は、とにかく位置情報を送信する」、または
- "If the emergency server does not authenticate itself, let the call fail".
- 「緊急サーバは自身を認証しない場合は、呼び出しは失敗してみましょう」。
Second, in the case where the authentication of the emergency call fails because the user may not authenticate itself, the question arises: whose Rule to use? It is reasonable to use a default one: this location information can only be sent to an emergency center.
第二に、ユーザーが自分自身を認証ない可能性があるため、緊急コールの認証が失敗した場合には、疑問が生じる：そのルールを使用するには？この位置情報は緊急時のみのセンターに送信することができます。デフォルトのものを使用するのが妥当です。
The third situation, which should be studied in more detail, is: what to do if not only the user fails to authenticate itself, but also the emergency center is not authenticable? It is reasonable to send the Location Information anyway, but are there any security threats that must be considered?
より詳細に検討する必要がある第3の状況は、次のとおりです。何を行うには、ユーザーだけでなく、それ自体を認証するために失敗したが、また、緊急センターが認証可能でない場合は？とにかく位置情報を送信することが合理的であるが、考えなければならないセキュリティ上の脅威があるのですか？
The use of Unlinked Pseudonyms is necessary to obtain anonymity.
リンクされていない仮名の使用は、匿名性を得ることが必要です。
The purpose of the use of Unlinked Pseudonyms is the following: the using protocol should be able to hide the real identity of the Rule Maker, the Target, and the Device, from Location Servers or Location Recipients, if required by the RM. Also, the using protocol SHOULD be able to hide the real identity of the Location Recipient from the Location Server.
リンクされていない仮名の利用目的は以下の通りである。使用したプロトコルは、RMで必要な場合、ロケーションサーバや場所の受信者から、ルールメーカー、ターゲット、およびデバイスの正体を隠すことができるはずです。また、使用するプロトコルは、ロケーションサーバから場所受信者の正体を隠すことができるようすべきです。
In this last case, the Target is not concerned about the Server identifying him and knowing his location, but identifying his business partners, and therefore his habits, etc. Reasons for hiding the real identities of the Location Recipients include (a) that this knowledge may be used to infer the identity of the Target, (b) that knowledge of the identity of the Location Recipient may embarrass the Target or breach confidential information, and (c) that the dossier telling who has obtained a Target's location information over a long period of time can give information on habits, movements, etc. Even if the location service providers agree to respect the privacy of the user, are compelled by laws or regulations to protect the privacy of the user, and misbehavior or negligence of the Location Server can be ruled out, there is still risk that personal data may become available to unauthorized persons through attacks from outsiders, unauthorized access from insiders, technical or human errors, or legal processes.
この最後のケースでは、ターゲットはなど、サーバーは彼を識別し、彼の位置を知ることが、彼のビジネスパートナー、したがって彼の習慣を識別する懸念はない場所受信者の本当の身元を隠すための理由は、（a）はこの知識ということが含まれます（b）の場所受信者のアイデンティティの知識が関係書類が長い上で対象者の位置情報を取得した人伝えるという目標を困ら情報や機密情報を突破、そして（c）も、ターゲットの身元を推測するために使用することができます一定の期間がロケーションサービスプロバイダは、ユーザーのプライバシーを尊重することに同意するものとした場合でもなどの習慣、運動、上の情報を与えることができ、利用者のプライバシーを保護するための法律や規制によって強要され、ロケーションサーバの不正行為または過失個人データは部外者からの攻撃、内部者からの不正アクセス、技術的またはヒトERRを通じて不正な人に利用可能になるというリスクがまだある、除外することができますORS、または法的手続き。
On some occasions, a Location Server has to know who is supplying the Privacy Rules for a particular Target, while in other situations it could be enough to know that the supplier of the Rules is authorized to do so.
いくつかの場面で、ロケーションサーバは、他の状況では、ルールのサプライヤーがそうすることを許可されていることを知るのに十分な可能性がありながら、特定のターゲットのプライバシー規則を供給しているかを知る必要があります。
An Unintended Target is a person or object tracked by proximity to the Target. This special case most frequently occurs if the Target is not a person. For example, the Target may be a rental car equipped with a GPS Device, used to track car inventory. The rental company may not care about the driver's location, but the driver's privacy is implicitly affected.
意図しないターゲットは、ターゲットへの接近によって追跡人物や物体です。対象が人でない場合は、この特殊なケースでは、最も頻繁に発生します。例えば、ターゲット車の在庫を追跡するために使用されるGPS装置を搭載したレンタカーであってもよいです。レンタル会社は、ドライバの場所を気にしないかもしれないが、運転者のプライバシーは暗黙のうちに影響を受けています。
Geopriv may or may not protect or affect the privacy of Unintended Targets, but the impact on Unintended Targets should be acknowledged.
Geoprivは、あるいは保護したり、意図しないターゲットのプライバシーに影響を与えるが、意図しないターゲットへの影響は認められるべきでない場合があります。
This section briefly discusses issues relating to the Location Object or the protocol that have emerged during the discussion of earlier versions of this document.
このセクションでは、簡単に場所オブジェクトまたはこのドキュメントの以前のバージョンの議論の中に出現しているプロトコルに関連する問題について説明します。
A location Field is intended to represent one point or one region in space (either 1, 2, or 3 dimensionally). The possibility of inclusion of multiple locations is discussed in another document. The current rough consensus is the following: the LO definition MAY allow the Location Field to be optional, to appear exactly one time or to occur several times. Each Location Field may contain one or more "Location Representations", each of which is intended to represent a different measurement or a different formatting of the same position. But there are other possibilities for using multiple Location Fields and multiple representations: maybe several Location Fields would be used to report the same sighting in different formats, or multiple sightings at different times, or multiple sensor locations for the same device, or other purposes, which could also depend on the using protocol. This is all for further discussion.
位置フィールドは（1、2、または3次元のいずれかの）空間の1点または1つの領域を表すことを意図しています。複数の場所の包含の可能性は、別の文書に記載されています。 LOの定義は、1つの時間を表示させたり、数回発生し、場所フィールドはオプションことを可能にすることができる：現在の荒いコンセンサスは次のようです。各ロケーションフィールドは、異なる測定または同じ位置の異なる書式を表すことが意図されているそれぞれが、1つ以上の「場所の表現」を含んでいてもよいです。しかし、複数の場所フィールドと複数の表現を使用するための他の可能性があります。多分、いくつかの場所のフィールドは、異なるフォーマットで同じ目撃情報を報告するために使用される、または複数の目撃異なる時間に、または同じデバイスに対して複数のセンサ位置、または他の目的は、これはまた、使用プロトコルに依存性があります。これは、すべてのさらなる議論のためです。
It is possible to include fields to indicate that one of the locations is a translation of another. If this is done, it is also possible to have a field to identify the translator, as identity and method.
場所のいずれかが別の翻訳であることを示すためのフィールドを含めることが可能です。このようにすれば、アイデンティティと方法として、翻訳者を識別するためのフィールドを有することも可能です。
Geopriv MUST be silent on the truth or lack-of-truth of the location information contained in the LO. Thus, the LO MUST NOT provide an attribute in object saying "I am (or am not) telling you the whole truth."
Geoprivは真実でサイレントまたは欠如オブ真理LOに含まれる位置情報でなければなりません。したがって、LOは言っオブジェクトの属性与える必要があり、「私は（またはしないよ）あなたに真実を語っています。」
The format of timing information is out of the scope of this document.
タイミング情報のフォーマットは、このドキュメントの範囲外です。
Who defines the Identities: can the using protocol define the Identifiers or must the using protocol use and authenticate Pseudonyms proposed by the Rules, chosen independently of the using protocol? Of course, if the using protocol has an appropriate namespace, containing many unused names that may be used as pseudonyms and may be replaced by new ones regularly, then the Location Object may be able to use the name space. For this purpose, the user would probably have to write his Rules using this name space. Note that it is necessary to change the used pseudonyms regularly, because identifying the user behind an unlinked pseudonym can be very simple.
誰がアイデンティティを定義：使用プロトコルとは独立して選択され、使用プロトコルは、識別子を定義することができ、またはプロトコルの使用を使用しなければならず、ルールによって提案仮名を認証しますか？もちろん、場合には、使用するプロトコルが偽名として使用することもできるし、定期的に新しいものに置き換えることができる、そして場所のオブジェクトは、名前空間を使用することができる場合が多く、未使用の名前を含む、適切な名前空間を持っています。この目的のために、ユーザーは、おそらく、この名前空間を使用して自分のルールを記述する必要があります。リンクされていない仮名の後ろにユーザを識別することは非常に単純なことができるので、定期的に使用仮名を変更する必要があることに注意してください。
There are several advantages in letting the using protocol define the name space:
使用するプロトコルは、名前空間を定義させるにはいくつかの利点があります。
o the embedded authentication would be easier, as the using protocol often already has the credentials for the authentication identity in place and the "embedded" authentication would be independent on the form of Identifiers,
使用するプロトコルは、多くの場合、すでに場所で認証アイデンティティのための資格情報を持っており、「埋め込まれた」認証は識別子の形式に依存しないだろうとして、O埋め込まれた認証は、容易になるだろう、
o the size of the names would be fixed.
O名のサイズは固定されます。
On the other hand, the benefits of the Rule choosing the identifiers are:
一方、識別子を選択するルールの利点は次のとおりです。
o the user has a control of his anonymity, and
ユーザーは自分の匿名性を制御している、とO
o the interworking of multiple systems with Location object across protocol boundaries is facilitated.
Oプロトコルの境界を越えロケーションオブジェクトと複数のシステムのインターワーキングが容易になります。
We wish to thank the members of the IETF Geopriv WG for their comments and suggestions. Aaron Burstein, Mehmet Ersue, Allison Mankin, Randall Gellens, and the participants of the Geopriv meetings in San Diego and Yokohama provided detailed comments or text.
我々は彼らのコメントや提案をIETF Geopriv WGのメンバーに感謝したいです。アーロン・バースタイン、メフメットErsue、アリソンマンキン、ランドールGellens、サンディエゴと横浜のGeopriv会議の参加者は、詳細なコメントやテキストを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]ブラドナーの、S.、 "要件レベルを示すためにRFCsにおける使用のためのキーワード"、BCP 14、RFC 2119、1997年3月。
[Bra00] Stefan A.: Rethinking Public Key Infrastructures and Digital Certificates : Building in Privacy, MIT Press; ISBN: 0262024918; 1st edition, August, 2000
[Bra00]ステファン・A：再考公開鍵インフラストラクチャおよびデジタル証明書：プライバシー中の建物、MITプレス; ISBN：0262024918;第1版、2000年8月
[Cha85] Chaum, David: Security without Identification, Card Computers to make Big Brother Obsolete. Original Version appeared in: Communications of the ACM, vol. 28 no. 10, October 1985 pp. 1030-1044. Revised version available at http://www.chaum.com/articles/
[Cha85] Chaum、デビッド：識別せずにセキュリティ、カードコンピュータはビッグブラザーが廃止されたようにします。 ACMのコミュニケーション、巻：オリジナルバージョンは、登場しました。 28なし。 10、1985年10月頁。1030年から1044年。 http://www.chaum.com/articles/でご利用いただけ改訂版
[ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/.
[ISO99] ISO99：ISO IS 15408、1999、http://www.commoncriteria.org/。
[OECD] OECD Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, http://www.oecd.org.
プライバシーの保護に関する[OECD] OECDガイドラインや個人情報、http://www.oecd.orgの越境フロー。
[Pfi01] Pfitzmann, Andreas; Koehntopp, Marit: Anonymity, Unobservability, and Pseudonymity - A Proposal for Terminology; in: H Federrath (Ed.): Designing Privacy Enhancing Technologies; Proc. Workshop on Design Issues in Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer versions available at http://www.koehntopp.de/marit/pub/anon
【Pfi01] Pfitzmann、アンドレアス。 Koehntopp、マリット：匿名性、観察不能、および偽名 - 用語の提案。中：H Federrath（編）：設計プライバシー強化技術。 PROC。匿名性と観察不能で設計上の問題に関するワークショップ。 LNCS 2009; 2001; 1-9。 http://www.koehntopp.de/marit/pub/anonで入手可能な新しいバージョン
Jorge R Cuellar Siemens AG Corporate Technology CT IC 3 81730 Munich, Germany
ホルヘ・RクエリャルシーメンスAGコーポレート・テクノロジCT IC 3 81730ミュンヘン、ドイツ
EMail: Jorge.Cuellar@siemens.com
メールアドレス：Jorge.Cuellar@siemens.com
John B. Morris, Jr. Director, Internet Standards, Technology & Privacy Project Center for Democracy & Technology 1634 I Street NW, Suite 1100 Washington, D.C. 20006 USA
ジョン・B・モリス・ジュニア・ディレクター、インターネット標準、技術・民主主義とテクノロジー1634 IストリートNW、スイート1100のプライバシーに関するプロジェクトセンターワシントンD.C. 20006 USA
EMail: jmorris@cdt.org URI: http://www.cdt.org
電子メール：jmorris@cdt.org URI：http://www.cdt.org
Deirdre K. Mulligan Samuelson Law, Technology & Public Policy Clinic Boalt Hall School of Law University of California Berkeley, CA 94720 USA
ディアドラK.マリガンサミュエルソン法律、技術・カリフォルニアの法律大学バークレー、CA 94720 USAの公共政策クリニックBoaltホールスクール
EMail: dmulligan@law.berkeley.edu URI: http://www.law.berkeley.edu/cenpro/samuelson/
電子メール：dmulligan@law.berkeley.edu URI：http://www.law.berkeley.edu/cenpro/samuelson/
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 5707 Concord, CA 94520 USA
ジョンピーターソンNeuStar、Inc.の1800サッター聖スイート5707コンコード、CA 94520 USA
EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
電子メール：jon.peterson@neustar.biz URI：http://www.neustar.biz/
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
ジェームズ・M.ポークシスコシステムズ2200東ブッシュ大統領ターンパイクリチャードソン、テキサス州75082 USA
EMail: jmpolk@cisco.com
メールアドレス：jmpolk@cisco.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78 and except as set forth therein, the authors retain all their rights.
著作権（C）インターネット協会（2004）。この文書では、BCP 78に含まれる権利、ライセンスおよび制限があり、そこに記載された以外、作者は彼らのすべての権利を保有します。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
Intellectual Property
知的財産
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETFは、本書またはそのような権限下で、ライセンスがたりないかもしれない程度に記載された技術の実装や使用に関係すると主張される可能性があります任意の知的財産権やその他の権利の有効性または範囲に関していかなる位置を取りません利用可能です。またそれは、それがどのような権利を確認する独自の取り組みを行ったことを示すものでもありません。 RFC文書の権利に関する手続きの情報は、BCP 78およびBCP 79に記載されています。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンラインIPRリポジトリから。
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETFは、その注意にこの標準を実装するために必要とされる技術をカバーすることができる任意の著作権、特許または特許出願、またはその他の所有権を持ってすべての利害関係者を招待します。 ietf-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。