[要約] RFC 3693は、位置情報プライバシーの要件を定義するための規格であり、位置情報の取り扱いに関するガイドラインを提供します。その目的は、位置情報のプライバシー保護を確保しながら、位置情報の利用を可能にするための要件を明確化することです。
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
GEOPRIV要件
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）The Internet Society（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 Locationオブジェクト（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）生の位置データにアクセスし、場所の導出または計算、または派生または計算された位置情報にアクセスできるエンティティのIDと（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) プライバシールールの1つのタイプは、受信者が誰であるかに応じて、位置情報のフィルタリング方法を指定します。フィルタリングは、データの精度または解像度を減らすプロセスです。典型的なルールは、「私の場所はそのような正確さまたは解決策でそのような資格の所有者にのみ開示することができる」という形式のものかもしれません（例えば、「私の同僚は私が現在いる都市に伝えることができます」）。
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) ロケーションオブジェクトは、プライバシールールの限定的ではあるがコアセットを携帯できる必要があります。コアセットまたはフルセットのこれらのルールの正確な形式または表現力については、このドキュメントではこれ以上議論されていませんが、このワーキンググループが作成した将来のドキュメントでより広範囲に説明します。
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.
法的制約のため、または一部のロケーションサービスが実際に明示的な識別を必要とする可能性があるため、一部のアプリケーションには完全な匿名性は適切ではない場合がありますが、ほとんどの場合、ロケーションサービスには何らかのタイプの承認情報および/またはおそらく問題のエンティティの匿名の識別子のみが必要です。
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].
「必須」、「そうしない」、「必須」、「shall」、「shall "、" ingle "、" should "、" not "、" becommended "、" bay "、および「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.
ここで説明する要件は、一般的なロケーションオブジェクトとロケーションサービスにプロトコルを使用する要件であることに注意してください。したがって、ほとんどの場合、このドキュメントで説明されている要件は、義務的な能力を指します。たとえば、実装をサポートする必要があることは、すべてのプロトコルトラフィックを認証することを要求するのと同じものではありません。対照的に、必須の（必須の義務的なものだけでなく）要件の例は、ロケーションデータが認証されていないときにユーザーが常に通知を受信することを示すものかもしれません。このプラクティスは、実装するだけでなく、使用する必要があります。
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.
プロトコルの使用：ロケーションオブジェクトを運ぶプロトコル。
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から受け取るLOSに適用し、必要に応じて結果のLOSのLRに通知します。
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.
Location Recipient（LR）：LRは、ロケーションサーバーからロケーションオブジェクトの通知を受信する要素です。LRは、これらのLOSを何らかの方法でユーザーまたはオートマトンにレンダリングする場合があります。
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に照会するか、ルールがRHからLSにプッシュされる場合があります。ルールホルダーのルールには、ルールメーカーが入力されます。
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.
したがって、場所の生成とは、おそらく複数のソースから、IPベースのGeoprivエンティティであるLGで位置情報を収集するプロセスであり、他のGeoprivエンティティと通信します。
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）入力またはその他のデバイスによって決定される情報（b）から派生または計算されたターゲットによって提供されます。
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.
たとえば、位置情報には、（a）携帯電話の塔に関するワイヤレス信号で三角測量によって計算された情報、（b）GPS（グローバルポジショニング衛星）機能を備えたデバイスによって決定される経度および緯度情報、（c）情報クエリに応じてターゲットによって携帯電話またはラップトップに手動で入力され、（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.
欠落しているフィールドのセマンティクスについては何も言われていません。たとえば、部分的に満たされたオブジェクトは、それを完了するための要求として暗黙的に理解される場合があります。または、時間情報が含まれていない場合、これは暗黙的に「現在の時期」または「ごく最近の時間」を意味する場合がありますが、コンテキストに応じて、異なる方法で解釈できます。
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の定義には、最小限の暗号機能を含める必要があります（Req。14および15）。さらに、RMが特定のLOセキュリティメカニズムの使用を指定する場合、使用する必要があります（Req。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.
1. 緊急サービス（米国内のE911など）の場合、地方または国の法律では、特定の定義された緊急通話状況で正確な位置情報を送信する必要がある場合があります。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は法的当局によって課されるオーバーライド指令を認識していない場合があります。この状況を促進するために特定の宿泊施設が作られるのは、ワーキンググループの期待ではありません。
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 Losを送信しますが、Geopriv Locationオブジェクトの一部を使用していません。他のケースには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.
プライバシールールの完全なセットには、可能な技術的意味が1つしかないルールと、地域の一般的な法律や税関の影響を受けるルールの両方が含まれる可能性があります。たとえば、「私の場所は、そのような資格の所有者にのみ開示でき、そのような精度または解像度でのみ開示できます」という形式の分布ルールは、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]仮名は、単に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が別のエンティティBを「ID-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衛星は信号を放送し、信号を使用したデバイスのIDまたは居場所に関する情報がないと想定されています。
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).
この例では、携帯電話がホームサービスエリアの外で使用されます（ローミング）。また、携帯電話サービスプロバイダー（携帯電話会社）は、携帯電話の使用の会計を外部委託しました。携帯電話はGPS対応ではありません。場所は、ターゲットとデバイスがローミングしている携帯電話ネットワークによって導出されます。ターゲットが携帯電話の使用を希望する場合、携帯電話会社1（AP）はターゲットにローミングサービスを提供します。これにより、使用に関する生データが使用されます（例：通話時間、ローミングネットワークの場所など）。電話会社、ホームサービスプロバイダー。携帯電話会社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.
ここでは、携帯電話会社がAPとLGです。このシナリオでは、携帯電話会社は信頼できるエンティティである可能性がありますが、携帯電話会社は不信感を抱いている可能性があります。
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
("***>").
+---------+ +------------+
| | | |
| 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：位置情報リクエスト：場所の受信者は、ターゲットの位置情報を要求します。このリクエストでは、場所の受信者は、どの位置情報データタイプを好むかを選択できます。位置情報を要求する1つの方法は、ターゲットと場所の受信者の識別のみ、目的のデータ型と精度または解像度のみを含む部分的に満たされた位置オブジェクトを送信し、必要な資格情報の所有の証明を提供することです。しかし、使用するプロトコルがこの部分的に満たされたオブジェクトを理解しているかどうかは、要求が使用中またはコンテキストに依存する可能性があるためです。場所の受信者は、定期的な位置情報の更新の必要性を指定することもできますが、これはおそらく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',
o LOを定義するドキュメントは、LOフィールド「A」を定義する必要があります。
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 フィールド「A」は、使用するオプションとして定義する必要があります（LOのインスタンスはフィールド「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',
o LOを定義するドキュメントは、LOフィールド「A」を定義する必要があります。
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'.
o フィールド「A」は、使用するかどうかと定義される場合があります。使用するオプションとして定義されている場合、LOのインスタンスはフィールド「A」を含む場合と含まない場合があります。オプションでない場合、LOSのすべてのインスタンスにはフィールド「A」が含まれている必要があります。
Req. 1. (Location Object generalities)
req。1.（ロケーションオブジェクトの一般性）
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は、すべてのGEOPRIVエンティティでサポートする必要がある、構文とセマンティクスの両方で1つの位置オブジェクト（LO）を定義する必要があります。
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）ロケーションオブジェクトの一部のフィールドがオプションである場合があります。これは、ロケーションオブジェクトのインスタンスにフィールドが含まれている場合と含まれていない場合があることを意味します。
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）ロケーションオブジェクトの一部のフィールドは、「拡張機能」として定義される場合があります。これは、これらのフィールドの構文またはセマンティクスが基本的な位置オブジェクト定義で完全に定義されていないことを意味しますが、それらの使用は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:
req。2.（ロケーションオブジェクトフィールド）ロケーションオブジェクト定義には、次のフィールドを含める必要があります。
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）ロケーション受信者のアイデンティティこのアイデンティティは、マルチキャストまたはグループのアイデンティティであり、プロトコルを使用してマルチキャストベースのロケーションオブジェクトを含めるために使用されます。
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.
ロケーションオブジェクトを送信する場合、送信者と受信者は、位置情報のデータ型に同意する必要があります。使用するプロトコルは、データ型情報が位置オブジェクトの一部であること、または送信者と受信者が実際のデータ転送前にそれに同意したことを指定する場合があります。
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）への紹介である場合があります。または、限られたルール（Req。11を参照）、またはその両方を含む場合があります。
2.9) Security-headers and -trailers (for instance encryption information, hashes, or signatures) (see Req. 14 and 15).
2.9）セキュリティヘッダーとトレーラー（たとえば、暗号化情報、ハッシュ、または署名）（req。14および15を参照）。
2.10) Version number
2.10）バージョン番号
Req. 3. (Location Data Types)
req。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を受け取るエンティティ）によってサポートされる少なくとも1つの位置データタイプを定義する必要があります。
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）ロケーションオブジェクトは、2つの位置データ型を定義する必要があります。1つは緯度 /経度 /高度座標用、もう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）ロケーションオブジェクトの定義は、一部の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.
req。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。5.使用するプロトコルは通常、資格情報に関連付けられたキーがそれぞれの当事者に輸送されることを促進します。つまり、重要な施設は使用プロトコルの責任です。
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.
req。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).
使用プロトコルに関する他の要件はこのドキュメントの範囲外ですが、このワーキンググループからの将来の努力の対象かもしれません。セクション9（後で検討するためにプロトコルとLOの問題）も参照してください。
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.
req。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.
req。8.（LGルール）ロケーションジェネレーターがルールメーカーによって定義された完全なプライバシールールへのアクセスを知らず、アクセスできない場合でも、ロケーションジェネレーターはルールメーカーが設定した命令に準拠して位置情報を送信する必要があります。このようなコンプライアンスは、ルールメーカーによって指定された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).
req。9.（ビューアルール）視聴者は、ルールメーカーによって定義された完全なルールを認識する必要はありません（視聴者は位置情報を再送信すべきではないため）。したがって、視聴者は視聴者に必要なプライバシールールのサブセットのみを受け取る必要があります完全なプライバシールール（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.
req。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.
req。11.（限られたルール言語）GEOPRIVは、位置情報に関する限られた一連のプライバシールールを表現できる限られたルール言語を指定する必要があります。このルール言語は、既存の言語、既存のものの適応、または新しいルール言語の適応である可能性があります。ロケーションオブジェクトには、プライバシールールの限られたセットを表現するのに十分なフィールドとデータを含める必要があります。
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.
req。12.（アイデンティティ保護）ロケーションオブジェクトは、ルールメーカー、ターゲット、デバイス、および位置の受信者の対応する識別フィールドで、リンクされていない仮名の使用をサポートする必要があります。リンクされていない仮名は、最初はよく知られているアイデンティティにリンクされていないビット文字列であるため、この要件は、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]).
req。13.（資格情報要件）使用プロトコルと位置オブジェクトは、プライバシーを強化する資格情報（[BRA00]または[CHA85]に記載されているもの）を含むさまざまな資格情報の使用を許可する必要があります。
Req. 14. (Security Features) The Location Object MUST support fields suitable for protecting the Object to provide the following security features:
req。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)
req。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）またはその他の目的に位置オブジェクトセキュリティメカニズムを実装するために、さらに必須を定義することもできます。
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).
非req。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.
ロケーションオブジェクト内にある情報は、ルールメーカーのプライバシールールとセキュリティルールに準拠して保護されていますが、他のオブジェクトまたはヘッダーで運ばれるその他の情報は、一般的に同じ方法で保護されていません。これは、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（メッセージ認証コード）または署名を使用して認証されます。パブリックルールホルダーのルール（原則として、いくつかのエンティティ、たとえば複数のロケーションサーバーによって直接アクセスされる可能性があるもの）は通常、デジタルで署名されています。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:
認証センターが自らを認証できないため、緊急通話で認証が失敗する状況を考えてみましょう。この場合、緊急コールに認証バイパスを実装する1つの方法（REQ 15.3で言及）は、ユーザーに次のようなルールを書くことを選択できるようにすることです。
- "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.
この最後のケースでは、ターゲットはサーバーが彼を識別し、自分の位置を知っていることを心配していませんが、彼のビジネスパートナー、したがって彼の習慣などを特定します。ターゲットのアイデンティティを推測するために使用される場合があります（b）場所の受信者の身元に関する知識は、ターゲットまたは機密情報に恥ずかしいこと、および（c）長い間ターゲットの位置情報を取得した人に書かれていることを伝えることができます。期間は、習慣、動きなどに関する情報を提供できます。ロケーションサービスプロバイダーがユーザーのプライバシーを尊重することに同意しても、ユーザーのプライバシーを保護するための法律または規制、およびロケーションサーバーの不正行為または過失を保護することができます。除外することができますが、部外者からの攻撃、インサイダーからの不正アクセス、技術的または人的誤り、または法的プロセスを通じて、個人データが不正な人が利用できるようになる可能性があります。
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つのポイントまたはスペース内の1つの領域を表すことを目的としています（1、2、または3次元）。複数の場所を含める可能性については、別のドキュメントで説明されています。現在の大まかなコンセンサスは次のとおりです。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.
フィールドを含めて、1つの場所が別の場所の翻訳であることを示すことができます。これが行われた場合、IDと方法として翻訳者を識別するフィールドを持つことも可能です。
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 埋め込み認証は簡単になります。使用するプロトコルには、既に存在する認証IDの資格情報が既にあり、「組み込み」認証は識別子の形式で独立しているため、
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のメンバーのコメントと提案に感謝したいと思います。アーロン・バースタイン、メフメット・エルセ、アリソン・マンキン、ランドール・ゲレンズ、およびサンディエゴと横浜でのジオプリフ会議の参加者は、詳細なコメントまたはテキストを提供しました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner、S。、「要件レベルを示すためにRFCで使用するためのキーワード」、BCP 14、RFC 2119、1997年3月。
[Bra00] Stefan A.: Rethinking Public Key Infrastructures and
Digital Certificates : Building in Privacy, MIT Press;
ISBN: 0262024918; 1st edition, August, 2000
[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、David：識別なしのセキュリティ、ビッグブラザーを時代遅れにするためのカードコンピューター。オリジナルバージョンが登場しました：ACMの通信、Vol。28いいえ。10、1985年10月pp。1030-1044。http://www.chaum.com/articles/で利用可能な改訂版
[ISO99] ISO99: ISO IS 15408, 1999, http://www.commoncriteria.org/.
[ISO99] ISO99：ISOは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
Jorge R Cuellar Siemens AG Corporate Technology CT IC 3 81730 Munich, Germany
Jorge R Cuellar Siemens AG Corporate Technology CT IC 3 81730ミュンヘン、ドイツ
EMail: 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
Deirdre K. Mulligan Samuelson Law, Technology & Public Policy Clinic Boalt Hall School of Law University of California Berkeley, CA 94720 USA
Deirdre K. Mulligan Samuelson Law、Technology＆Public Policy Clinic Boalt Hall School of California University、CA 94720 USA
EMail: 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
Jon Peterson Neustar、Inc。1800 Sutter St Suite 5707 Concord、CA 94520 USA
EMail: 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
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）The Internet Society（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.
このドキュメントとここに含まれる情報は、「現状のまま」に基づいて提供されています。また、貢献者、彼/彼女が代表する組織（もしあれば）が後援する組織、インターネット協会とインターネット工学タスクフォースは、すべての保証、明示的または明示的、またはすべての保証を否認します。本書の情報の使用が、商品性または特定の目的に対する適合性の権利または黙示的な保証を侵害しないという保証を含むがこれらに限定されないことを含む。
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.
IETF事務局に行われたIPR開示のコピーと、利用可能にするライセンスの保証、またはこの仕様の実装者またはユーザーによるそのような独自の権利の使用のための一般的なライセンスまたは許可を取得するための試みの結果を取得できます。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エディター機能の資金は現在、インターネット協会によって提供されています。