[要約] RFC 3693は、ネットワーク上でユーザーの「位置情報（ジオロケーション）」を安全に扱うためのフレームワーク「GEOPRIV」に対する詳細な機能要件を定義しています。ユーザー自身によるプライバシーポリシーの設定、情報の取得・配布における認可、および不正な追跡を防止するための機密性保持に関する基準を整理しています。位置情報サービス（LBS）の利便性を享受しつつ、ユーザーのプライバシー権利を技術的に保護するための堅牢なプロトコル設計指針を提供することを目的としています。
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
Geographic Location Privacy (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.
位置情報に基づくサービス、ナビゲーションアプリケーション、緊急サービス、現場の機器管理など、位置に依存するサービスでは、対象（Target。利用者、リソース、その他の主体など）の地理的位置情報が必要です。位置情報サービスのために位置情報を安全に収集・転送すると同時に、関係する人々のプライバシーを保護する必要があります。
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 Object: 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").
位置情報を入力として必要とするアプリケーションである位置情報ベースのサービスは、ますます一般的になっています。特定の対象（Target）に関する位置情報の収集と転送は、プライバシーに重大な影響を及ぼす場合があります。この文書で説明するプロトコルの主な目的は、「対象の利用者／所有者」（より正確には、セクション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) 位置情報オブジェクト（LO）の送信を保護することは、位置情報の完全性と機密性を保証するために不可欠です。これには、LOの送信者と受信者の認証、およびLO自体の保護が含まれます。
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) 位置情報オブジェクトは、限定的ながら中核となるプライバシールール一式を保持できることが望ましいです。中核のルール一式または完全なルール一式の具体的な形式や表現力はこの文書では詳述せず、今後このワーキンググループが作成する文書で詳しく扱います。
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].
このドキュメントのキーワード "MUST"、"MUST NOT"、"REQUIRED"、"SHALL"、"SHALL NOT"、"SHOULD"、"SHOULD NOT"、"RECOMMENDED"、"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.
ここで扱う要件は、汎用的な位置情報オブジェクトと、位置情報サービスで使うプロトコルに対するものです。したがって、これらの要件の大半は、実装が備えるべき機能を定めています。たとえば、実装に完全性保護の機能を求めることと、すべてのプロトコルトラフィックの認証を必須にすることは同じではありません。一方、「実装するだけでなく使用する」ことも義務付ける要件の例として、位置データが認証されていない場合に利用者へ必ず通知する要件が考えられます。この場合は、その機能を実装するだけでなく、実際に使用することも必須です。
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.
位置情報生成者 (Location Generator: 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.
位置情報オブジェクト (Location Object: 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.
位置情報受信者 (Location Recipient: 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.
位置サーバー (Location Server: LS): 位置情報生成者から位置情報オブジェクトを受け取り、位置情報受信者からの問い合わせを受け付け、ルール作成者が定めたルールを適用する主体です。
Precision: The number of significant digits to which a value has been reliably measured.
精度 (Precision): 値を信頼性をもって測定した有効桁数です。
Principal: The holder/subject of the credentials, e.g., a workstation user or a network server.
主体 (Principal): 資格情報の保有者または対象者です。例として、ワークステーションの利用者やネットワークサーバーがあります。
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).
空間解像度 (Resolution): 測定領域で区別できる細部の細かさです。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 Holder): 位置情報を配布するため、特定の対象に適用するルールを提供する主体です。位置サーバーにルールを「プッシュ」する場合も、位置サーバーがルール保持者からルールを「プル」する場合もあります。
Rule Maker: The authority that creates rules governing access to location information for a target (typically, this it the target themselves).
ルール作成者 (Rule Maker): 対象の位置情報へのアクセスを管理するルールを作成する権限者です。通常は対象自身です。
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.
ルール／プライバシールール (Rule / Privacy Rule): 位置情報の収集、使用、開示、保持を含む、位置情報に関する主体の活動を規制する指示です。
Target: A person or other entity whose location is communicated by a Geopriv Location Object.
対象 (Target): Geopriv位置情報オブジェクトによって位置が伝えられる人またはその他の主体です。
Using Protocol: A protocol that carries a Location Object.
使用プロトコル (Using Protocol): 位置情報オブジェクトを運ぶプロトコルです。
Viewer: A Principal that consumes location information that is communicated by a Geopriv Location Object, but does not pass this information further.
閲覧者 (Viewer): 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.
空間解像度と精度はよく似た概念です。どちらを下げても位置情報を粗くできます。「空間解像度」は、利用者の位置を囲む領域を広げる（州から国へ広げるなど）ことで下げられます。「精度」は、位置測定値の有効桁を捨てる（経度・緯度を秒単位から分単位に丸めるなど）ことで下げられます。別のワーキンググループ文書で、この話題をさらに詳しく扱っています。
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): 対象の位置を最初に判定または収集し、その位置を記述する位置情報オブジェクトを作成する主体です。LGは位置情報オブジェクトを位置サーバーに公開します。位置情報生成者が位置情報をどのように取得するかは、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は、位置情報生成者から受け取ったLOにルール保持者から取得したルールを適用し、必要に応じて、その結果のLOを位置情報受信者へ通知します。
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は、何らかの方法でその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): 特定の対象に関する位置情報オブジェクトの受信、フィルタリング、配布を定めるプライバシールールを保持する要素です。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".
ルールは認証され、保護されていなければなりません (MUST)。これがどのように行われるか、特にキーを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.
たとえば、位置情報には、(a) 携帯電話基地局を基準に無線信号を三角測量して算出した情報、(b) GPS (Global Positioning System) 機能を備えた装置が判定した経度・緯度、(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)」と呼びます。
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.
位置検知 (Sighting): 非公開情報（「位置情報」の定義を参照）に基づいて位置を最初に判定し、位置情報を最初に作成することです。
Some variant of the sighting information is included in the Location Object. Abstractly, it consists of two separate data fields:
位置検知情報の何らかの形は位置情報オブジェクトに含まれます。概念上、次の2つのデータフィールドから成ります。
(Identifier, Location)
(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は位置検知対象に割り当てられた識別子であり、Locationはその対象の現在位置です。すべての主体がまったく同じ位置検知情報を参照できるとは限りません。位置検知情報は、次の組に変換される場合があります。
(Identifier-1, Location-1)
(Identifier-1, Location-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.
位置情報生成者または位置サーバーが位置情報受信者に提供する前に、このような変換が行われます。この場合、Identifier-1は仮名であり、Location-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ワーキンググループの主な目標の1つは、位置情報と基本的なプライバシー保護指示の両方を伝える位置情報オブジェクト (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): 対象の位置情報と、対象のIDまたは仮名、時刻情報、中核となるプライバシールール、認証情報などのフィールドを含むデータです。位置情報自体を含め、ほとんどのフィールドは省略可能です。
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.
省略されたフィールドの意味は定められていません。たとえば、一部だけ記入されたオブジェクトは、その補完を求める要求として暗黙に解釈してもよいです (MAY)。時刻情報が含まれない場合は、「現在」または「ごく最近」を暗黙に意味してもよいですが (MAY)、文脈によって別の意味に解釈されることもあります。
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に適用されるルールに従い、適切な配布、保護、使用、保持、保管に責任を負います。
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自体を保護するフィールドまたは機構を含まなければなりません (MUST)。たとえば、暗号学的チェックサムや暗号化をLO自体に含めて保護してもよいです (MAY)。第二に、使用プロトコルも、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）を含めなければなりません (MUST)。さらに、ルール作成者 (RM) が特定のLOセキュリティ機構の使用を指定した場合、その機構を使用しなければなりません (MUST)（要件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.
信頼できるデータフロー (Trusted Data Flow): 位置情報のプライバシーを扱う既存の契約関係に基づいて管理されるデータフローです。
Non-trusted Data Flow: The data flow is not governed by a pre-existing contractual relationship that addresses location privacy.
信頼できないデータフロー (Non-trusted Data Flow): 位置情報のプライバシーを扱う既存の契約関係に基づいて管理されないデータフローです。
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.
対象 (Target): 位置情報受信者が位置を知ろうとしている主体です。多くの場合、対象は装置の人間の利用者、または装置が取り付けられた車両や輸送コンテナなどです。対象そのものが装置である場合もあります。
Device: The technical device whereby the location is tracked as a proxy for the location of a Target.
装置 (Device): 対象の位置を代替的に示すものとして、その位置が追跡される技術装置です。
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) 受信機、無線アクセス装置を備えたラップトップ、または追跡・位置特定できる信号を送信する装置などがあります。対象がウェブブラウザーなどを使って位置情報を手入力する場合、その対象が事実上、装置の役割を果たします。
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ワーキンググループは、この状況に対応できるようにしなければなりません (MUST)。
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. 法執行機関による通信傍受の場合、ルール作成者が、法的権限を持つ機関から課されたルール上書き指令を知らないことがあります。この状況に対応する特別な仕組みを設けることは、ワーキンググループの想定外です。
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.
閲覧者 (Viewer): 対象の位置データを受け取り、その位置情報や対象の位置に基づく情報（対象への／対象からの運転経路など）を、対象またはルール作成者以外の当事者に送信しない個人または主体です。
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.
データ転送者 (Data Transporter): データを処理または変更せずに受信して転送する主体またはネットワークです。データ転送者は、装置と位置サーバー、位置サーバー同士、または位置サーバーと閲覧者との間で行われるほぼすべての転送に関与する可能性があります。位置追跡のシナリオによっては、データ転送者が関与しない場合もあります。
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を持つ場合があります。このLGはGeopriv LOを転送するだけで、LOの内容を利用しません。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.
位置情報保管装置 (Location Storage): データベースなど、生または処理済みの位置情報を、位置情報に関する即時の取引を完了するのに必要な時間を超えて保管する装置または主体です。
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 Guidelines on the Protection of Privacy and Transborder Flows of Personal Data [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.
プライバシールール (Privacy Rule): 位置情報の収集、使用、開示、保持など、位置情報に関する主体の活動を規制するルールまたはルール一式です。特に、主体が位置情報をどのように使用できるか、どの変換済み位置情報を、どの条件で、どの主体に開示できるかを定めます。ルールは遵守しなければならず、単なる助言ではありません。
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.
匿名性とは、ある主体の集合の中で個人を識別できない性質です。匿名性はプライバシーの基本です。匿名性を保てなければ、個人が自分のプライバシーを管理できない場合があります。リンク不能性 (unlinkability) によって、他者が複数の利用を相互に関連付けることなく、利用者はリソースやサービスを複数回利用できます。リンク不能であるためには、システム内の特定の操作を同じ利用者が行ったかどうかを主体が判定できないことが必要です [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).
リンクされていない仮名 (Unlinked Pseudonym): 仮名とその保有者との対応関係が、少なくとも当初は、保有者本人または利用者の信頼できるサーバーを除く誰にも分からない仮名です。[Pfi01]（同文献ではInitially Unlinked Pseudonymと呼ばれます）を参照してください。
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.)
明示的認証 (Explicit Authentication): 主張された身元が、メッセージの唯一の送信元（メッセージ認証）またはチャネルのエンドポイント（主体認証）であることを検証する行為です。さらに、その身元は、あらかじめ定義された名前空間の固定ラベル（電話番号や氏名など）のように、対象の実際の身元と容易に結び付きます。
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.
認可 (Authorization): 特定の資格情報を提示した主体に、特定のリソースへのアクセスなどの権利を与えてよいか判断する行為です。
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
("***>").
+---------+ +------------+
| | | |
| 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) に証明済みです（対象は通常、RMが所有する装置です）。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つとして、対象と位置情報受信者の識別情報、希望するデータ型、精度または空間解像度だけを含む部分的な位置情報オブジェクトを送り、必要な資格情報を保有する証明を提示してもよいです (MAY)。ただし、使用プロトコルがその部分的なオブジェクトを要求として解釈するかどうかは、プロトコルや文脈によって異なる場合があります (MAY)。位置情報受信者は、定期的な位置情報更新を求めることもできますが、これはおそらく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を使用省略可能なフィールドとして含まなければならない (MUST)」と記述されているとします。この要件が意味するのは次のことです。
o the document that defines the LO MUST define the LO field 'A',
o LOを定義するドキュメントは、LOフィールド「A」を定義しなければなりません (MUST)。
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は使用を省略可能なフィールドとして定義しなければなりません (MUST)（LOの個々のインスタンスには、フィールドAが含まれる場合も含まれない場合もあります (MAY)）。
Some Requirements read like this: "The LO definition MUST contain Field 'A', which MAY be an optional field." This requirement states that
要件には、たとえば「LOの定義は、使用省略可能なフィールドとして定義してもよい (MAY) フィールドAを含まなければならない (MUST)」と記述されるものもあります。この要件が意味するのは次のことです。
o the document that defines the LO MUST define the LO field 'A',
o LOを定義するドキュメントは、LOフィールド「A」を定義しなければなりません (MUST)。
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は、使用省略可能なフィールドとして定義しても、必須フィールドとして定義してもよいです (MAY)。使用省略可能と定義した場合、LOの個々のインスタンスにフィールドAを含めても含めなくてもかまいません (MAY)。省略不可と定義した場合は、すべてのLOインスタンスにフィールドAを含めなければなりません (MUST)。
Req. 1. (Location Object generalities)
要件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主体がサポートする位置情報オブジェクト (LO) を、構文と意味の両面で1つ定義しなければなりません (MUST)。
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) 位置情報オブジェクトの一部のフィールドは省略可能として定義してもよいです (MAY)。つまり、位置情報オブジェクトの個々のインスタンスに、そのフィールドが含まれる場合も含まれない場合もあります (MAY)。
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) 位置情報オブジェクトの一部のフィールドは「拡張」として定義してもよいです (MAY)。この場合、基本となる位置情報オブジェクトの定義ではフィールドの構文または意味が完全には定義されず、その使用が1つ以上の使用プロトコルに固有となる場合があります。
1.4) The Location Object MUST be extensible, allowing the definition of new attributes or fields.
1.4) 位置情報オブジェクトは、新しい属性やフィールドを定義できるよう、拡張可能でなければなりません (MUST)。
1.5) The object MUST be suitable for requesting and receiving a location.
1.5) 位置情報オブジェクトは、位置の要求と受信に適したものでなければなりません (MUST)。
1.6) The object MUST permit (but not require) the Privacy Rules to be enforced by a third party.
1.6) 位置情報オブジェクトは、第三者がプライバシールールを適用することを許容しなければなりません (MUST)。適用を必須にする必要はありません。
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で使用できなければなりません (MUST)。
1.8) The object MUST be usable in a secure manner even by applications on constrained devices.
1.8) 制約のある装置上のアプリケーションでも、位置情報オブジェクトを安全に使用できなければなりません (MUST)。
Req. 2. (Location Object fields) The Location Object definition MUST contain the following Fields, which MAY be optional to use:
要件2.（位置情報オブジェクトのフィールド）位置情報オブジェクトの定義は、次のフィールドを含まなければなりません (MUST)。これらのフィールドは使用省略可能としてもかまいません (MAY)。
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) 動きおよび方向のベクトル。このフィールドは省略可能でなければなりません (MUST)。
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: time-to-live）。これはデータ保持期間を制限するプライバシールールとは異なります。
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など）を含めてもよく (MAY)、限定ルール（要件11参照）を含めてもよく (MAY)、両方を含めてもかまいません。
2.9) Security-headers and -trailers (for instance encryption information, hashes, or signatures) (see Req. 14 and 15).
2.9) セキュリティヘッダーおよびトレーラー（暗号化情報、ハッシュ、署名など）（要件14および15参照）
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受信者（LOを受け取る主体）がサポートする位置データ型を少なくとも1つ定義しなければなりません (MUST)。
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種類の位置データ型を定義すべきです (SHOULD)。1つは緯度／経度／高度の座標用、もう1つはすべてのGeopriv受信者（LOを受け取る主体）がサポートする住所形式（市、通り、番地）用です。
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) 緯度／経度／高度のデータ型は、絶対値形式に加えて差分形式もサポートすべきです (SHOULD)。差分形式は、データサイズの削減やセキュリティ・機密性の要件に役立ちます。
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主体がサポートし、他の組織が定義する追加の位置データ型についても合意すべきです (SHOULD)。
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.
要件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.
要件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.
要件7.（LSのルール）位置サーバーが位置情報受信者に位置情報へのアクセスを許可する判断は、ルール作成者が定めたプライバシールールに基づかなければなりません (MUST)。
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のルール）位置情報生成者がルール作成者の定めた完全なプライバシールールを知らず、そのルールにアクセスできない場合でも、ルール作成者の指示に従って位置情報を送信しなければなりません (MUST)。たとえば、ルール作成者が指定したURIにのみLOを送信することで、この要件を満たせます (MAY)。
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.（閲覧者のルール）閲覧者は、ルール作成者が定めた完全なルールを知る必要はありません（閲覧者は位置情報を再送信すべきではないためです (SHOULD NOT)）。したがって、完全なプライバシールールに従ってLOを扱うために必要な範囲のルールだけを受け取るべきです (SHOULD)（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は、位置情報に関する幅広いプライバシールールを表現できるルール言語を定めてもよいです (MAY)。この言語には既存の言語、その拡張、新しい言語のいずれを使ってもよく (MAY)、できるだけ単純にすべきです (SHOULD)。
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は、位置情報に関する限定された一連のプライバシールールを表現できるルール言語を定めなければなりません (MUST)。この言語には既存の言語、その拡張、新しい言語のいずれを使ってもかまいません (MAY)。位置情報オブジェクトは、この限定されたルール一式を表すのに十分なフィールドとデータを含まなければなりません (MUST)。
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.（身元の保護）位置情報オブジェクトは、ルール作成者、対象、装置、位置情報受信者の各識別フィールドで、リンクされていない仮名を使用できなければなりません (MUST)。リンクされていない仮名は、当初は既知の身元と結び付いていない単なるビット列です。したがって、この要件は、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]で説明されるものなど）を含む、複数種類の資格情報を使用できるようにすべきです (SHOULD)。
Req. 14. (Security Features) The Location Object MUST support fields suitable for protecting the Object to provide the following security features:
要件14.（セキュリティ機能）位置情報オブジェクトは、オブジェクトを保護し、次のセキュリティ機能を実現するのに適したフィールドを備えなければなりません (MUST)。
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は、デジタル署名アルゴリズムと暗号化アルゴリズムについて実装必須の方式を含め、位置情報オブジェクトのセキュリティとして最低限実装すべき機能を定めなければなりません (MUST)。
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）プロトコルは、緊急通話で認証が失敗した場合にバイパスを許可すべきです (SHOULD)。
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など）へのブリッジ方法を規定すべきではありません (SHOULD NOT)。
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 (Message Authentication Code) または署名で認証します。複数の主体（複数の位置サーバーなど）が直接アクセスできる公開ルール保持者のルールは、通常、デジタル署名します。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?
さらに検討が必要な第三の状況は、利用者が認証できず、緊急センターも認証できない場合にどうするかです。それでも位置情報を送るのが妥当でしょうか。また、その場合に考慮すべきセキュリティ上の脅威はあるでしょうか。
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が求める場合、使用プロトコルは、位置サーバーや位置情報受信者に対してルール作成者、対象、装置の実際の身元を隠せるべきです。また、使用プロトコルは、位置サーバーに対して位置情報受信者の実際の身元も隠せるべきです (SHOULD)。
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) 長期にわたり対象の位置情報を取得した人の記録から、習慣や移動などが分かる可能性があります。位置情報サービス事業者が利用者のプライバシーを尊重すると約束し、法律や規制によって保護を義務付けられ、位置サーバーの不正や過失も排除できるとしても、外部からの攻撃、内部者による不正アクセス、技術的・人的ミス、法的手続きによって個人データが権限のない者に渡る危険は残ります。
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.
意図しない対象 (Unintended Target) とは、対象の近くにいることを理由に追跡される人または物です。対象が人ではない場合に、この状況がよく起こります。たとえば、車両在庫の追跡用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次元、2次元、または3次元）を表します。複数の位置を含める方法は別の文書で議論されています。現時点での大まかな合意は次のとおりです。LOの定義では、位置フィールドを省略可能とすること、ちょうど1つ含めること、または複数回含めることを許容してもよいです (MAY)。各位置フィールドには、同じ位置の別々の測定値または異なる形式を表す「位置表現」を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に含まれる位置情報が真実かどうかについて立場を示してはなりません (MUST)。したがって、LOは「私は真実のすべてを伝えている（または伝えていない）」と示す属性を含めてはなりません (MUST NOT)。
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のメンバーには、コメントと提案をいただきました。Aaron Burstein、Mehmet Ersue、Allison Mankin、Randall Gellens、およびサンディエゴと横浜で開かれたGeopriv会合の参加者から、詳しいコメントや文章案をいただきました。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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: 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/
[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 Guidelines on the Protection of Privacy and Transborder Flows of Personal Data, 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 Munich, Germany
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
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
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 Law University of California Berkeley, 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
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 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.
Copyright (C) The Internet Society (2004). この文書にはBCP 78に含まれる権利、ライセンス、制限が適用されます。同BCPに別段の定めがある場合を除き、著者はすべての権利を保持します。
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.
この文書およびここに含まれる情報は「現状有姿」で提供されます。寄稿者、その寄稿者が代表する、または支援を受ける組織（該当する場合）、Internet Society、およびInternet Engineering Task Forceは、明示または黙示を問わず、あらゆる保証を否認します。これには、ここに含まれる情報の使用がいかなる権利も侵害しないという保証、商品性または特定目的への適合性に関する黙示の保証が含まれますが、これらに限りません。
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 Editor機能の資金は、現在Internet Societyが提供しています。