RFC3693 日本語訳
3693 Geopriv Requirements. J. Cuellar, J. Morris, D. Mulligan, J.Peterson, J. Polk. February 2004. (Format: TXT=68881 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
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
コメントを求めるワーキンググループJ.クエリャルの要求をネットワークでつないでください: 3693年のジーメンス株式会社カテゴリ: 民主主義のための情報のJ.モリスセンターと技術D.マリガンサミュエルソン法、技術、および公共の方針のピーターソンNeuStar J.ポークコクチマス診療所J.2004年2月
Geopriv Requirements
Geopriv要件
Status of this Memo
この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.
Copyright(C)インターネット協会(2004)。 All rights reserved。
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)とこのLocation Objectを使用するプロトコルのための要件について説明します。 このLOは、しっかりと位置のデータを移すのにすべてのGeoprivプロトコル交換に使用されるプライマリデータ構造になるように思い描かれます。
Cuellar, et al. Informational [Page 1] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [1ページ]情報のRFC3693Geopriv要件2004年2月
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
1. 概要. . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2。 このDocumentのコンベンションUsed。 . . . . . . . . . . . . . . 4 3. 用語集. . . . . . . . . . . . . . . . . . . . . . . . . . . 4 4。 プライマリGeopriv実体. . . . . . . . . . . . . . . . . . . 6 5。 さらなるGeopriv用語。 . . . . . . . . . . . . . . . . . 7 5.1. 位置情報と目撃例。 . . . . . . . . . . . 7 5.2. 位置のオブジェクトとプロトコル. . . . . . . . . 9 5.3を使用すること。 非信じられたデータフロー. . . . . . . . . . . 10 5.4に対して信じられます。 さらなるGeopriv主体. . . . . . . . . . . . . . . 10 5.5。 プライバシーは統治されます。 . . . . . . . . . . . . . . . . . . . . . 12 5.6. 識別子、認証、および承認。 . . . . . 13 6. シナリオと説明している議論. . . . . . . . . . . . . 15 7。 要件. . . . . . . . . . . . . . . . . . . . . . . . . 19 7.1。 位置のオブジェクト。 . . . . . . . . . . . . . . . . . . . . 19 7.2. 使用プロトコル. . . . . . . . . . . . . . . . . . . 21 7.3。 ベースのLocation Data Transferを統治してください。 . . . . . . . . . . . 21 7.4. 位置のオブジェクトプライバシーとセキュリティ. . . . . . . . . . 22 7.4.1。 アイデンティティ保護。 . . . . . . . . . . . . . . 22 7.4.2. 認証要件。 . . . . . . . . . . 23 7.4.3. 保証される動作。 . . . . . . . . . . . . . 23 7.5. 非要件.248。 セキュリティ問題。 . . . . . . . . . . . . . . . . . . . 24 8.1. トラヒック分析. . . . . . . . . . . . . . . . . . . . 24 8.2。 プライバシーが規則. . . . . . . . . . . . . . . 24 8.3であると機密保護します。 救急箱. . . . . . . . . . . . . . . . . . . . . 24 8.4。 アイデンティティと匿名. . . . . . . . . . . . . . . . 25 8.5。 故意でない目標。 . . . . . . . . . . . . . . . . . . . 26 9. 後のConsideration. . . . . . . . 26 9.1のためのプロトコルとLO Issues。 1LO. . . . . . . . . . . . . . 26 9.2の複数のLocations。 翻訳分野. . . . . . . . . . . . . . . . . . . 26 9.3。 真実旗. . . . . . . . . . . . . . . . . . . . . . . 27 9.4。 情報形式を調節します。 . . . . . . . . . . . . . . . 27 9.5. 識別子の名前スペース。 . . . . . . . . . . . . . 27 10. 承認. . . . . . . . . . . . . . . . . . . . . . . 28 11。 参照. . . . . . . . . . . . . . . . . . . . . . . . . . 28 11.1。 引用規格. . . . . . . . . . . . . . . . . . 28 11.2。 有益な参照. . . . . . . . . . . . . . . . . 28 12。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 29 13。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 30
Cuellar, et al. Informational [Page 2] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [2ページ]情報のRFC3693Geopriv要件2004年2月
1. Overview
1. 概要
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に関する位置情報の収集と転送は重要なプライバシー意味を持つことができます。 本書では説明されたプロトコルの主要な目標は「Targetのユーザ/所有者」(セクション3と5.4で以下に与えられたこのドキュメントの用語で、より正確に「規則メーカー」)が用意ができさせたPrivacy Rulesによると、プライバシーの保護を容易にすることです。
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.
Targetの位置を集めて、生成する能力、および派生したか計算された位置へのアクセスはベースの位置のサービスプライバシー方程式の主要な要素です。 (a) ユーザのPrivacy Rulesを知って、それらの実体が続くと信じることができるか否かに関係なく、Targetのプライバシーに主要であるのは、生の位置のデータに近づく手段を持っていて、位置を派生するか、または計算する、そして/または、派生したか計算された位置情報に近づく手段を持っている実体、および(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) Location Objectのトランスミッションのセキュリティは、位置情報の保全と秘密性を保証するのに不可欠です。 これは、Location Objectの送付者と受信機を認証して、Location Object自身を固定するのを含んでいます。
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) 重要な役割はユーザによって制御されたPrivacy Rulesによって果たされます。(Privacy Rulesは課された制限か「ユーザ」(以下で定義されるときの「規則メーカー」)によって与えられた許容について説明します)。 Privacy RulesはLocation情報を使用できるLocation Recipient、状態、および目的にLocation Serverが情報をLocationに転送できる必要条件を指定します。
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) Privacy Rulesの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) Location ObjectはPrivacy Rulesの制限されるのにもかかわらずの、コアセットを運ぶはずであることができます。 巻き癖かフルセットにおけるそれらのRulesの正確なフォームか表情の豊かさについて、より詳しく本書では議論しませんが、このワーキンググループによって製作された将来のドキュメントで、より手広く議論するでしょう。
Cuellar, et al. Informational [Page 3] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [3ページ]情報のRFC3693Geopriv要件2004年2月
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) 適切であるときはいつも、ユーザの正体に位置情報をリンクするべきではありませんでしたか、または静的な識別子は容易にユーザ(すなわち、名前、郵送先住所、電話番号、社会保険番号、Eメールアドレスまたはユーザ名などのPersonally Identifiable情報)の正体につないで戻りました。 むしろ、ユーザは、どのローカルの識別子、放された匿名、または個人的な識別子が位置情報に制限されているかことであるかと指定できるべきです。
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.
いくつかのアプリケーションには、法的な規制のため、または事実上、いくつかの位置のサービスが明白な識別を必要とするかもしれないので完全な匿名は適切でないかもしれませんが、たいてい位置のサービスはタイプの承認情報、そして/または、恐らく問題の実体の匿名の識別子を必要とするだけです。
2. Conventions Used in this Document
2. このDocumentのコンベンションUsed
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"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[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.
ここで議論した要件がジェネリックLocation Objectと位置のサービスにプロトコルを使用することに関する要件であることに注意してください。 このようにして、そして、だいたい、本書では議論した要件は実装するために義務的な能力について言及します。 例えば、実装が保全をサポートするのが必要であるのは、すべてのプロトコルトラフィックが認証されるのが必要であるのと同じものではありません。 対照的に、使用するために義務的なaに関する例、(ちょうど義務的でない、-、-道具) 要件は彼の位置のデータが認証されなかったとき、ユーザがいつも通知を受け取ると述べるものであるかもしれません。 この習慣は、使用するために道具だけでないのに義務的です。
3. Glossary
3. 用語集
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): 初めは、Targetの位置を決定するか、または集めて、Targetの位置について説明するLocation Objectsを作成する実体。
Cuellar, et al. Informational [Page 4] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [4ページ]情報のRFC3693Geopriv要件2004年2月
Location Object (LO): An object conveying location information
(and possibly privacy rules) to which Geopriv security
mechanisms and privacy rules are to be applied.
位置のオブジェクト(最低気温): 位置情報(そして、ことによるとプライバシー規則)をどの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と封鎖されている国境に付けられます。(例えば 緯度とLongitude境界).
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, 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 Location Objectによって伝えられる人か他の実体。
Using Protocol: A protocol that carries a Location Object.
使用プロトコル: 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 Location Objectによって伝えられますが、さらにこの情報を通過しない位置情報を消費するプリンシパル。
Cuellar, et al. Informational [Page 5] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [5ページ]情報のRFC3693Geopriv要件2004年2月
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.
解決とPrecisionは非常に近い用語です。品質は位置情報が粗雑であるように'減少できます': ユーザの位置の周りでオフセンター周辺を定義するか、またはそうでなければ、位置決め情報(秒から数分まで経度と緯度を丸くして、言う)の有効数字を捨てることによって考慮(状態から国まで、言う)と'精度'における領域を拡大するのによる'解決'。 WGが記録する別のものはずっと多くの詳細にこの話題について議論します。
4. Primary Geopriv Entities
4. プライマリGeopriv実体
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 | |
+----------+ +----------+ +----------+
+----------+ | 規則| | 所有者| | | +----+-----+ | 規則|インタフェースV+----------+ +----------+ +----------+ |位置| 公表| 位置| 通知|位置| |ジェネレータ+-------------->| サーバ+-------------->|受取人| | | インタフェース| | インタフェース| | +----------+ +----------+ +----------+
The four primary Entities are described as follows:
4プライマリEntitiesが以下の通り説明されます:
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): 初めは、Targetの位置を決定するか、または集めて、その位置について説明するLocation Objectsを作成する実体。 LGsはLocation ServersにLocation Objectsを発行します。 Geoprivプロトコルの範囲の外にLocation GeneratorがLocation情報を知っている方法があります。
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はLocation GeneratorsからLocation Objectsの刊行物を受け取って、Location Recipientsから購読を受けるかもしれない要素です。 LSは規則(それがRule Holderから学ぶ)をそれがLGsから受けるLOsに適用して、次に、必要に応じて結果として起こるLOsについてLRsに通知します。
Cuellar, et al. Informational [Page 6] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [6ページ]情報のRFC3693Geopriv要件2004年2月
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はLocation ServersからLocation Objectsの通知を受け取る要素です。 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は特定のTargetsのためにLocation Objectsを受けて、フィルターにかけて、分配するためにPrivacy Rulesを収容する要素です。 LSが1セットの規則のためにRHについて質問するかもしれませんか、または規則はRHからLSまで押されるかもしれません。 Rule Holderの規則はRule Makerによって居住されます。
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.
したがって、Location Generationは集会Location情報のプロセスです、恐らく複数のソースから、IPベースのGeopriv Entity、LGで。(LGは他のGeopriv Entitiesとコミュニケートします)。
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実体の間のインタフェースは必ずプロトコルインタフェースであるというわけではありません。 それらは単一の落ち着いたデバイスの中の内部のインタフェースであるかもしれません。 いくつかのアーキテクチャでは、Location Generator、Rule Holder、およびLocation Serverは同じデバイスですべて実装されるかもしれません。 特定のLocation ServerでPrivacy Rulesを実施する数個のRule Holdersがあるかもしれません。
5. Further Geopriv Terminology
5. さらなる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.
(2)以下で詳細な用語と定義は両方の用語的にそれを含んで、そのうえ、プライマリGeopriv実体、(1)はこのドキュメントの要件部で使用されます、そして、Geopriv Location Objectのために思い描かれた用法モデルに関する追加詳細を明らかにしてください。 これらの後者の用語は別々のシナリオドキュメントとほかの場所で利用されるでしょう。
5.1. Location Information and Sighting
5.1. 位置情報と目撃例
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ワーキンググループの焦点を一般に、それが基づいていないTargetの位置か公的に手があいているソースの情報にありますが、個人情報で提供するか、またはTargetのTarget、TargetのDevice、ネットワークまたはサービスプロバイダーが作成しています。 個人的な位置情報のこの焦点にもかかわらず、確かに、公的に手があいているソースから位置情報を伝えるのにGeopriv Location Objectを使用できました。
Location Information: A relatively specific way of describing
where a Device is located.
位置情報: Deviceがどこに位置しているかを説明する比較的特定の方法。
Cuellar, et al. Informational [Page 7] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [7ページ]情報のRFC3693Geopriv要件2004年2月
This Location Information may have been determined in many different ways, including:
このLocation情報は多くの異なった道、包含で決定していたかもしれません:
(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)、一般に、公的にアドレス可能であるか、またはアクセスしやすくないかもしれないDeviceで断固とした(b)、または(c)がTargetによって入力したか、または別の方法で提供されました。
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.
例として、Location情報は(a) 携帯電話塔、(b)経度、および緯度に関するワイヤレスの信号の上で質問に対応してDeviceでGPS(グローバル測位衛星)能力、Targetによって手動で携帯電話かラップトップに入力された(c)情報に決定している情報を三角にするか、またはある他のIPプロトコルで自動的に提供された(d)を三角にすることによって計算された情報を含むかもしれません、DHCPを通したデバイス構成などのように。
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.
この定義から除かれているのは、完全な知識のない位置情報の決断かTarget(または、Targetのネットワークかアクセスサービスプロバイダー)の同意です、IPかEメールアドレスの一般に利用可能な情報に基づいて。 いくつかの場合、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:
どんな与えられた位置のベースのトランザクションの中ではも、位置(そして、その結果、Location情報の初期の作成)のINITIAL決断は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.
目撃例: 位置の初期の決断は情報を非公開情報(Location情報の定義で議論するように)、およびLocationの初期の作成に基礎づけました。
Some variant of the sighting information is included in the Location Object. Abstractly, it consists of two separate data fields:
目撃情報のある異形がLocation Objectに含まれています。 抽象的に、2つの別々のデータ・フィールドから成ります:
(Identifier, Location)
(識別子、位置)
Cuellar, et al. Informational [Page 8] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [8ページ]情報のRFC3693Geopriv要件2004年2月
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が見つけられるTargetに割り当てられた識別子であり、Locationが見つけられるそのTargetの現在の位置であるところ。 すべての実体がまさに同じ目撃例情報に近づく手段を持っているかもしれないというわけではありません。 目撃例は新しい目撃例組に変えられるかもしれません:
(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.
以前、それはLocation GeneratorかLocation ServerによってLocation Recipientに提供されます。 この場合、Identifier-1はPseudonymであるかもしれません、そして、Location-1には、精度か解決より元の値があるかもしれません。
5.2. The Location Object and Using Protocol
5.2. 位置のオブジェクトとプロトコルを使用すること。
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ワーキンググループの第一目的はLocation情報と基本的なプライバシーを保護する指示の両方を伝えるのに使用されるために、Location Object(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.
位置のオブジェクト(最低気温): このデータはTarget、およびTarget、時間情報、コアPrivacy Rules、固有識別文字などのアイデンティティか匿名を含む他の分野に関するLocation情報を含んでいます。 Location情報自体を含んでいて、分野の大部分は任意です。
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.
「使用プロトコル」はLocation Objectを使用する(読むか、または変更します)プロトコルです。 一連のビットとしてただそれら(IPストレージプロトコルができたように)を見ないでLOを輸送するプロトコルは使用プロトコルではなく、トランスポート・プロトコルにすぎません。 それにもかかわらず、実体かプロトコルがその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.
2つのタイプにはLOを保護するのに使用されるメカニズムを高めるセキュリティとプライバシーがあります: まず最初にLocation Object定義が分野を含まなければならない、さもなければ、メカニズムは以前はよくそういうもののLOを固定していました。 LO MAY、例えば、LO自身の一部として暗号のチェックサムか暗号化を使用することで、機密保護されてください。 また、2番目に、使用プロトコルは、しっかりとLocation Objectを輸送するためにセキュリティー対策を提供するかもしれません。
Cuellar, et al. Informational [Page 9] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [9ページ]情報のRFC3693Geopriv要件2004年2月
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を定義するとき、デザインは、Location Object自身のセキュリティー対策が好まれることであることを観測するべきです。 したがって、LO MUSTの定義は何らかの最小量の暗号の機能性を含んでいます。(Req。 14と15). そのうえ、RMが特定のLOセキュリティー対策の使用を指定するなら、それを使用しなければなりません。(Req。 4).
5.3. Trusted vs. Non-trusted Data Flows
5.3. 非信じられたデータフローに対して信じられます。
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:
異なった関係はPrivacy Rulesを伝える必要性を含むプライバシー規則の実装に関する異なった心配を高めます。 例えば、公共のRule Holderはプライバシーが問題であると扱うより効率的なメソッドが存在するところで信じられた環境で不要であるかもしれません。 次の用語は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.
非信じられたデータは流れます: データフローは位置がプライバシーであると扱う先在の契約上の関係によって支配されません。
5.4. Further Geopriv Principals
5.4. さらなるGeopriv主体
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.
以下を狙ってください。 位置がLocation Recipientによって望まれている実体。 多くの場合、TargetはDeviceが付けている乗り物か運送用コンテナなどのDeviceかオブジェクトの人間の」になるでしょう「ユーザ。 ある場合にTargetはDeviceにな自体でしょう。
Device:
The technical device whereby the location is tracked as a proxy
for the location of a Target.
デバイス: 位置が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.
例えば、Deviceは携帯電話、Global Positioning Satellite(GPS)受信機、ワイヤレスのアクセスDeviceを備えていたラップトップ、または跡をつけるか、または見つけることができる信号を放つ送信機であるかもしれません。 Targetが手動で、位置情報(恐らくウェブブラウザがある)を入力する時などのいくつかの状況で、事実上、TargetはDeviceの機能を実行しています。
Cuellar, et al. Informational [Page 10] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [10ページ]情報のRFC3693Geopriv要件2004年2月
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 Targetに適切なPrivacy Rulesを設定する承認がある個人か実体。 多くの場合、これはDeviceの所有者になるでしょう、そして、他の場合では、Deviceの所持にいるユーザであるかもしれません。 例えば、両親は、子供の携帯電話から得られた位置情報がどうなるかを制御するかもしれません。 会社は、対照的に、携帯電話を従業員に所有して、提供するかもしれませんが、従業員がプライバシー規則を設定することを許可してください。
There are four scenarios in which some form of constraint or
override might be placed on the Privacy Rules of the Rule
Maker:
何らかのフォームの規制かオーバーライドがRule MakerのPrivacy Rulesに置かれるかもしれない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. 緊急サービス(合衆国の中の911Eなどの)の場合では、地方の、または、国家の法は、正確な位置情報が、ある定義された緊急通報状況で伝えられるのを必要とするかもしれません。 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. 雇用関係か他の契約上の関係の文脈では、特定の位置(法人のキャンパスなどの)の所有者はRule MakerによるPrivacy Rulesの使用に規制を課すかもしれません。 それは特定の宿泊設備がこの状況を容易にするためにされる作業部会への期待ではありません。
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. 政府の権威が非緊急事態でRule MakerによるPrivacy Rulesの使用に規制を課そうとするのが想像できます。 それは特定の宿泊設備がこの状況を容易にするためにされる作業部会への期待ではありません。
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.
ビューアー: Targetに関する位置のデータを受け取って、する個人か実体がTargetかRule MakerほどTargetの位置(TargetかTargetから方向を追い立てなどなどの)に基づく位置情報か情報をどんなパーティーOTHERにも伝えません。
Cuellar, et al. Informational [Page 11] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [11ページ]情報のRFC3693Geopriv要件2004年2月
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は理論的にDeviceとLocation ServerかLocation Serverと第2のLocation Serverか、Location ServerとViewerの間のほとんどどんなトランスミッションにもかかわることができました。 いくつかの位置追尾シナリオは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): 初期のネットワークアクセスを提供するドメイン、Deviceのコミュニケーション機能の操作に、不可欠の他のデータ通信またはDeviceが作動するコンピュータ機器。 しばしば、APはLGを含んでいます。(APは無線電話会社か、インターネットサービスプロバイダか、内部の企業ネットワークになるでしょう)。 APには時々、「馬鹿な」LG(Geopriv LOsを伝えますが、Geopriv Location Objectの少しの部分も使用しないもの)があります。 他のケースは少しのAPにもかかわらないかもしれませんか、またはAPがData Transporterとして機能するだけであるかもしれません。
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情報に関して即座の取引を完了するのに必要な持続時間より長い間どんな期間の間のデータベースなどの生の、または、処理されたLocation情報も保存するDeviceか実体。
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).
Location Storageの存在とデータ保存練習がプライバシー問題に重要である、これがことに影響を及ぼすかもしれないので、結局、Location情報を明らかにすることができました(より遅い分配、技術的な不履行、または法的なプロセスを通して)。
5.5. Privacy Rules
5.5. プライバシー規則
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].
プライバシーRulesは位置情報の位置、他の情報、包含、他、収集、使用、公開、および保有に関して実体の活動を規制する規則です。 一般に、そのような規則は公正な情報習慣に基づいています、(例えば、)PrivacyのProtectionとパーソナルData[OECD]のTransporter Flowsの上のOECD Guidelinesで詳しく述べられるように。
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.
プライバシー規則: 位置情報の収集、使用、公開、および保有を含む位置情報に関して実体の活動を規制する規則の規則かセット。 特に、Ruleは位置情報が実体によって使用されるかもしれなくて、どれが位置情報を変えたかがどの条件のもとでどうリリースされるかもしれないかをどの実体に説明するか。 規則に従わなければなりません。 それらは顧問ではありません。
Cuellar, et al. Informational [Page 12] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [12ページ]情報のRFC3693Geopriv要件2004年2月
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.
Privacy Rulesのフルセットはおそらく1つの可能な技術的な意味しか持っていない規則と場所の行き渡っている法と習慣で影響を受ける規則の両方を含むでしょう。例えば、「そのような資格証明書の所有者とそのような精度か解決で私の位置を明らかにすることができるだけである」というフォームの分配規則には、LOを使用するプロトコルのための明快な意味があります。 しかし、他の規則には、保有や用法Rulesのように、プロトコルかかかわった実体のための不明瞭な技術的な結果があるかもしれません。 例えば、「あなたは2日間以上私の位置を保存できません」と述べる保有規則の正確な範囲は地域法か習慣を一部つけるかもしれません。
5.6. Identifiers, Authentication and Authorization
5.6. 識別子、認証、および承認
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.
匿名は身元保証可能でないことの(1セットの対象の中の)特性です。 匿名はプライバシーのための規範事例として機能します: 匿名のままで残る能力がなければ、個人はそれら自身のプライバシーを制御できないかもしれません。 Unlinkabilityは、ユーザがこれらの用途を互いにリンクできる複数の他のもののいないリソースの、または、サービスの用途をするかもしれないのを確実にします。 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).
匿名を放します: 匿名とその所有者の間のリンクが少なくとも初めは所有者自体の可能な例外かユーザの信じられたサーバをもっているだれにとっても知られていない匿名。 [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」であるとして別の実体Bを認証するならラベル「イドB」が実体のよく知られるか、a少なくともリンク可能なアイデンティティであることを基本的に意味します。 この場合、ラベル「イド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.)
明白な認証: メッセージの唯一の創始者(通報認証)かチャンネルのエンドポイント(実体認証)を要求されたアイデンティティについて確かめる行為。 そのうえ、このアイデンティティは容易に問題の実体の正体にリンクして戻されます、例えば、事前に定義された名前スペースからの先在の静的なラベルであり(電話番号、名前など)
Cuellar, et al. Informational [Page 13] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [13ページ]情報のRFC3693Geopriv要件2004年2月
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.
資格証明書のタイプに頼っていて、承認はExplicit Authenticationを含意するかもしれません。
Cuellar, et al. Informational [Page 14] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [14ページ]情報のRFC3693Geopriv要件2004年2月
6. Scenarios and Explanatory Discussion
6. シナリオと説明している議論
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.
この例では、Targetは全地球測位システム(GPS)を使用することでその人の位置を知りたがっています、そして、Deviceは位置を決定するために独自に生データを処理できます。 位置は以下の通り引き出されます: DeviceはGPS衛星からトランスミッションを受けて、内部的に計算して、位置を表示します。 これはクローズドシステムです。 これとその後の例の目的のために、GPS衛星が信号を使用するDevicesのアイデンティティか居場所の周りに何らかの信号を放送して、情報を全く持っていないと思われます。
GPS Satellite
|
| Sighting (not a Geopriv Interface)
|
|
|
V GPS Device
--------------------------------------------------
/ \
| Location ----- Location ----- Location |
| Generator Server Storage |
\ | /
-------------------------------------------|------
|
| Notification
| Interface
|
------------|------
/ V \
/ Target Location \
| Recipient |
| |
\ Rule Maker /
\ /
-------------------
GPS衛星| | (Geoprivインタフェースでない)を見つけます。| | | V GPSデバイス-------------------------------------------------- / \ | 位置----- 位置----- 位置| | ジェネレータサーバストレージ| \ | / -------------------------------------------|------ | | 通知| インタフェース| ------------|------ /V\/目標位置、\| 受取人| | | \規則メーカー/\/-------------------
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 DeviceはAPとLGの両方です。 Rule MakerのDeviceに起こるので、相互作用はTrusted環境で起こります。
Cuellar, et al. Informational [Page 15] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [15ページ]情報のRFC3693Geopriv要件2004年2月
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).
この例では、携帯電話はホームサービスエリア(ローミング)の外で使用されます。 また、携帯電話サービスプロバイダー(携帯電話Corp2)は携帯電話用法の会計を社外調達しました。 携帯電話はGPSによって可能にされません。 位置はTargetとDeviceが移動している携帯電話ネットワークによって引き出されます。 Targetが携帯電話を使用したがっているとき、携帯電話Corp1(AP)はローミング・サービスをTargetに供給します。(Targetは携帯電話への用法(例えば、呼び出しの持続時間、ローミングネットワークにおける位置など)に関する生データにCorp2(ホームサービスプロバイダー)を送ります)。 携帯電話Corp2は会計会社に生データを提出します。(それは、会計報告のための生データを処理します)。 最終的に、生データがLocation Server(例えば、コンピュータサーバ)に保存されるところにデータウェアハウスに生データを送ります。
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 |
\ / \ /
------------- ----------
携帯電話Corp1携帯電話Corp2----------------- ----------------- 目撃例/\は/\デバイスを発行します。----- | データ運送者| --------- | データ運送者| 目標\/インタフェース\/----------------- / ----------------- / | / | 通知/| インタフェース----------- | /V------------ / ---------- /\//\/位置の\/| 位置| | ストレージ| 位置のインフォメーション| ストレージ| | | <、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、|、|、| 位置| | 位置| | 受取人| | 受取人| \ / \ / ------------- ----------
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.
ここで、携帯電話Corp1は、APとLGです。 このシナリオでは、Cell電話Corp2はTrusted実体である傾向がありますが、携帯電話Corp1はNonによって信じられるかもしれません。
Cuellar, et al. Informational [Page 16] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [16ページ]情報のRFC3693Geopriv要件2004年2月
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 Service Providerがあるショーの下における図。 メッセージのいくつかが例えばアイデンティティか匿名と、資格証明書とそれら、Rules、およびLocation Data情報所有物の証拠を運ぶのにLocation Objectを使用します、Data TypesとPrecisionかResolutionを含んでいて。 理解性のために言及されるべきであるのを除いて、Location Objectを使用しないで、Geopriv WGの範囲の外にあるメッセージは主演された矢(「***>」)として図に示されます。
+---------+ +------------+
| | | |
| Location|<** | Public |
|Generator| * | Rule Holder|
| | * | |
+---------+\ * +------------+
\ *3 1a* *
\ * * *
\ ** *
\ * * *1a
\* * *
* \ * *
* \ * *
* \4 * *
* \ * V
* \->+-----------+
+----------+ 1 | Location |
| Rule |--------------------->| Server + |
| Maker | | Private |
+----------+ |Rule Holder|
+-----------+
^ |
3| |5
| V
+----------+
| Location |
| Recipient|
+----------+
+---------+ +------------+ | | | | | 位置|<** | 公衆| |ジェネレータ| * | 規則所有者| | | * | | +---------+\ * +------------+ \*3 1a**\***\***\***1a\****\***\***\4***\*V*\>+-----------+ +----------+ 1 | 位置| | 規則|、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、-、--、>| サーバ+| | メーカー| | 個人的| +----------+ |規則所有者| +-----------+ ^ | 3| |5 | +に対して----------+ | 位置| | 受取人| +----------+
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,
Rule MakerとTargetがLocation Serverに登録されると仮定してください。RMは、本当に、彼がTargetのプライバシー権利の所有者(通常、TargetはRule Makerによって所有されていたDeviceである)であるとLSにどうにか立証しました。 Rule MakerとLocation Serverはそれらが互いを認証するのに使用するキーか資格証明書と暗号の材料のセットに同意しました。
Cuellar, et al. Informational [Page 17] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [17ページ]情報のRFC3693Geopriv要件2004年2月
and in particular, to authenticate or sign the Rules. How this has been done is outside of the scope of the document.
そして、特定でRulesに認証するか、または署名するために。 これがどう完了していたかがドキュメントの範囲の外にあります。
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: 転送を統治してください: Rule MakerはRuleをLocation Serverに送ります。このRuleはLocation Objectの分野であるかもしれません。
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: 署名している規則: 代替手段として、Rule MakerはRuleに書いて、それをPublic Rule Holderに置くかもしれません。 実体は、署名しているRulesを読むために倉庫にアクセスします。
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: 位置情報要求: Location RecipientはTargetのための位置情報を要求します。 この要求では、Location Recipientは、それがどの位置のインフォメーション・データを好むかを選択するかもしれません。 Location情報を要求する1つの方法が部分的にいっぱいにされたLocation Objectを送るかもしれません、TargetとLocation Recipientのアイデンティティと必要なData Typeと精度か解決だけ、および必要な資格証明書の所有物の提供証拠を含んでいて。 しかし、使用プロトコルが要求としてこの部分的にいっぱいにされたオブジェクトを理解しているかどうかが使用プロトコル、または、文脈によるかもしれません。 また、Location Recipientは周期的な位置情報最新版の必要性を指定できましたが、たぶん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: 場所を見つけます: Location Serverがどんな現在の位置情報も持っていないTargetのためにLocation情報Requestを受けるとき、サーバは、Targetの場所を見つけるようにLocation Generatorに頼むかもしれません。
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: 位置情報: Location Generatorは「完全な」位置情報をLocation Serverに送ります。このLocation情報はLocation Objectに埋め込まれるかもしれません。
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: フィルターにかけることの位置情報: Location Serverは位置情報をLocation Recipientに送ります。 情報は一般に、それほど正確でないバージョンか情報の計算されたバージョンが提供されているという意味でフィルターにかけられるかもしれません。
Cuellar, et al. Informational [Page 18] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [18ページ]情報のRFC3693Geopriv要件2004年2月
7. Requirements
7. 要件
7.1. Location Object
7.1. 位置のオブジェクト
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の定義に関する要件を指定しているのを覚えていてください。 いくつかのRequirementsがこのように読めます: 「LO定義は任意の分野としてField'A'を含まなければなりません。」 この要件はそれを述べます。
o the document that defines the LO MUST define the LO field 'A',
o LO MUSTを定義するドキュメントは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'を使用するために任意であると定義しなければならない、(分野'A'をLO MAYについて例証しないか、含まないかもしれない、)
Some Requirements read like this: "The LO definition MUST contain Field 'A', which MAY be an optional field." This requirement states that
いくつかのRequirementsがこのように読めます: 「LO定義はField'A'を含まなければなりません」。(Fieldは任意の分野であるかもしれません)。 この要件はそれを述べます。
o the document that defines the LO MUST define the LO field 'A',
o LO MUSTを定義するドキュメントは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 MAYのどんなインスタンスにも任意であると定義されないか、分野'A'を含まないかもしれないなら。 それが任意でないなら、LOsのすべてのインスタンスが分野'A'を含まなければなりません。
Req. 1. (Location Object generalities)
Req。 1. (位置のObjectの一般性)
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は1Location Object(LO)を定義しなければなりません。 -- 構文と意味論における両方--すべてのGeopriv実体でそれをサポートしなければなりません。
1.2) Some fields of the Location Object MAY be optional. This
means that an instance of a Location Object MAY or may not contain
the fields.
1.2) Location Objectのいくつかの分野が任意であるかもしれません。 これは、Location Objectのインスタンスが分野を含むかもしれないことを意味します。
1.3) Some fields of the Location Object MAY be defined as
"extensions". This means that the syntax or semantics of these
fields is not fully defined in the basic Location Object
definition, but their use may be private to one or more of the
using protocols.
1.3) Location Objectのいくつかの分野が「拡大」と定義されるかもしれません。 これは、これらの分野の構文か意味論が基本的なLocation Object定義で完全に定義されるというわけではありませんが、彼らの使用が使用プロトコルの1つ以上に個人的であるかもしれないことを意味します。
1.4) The Location Object MUST be extensible, allowing the
definition of new attributes or fields.
1.4) 新しい属性か分野の定義を許して、Location Objectは広げることができるに違いありません。
1.5) The object MUST be suitable for requesting and receiving a
location.
1.5) オブジェクトは位置を要求して、受けるのに適当であるに違いありません。
Cuellar, et al. Informational [Page 19] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [19ページ]情報のRFC3693Geopriv要件2004年2月
1.6) The object MUST permit (but not require) the Privacy Rules to
be enforced by a third party.
1.6) しかし、オブジェクトが可能にしなければならない、(必要でない、)、第三者によって実施されるべきPrivacy Rules。
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. (位置のObject分野) Location Object定義は以下のフィールズを含まなければなりません:(フィールズは、使用するために任意であるかもしれません)。
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) 位置のRecipient Identity Thisのアイデンティティは、マルチキャストかグループのアイデンティティであるかもしれません、マルチキャストベースの使用プロトコルにLocation Objectを含むのにおいて、使用されています。
2.3) Location Recipient Credential
2.3) 位置の受取人資格証明書
2.4) Location Recipient Proof-of-Possession of the Credential
2.4) 資格証明書所有物の位置の受取人証拠
2.5) Location Field
2.5) 位置の分野
2.5.1) Motion and direction vectors. This field MUST be optional.
2.5.1) 動きと方向ベクトル。 この分野は任意であるに違いありません。
2.6) Location Data Type
2.6) 位置のデータ型
When transmitting the Location Object, the sender and the receiver
must agree on the data type of the location information. The
using protocol may specify that the data type information is part
of the Location Object or that the sender and receiver have agreed
on it before the actual data transfer.
Location Objectを伝えるとき、送付者と受信機は位置情報に関するデータ型に同意しなければなりません。 使用プロトコルは、データ型情報がLocation Objectの一部であるか送付者と受信機が実際のデータ転送の前にそれに同意したと指定するかもしれません。
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) Location情報はいつ正確でしたか? (時間を見つけます) (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) 分野を統治してください: この分野は適切なRule(例えば、完全なRuleへのURI)への紹介であるかもしれませんかそれが株式会社Ruleを含むかもしれません。(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) バージョン番号
Cuellar, et al. Informational [Page 20] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [20ページ]情報のRFC3693Geopriv要件2004年2月
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) Location Objectは、すべてのGeopriv受信機(LOsを受ける実体)によってサポートされるために少なくとも1Location Data Typeを定義しなければなりません。
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) Location Object SHOULDは2Location Data Typesを定義します: 緯度/経度/高度座標のためのものとすべてのGeopriv受信機によってサポートされた民間位置(市、通りNumber)へのもの(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) また、緯度/経度/高度Data Type 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) Location Object定義SHOULDはいくつかのGeopriv実体によってサポートされて、他の組織によって定義された一層のLocation Data Typesに同意します。
7.2. The Using Protocol
7.2. 使用プロトコル
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. 使用プロトコルは指示がLocation Objectと対応するRulesで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(後のConsiderationのためのプロトコルとLO Issues)を見てください。
7.3. Rule based Location Data Transfer
7.3. ベースのLocation Data Transferを統治してください。
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規則) Location ServerがLocation情報へのLocation Recipientアクセスを提供するという決定をRule Makerによって定義されたPrivacy Rulesに基礎づけなければなりません。
Cuellar, et al. Informational [Page 21] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [21ページ]情報のRFC3693Geopriv要件2004年2月
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.
それはPrivacy Rulesが管理されて、Location ServerがPrivacy Rulesに近づく手段を持っている私たちの範囲の外にあります。 いくつかの規則が信頼されていないパーティーのために意図しない個人情報を含んでいるということであるかもしれないことに注意してください。
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規則) Location Generatorは気づかなくて、完全Privacy RulesへのアクセスがRule Makerで定義した欠乏、Location Generatorです。Rule Makerによって設定された指示に従ってLocation情報を伝えなければなりません。 そのようなコンプライアンスはRule Makerによって指定されたURIだけにLOを伝えるLocation Generatorによって実行されるかもしれません。
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. (ビューアー規則) ViewerがRule Makerによって定義された完全なRulesを意識している必要はなくて(a Viewer SHOULDがLocation情報を再送しないので)、その結果、a Viewer SHOULDがViewerが完全なPrivacy Rulesに従ってLOを扱うのに必要なPrivacy Rulesの部分集合だけを受け取る、(あれほど、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. (完全なRule言語) Geoprivは位置情報に関してさまざまなプライバシー規則を表すことができるRule言語を指定するかもしれません。 このRule言語は簡単であるかもしれません。存在1つか既存のものの適合か新しいRule言語と、それが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.
Req。 11. (株式会社Rule言語) Geoprivは位置情報に関して限られたセットのプライバシー規則を表すことができる限られたRule言語を指定しなければなりません。 このRule言語は、既存のもの、既存のものの適合または新しいRule言語であるかもしれません。 Location Objectは、限られたセットのプライバシー規則を表すために十分な分野とデータを含まなければなりません。
7.4. Location Object Privacy and Security
7.4. 位置のオブジェクトプライバシーとセキュリティ
7.4.1. Identity Protection
7.4.1. アイデンティティ保護
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. (アイデンティティ保護) Location ObjectはRule Maker、Target、Device、およびLocation Recipientの対応する識別分野でのUnlinked Pseudonymsの使用をサポートしなければなりません。 Unlinked Pseudonymsが単に初めはよく知られるアイデンティティにリンクされないビット列であるので、LOで使用されるIdentifiersのための名前スペースが多くの未使用のストリングを含むことができるくらい大きくなければならないと言うまでこの要件は沸騰します。
Cuellar, et al. Informational [Page 22] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [22ページ]情報のRFC3693Geopriv要件2004年2月
7.4.2. Authentication Requirements
7.4.2. 認証要件
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. (資格証明要件) 使用プロトコルとLocation Object SHOULDは異なった資格証明タイプの使用を許します、プライバシーを高める資格証明書(例えば[Bra00]か[Cha85]で説明されたもの)を含んでいて。
7.4.3. Actions to be secured
7.4.3. 保証される動作
Req. 14. (Security Features) The Location Object MUST support fields
suitable for protecting the Object to provide the following
security features:
Req。 14. (セキュリティ機能) Location Objectは以下のセキュリティ機能を提供するためにObjectを保護するのに適当な分野をサポートしなければなりません:
14.1) Mutual end-point authentication: the using protocol is
able to authenticate both parties in a Location Object
transmission,
14.1) 互いのエンドポイント認証: 使用プロトコルはLocation Objectトランスミッションで双方を認証できます。
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(恐らく構成可能であり、Rule Makerによって受け入れられる時間の小さい窓を除いた)自身を使用したのと同じ実体によって再演されないかもしれません。
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はLocation Objectセキュリティ、デジタル署名アルゴリズムと暗号化アルゴリズムのために暗号アルゴリズムを実装するために義務的な包含を実装するために義務的な最小限を指定しなければなりません。
15.2) It MAY also define further mandatory to implement
Location Object security mechanisms for message authentication
codes (MACs) or other purposes.
15.2) また、それはさらなるメッセージ確認コード(MACs)に道具Location Objectセキュリティー対策に義務的であるか他の目的を定義するかもしれません。
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
最後のポイントで扱われた問題は最小量の認証が失敗するならいくつかの好ましくない状況における緊急通報が終了しないかもしれないということです。 これはたぶんユーザがそうしたいことではありません。起こってください。 ユーザは非認証された呼び出しを好むかもしれません。
Cuellar, et al. Informational [Page 23] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [23ページ]情報のRFC3693Geopriv要件2004年2月
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.
どんな呼び出し完成の上でも彼が攻撃者と話しているか、または彼の情報が保証されないリスクでさえ非常時のサーバを非認証しませんでした。
7.5. Non-Requirements
7.5. 非要件
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仕様SHOULD NOTは非IPネットワーク(PSTNなど)にブリッジすることを指定します。
8. Security Considerations
8. セキュリティ問題
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 Location Objectの目的と使用プロトコルに関する要件は位置のサービスのための位置情報のPrivacy Ruleによって制御された公開を許すことです。
8.1. Traffic Analysis
8.1. トラヒック分析
The information carried within the Location Object is secured in a way compliant with the privacy and security Rules of the Rule Maker, but other information, carried in other objects or headers are in general not secured in the same way. This means that Geopriv may not as a general matter, secure the Target against general traffic analysis attacks or other forms of privacy violations.
ある意味でプライバシーで言いなりになった状態でLocation Objectの中で運ばれた情報を保証します、そして、一般に、同様に、Rule MakerのセキュリティRules(他の情報だけ)が他のオブジェクトで運んだか、またはヘッダーを固定しません。 これは、Geoprivが一般的な件としてそうしないかもしれないことを意味して、一般的なトラヒック分析攻撃か他の形式のプライバシー違反に対してTargetを固定してください。
8.2. Securing the Privacy Rules
8.2. プライバシーが規則であると機密保護します。
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.
Targetの位置のRule MakerのPrivacy Rulesが公共の、または、非公共のRule HolderのLocation Serverにアクセスしやすいかもしれませんか、彼らがLocation Objectによって運ばれるかもしれませんか、または彼らは能力かトークンとしてLocation Recipientによって提示されるかもしれません。 それ自身の特定の道であることをRuleの各タイプを保証しなければなりません。
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.
非公共のRule Holderの規則はMAC(メッセージ立証コード)か署名を使用することで通常認証されます、使用されるキーのタイプに頼っていて。 通常、公共のRule Holder(原則としていくつかの実体、例えば、直接数個のLocation Serversによってアクセスされるかもしれないもの)の規則はデジタルに調印されます。 LOのフィールズがLO自身の一部として機密保護されると裁決してください。 Geopriv Token(彼の位置情報にアクセスするためにRule Makerの明白な同意を言い表して、Rule MakerによってLocation Recipientに発行されたトークンかチケット)は認証されるか、または署名されます。
8.3. Emergency Case
8.3. 救急箱
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
認証センターがそれ自体を認証しないので、認証が緊急通報に失敗するところで状況を考えさせてください。 この場合実装することの1つの方法
Cuellar, et al. Informational [Page 24] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [24ページ]情報のRFC3693Geopriv要件2004年2月
authentication bypass for emergency calls (mentioned in Req 15.3) is to let the user have the choice of writing a Rule that says:
ユーザは緊急通報(Req15.3では、言及される)のための認証迂回で言うRuleに書くことの選択を持つことができることになっています:
- "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.
2番目に、ユーザがそれ自体を認証しないかもしれないので緊急通報の認証が失敗する場合では、質問は起こります: 使用へのRule? デフォルト1を使用するのは妥当です: この位置情報を非常災害対策本部に送ることができるだけです。
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番目の状況(さらに詳細に研究されるべきである)は以下の通りです。 するべきことかユーザだけがそれ自体を認証しませんが、非常災害対策本部はまた「正統-可能」ではありませんか? とにかくLocation情報を送るのが妥当ですが、何か考えなければならない軍事的脅威がありますか?
8.4. Identities and Anonymity
8.4. アイデンティティと匿名
The use of Unlinked Pseudonyms is necessary to obtain anonymity.
Unlinked Pseudonymsの使用が、匿名を得るのに必要です。
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.
Unlinked Pseudonymsの使用の目的は以下です: 使用プロトコルはRule Maker、Target、およびDeviceの正体を隠すことができるべきです、Location ServersかLocation Recipientsから、必要ならRM。 また、使用はSHOULDについて議定書の中で述べます。Location Recipientの正体をLocation Serverから隠すことができてください。
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.
この最後の場合では、Targetは彼を特定するServerに関して心配していて、彼の位置を知るのではなく、彼のビジネスパートナーを特定して、したがって、彼の習慣などを特定することです。 (a) この知識がTargetのアイデンティティを推論するのに使用されるかもしれなくて、(b) Location Recipientのアイデンティティに関する知識がTargetを当惑させるか、または秘密情報を破るかもしれなくて、(c) だれが長日月の間、Targetの位置情報を得ているかを言う関係書類が習慣、動きなどで知らせることができるとLocation Recipientsの正体が含む隠れることに推論します。 位置のサービスプロバイダーをユーザのプライバシーを尊敬するのに同意して、ユーザのプライバシーを保護する法か規則で強制し、Location Serverの不正行為か怠慢を除外できても、個人的なデータがなるかもしれないリスクがまだ部外者からの攻撃、インサイダーからの不正アクセス、技術的であるか人間の誤り、または法的なプロセスを通して権限のない人にとって利用可能な状態であります。
Cuellar, et al. Informational [Page 25] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [25ページ]情報のRFC3693Geopriv要件2004年2月
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.
いくつかの時に、Location Serverは、だれが特定のTargetにPrivacy Rulesを供給しているかを知らなければなりません、他の状況で、Rulesの供給者がそうするのに権限を与えられるのを知るのが十分であるかもしれませんが。
8.5. Unintended Target
8.5. 故意でない目標
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はTargetの近接で跡をつけられた人かオブジェクトです。 この特別なケースはTargetが人でないなら最も頻繁に現れます。 例えば、Targetは車の目録を追跡するのに使用されるGPS Deviceを備えていたレンタカーであるかもしれません。 レンタルの会社はドライバーの位置を心配しないかもしれませんが、ドライバーのプライバシーはそれとなく影響を受けます。
Geopriv may or may not protect or affect the privacy of Unintended Targets, but the impact on Unintended Targets should be acknowledged.
GeoprivはUnintended Targetsのプライバシーに保護するか、または影響するかもしれませんが、Unintended Targetsの上の影響は承認されるべきです。
9. Protocol and LO Issues for later Consideration
9. 後のConsiderationのためのプロトコルとLO Issues
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.
このセクションは簡潔にこのドキュメントの以前のバージョンの議論の間に現れているLocation Objectに関連する問題かプロトコルについて論じます。
9.1. Multiple Locations in one LO
9.1. 1LOの複数のLocations
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ポイント表すFieldが意図する位置か1つの領域、(1、2、または3、次元的) 別のドキュメントで複数の所在地の包含の可能性について議論します。 現在の荒いコンセンサスは以下です: LO定義で、Location Fieldは任意であるか、あるとき、まさに現れるか、または何度か起こるかもしれません。 各Location Fieldは1「位置の表現」を含むかもしれません。それはそれぞれ異なった測定か同じ位置の異なった形式を表すつもりです。 しかし、複数のLocationフィールズと複数の表現を使用するための他の可能性があります: 多分数個のLocationフィールズが、同じように報告するのにまた、使用プロトコルに依存できた同じデバイス、または他の目的のためにいろいろな時間、または複数のセンサ位置で異なった形式、または複数の目撃例で見つけながら、使用されるでしょう。 これはすべてさらなる議論のためのものです。
9.2. Translation Fields
9.2. 翻訳分野
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つが別のものに関する翻訳であることを示すために分野を含んでいるのは可能です。 また、これが完了しているなら、アイデンティティとメソッドとして翻訳者を特定する分野を持っているのも可能です。
Cuellar, et al. Informational [Page 26] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [26ページ]情報のRFC3693Geopriv要件2004年2月
9.3. Truth Flag
9.3. 真実旗
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 MUST NOTは「私は全体の真実をあなたに言っています(または、ありません)」と言うオブジェクトに属性を供給します。
9.4. Timing Information Format
9.4. タイミング情報形式
The format of timing information is out of the scope of this document.
このドキュメントの範囲の外にタイミング情報の形式があります。
9.5. The Name Space of Identifiers
9.5. 識別子の名前スペース
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.
だれがIdentitiesを定義するか: 使用プロトコルがIdentifiersを定義できるか、使用は、使用について議定書の中で述べて、または使用プロトコルの如何にかかわらず選ばれたRulesによって提案されたPseudonymsを認証しなければなりませんか? もちろん、匿名として使用されるかもしれなくて、定期的に新しいものに取り替えられるかもしれない多くの未使用の名前を含んでいて、使用プロトコルに適切な名前空間があるなら、Location Objectはスペースという名前を使用できるかもしれません。 このために、ユーザは、たぶんこの名前スペースを使用することで彼のRulesに書かなければならないでしょう。 定期的に中古の匿名を変えるのが必要であることに注意してください、放された匿名の後ろでユーザを特定するのが非常に簡単である場合があるので。
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 埋め込まれた認証は、より簡単でしょう、使用プロトコルには適所にある認証のアイデンティティのための資格証明書が既にしばしばあって、「埋め込まれた」認証がIdentifiersのフォームで独立しているだろうというとき
o the size of the names would be fixed.
o 名前のサイズは固定されるでしょう。
On the other hand, the benefits of the Rule choosing the identifiers are:
他方では、識別子を選ぶRuleの利益は以下の通りです。
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 Locationオブジェクトがプロトコル限界のむこうにある複数のシステムを織り込むことは容易にされます。
Cuellar, et al. Informational [Page 27] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [27ページ]情報のRFC3693Geopriv要件2004年2月
10. Acknowledgements
10. 承認
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のメンバーに感謝申し上げます。 サンディエゴと横浜でのGeoprivミーティングのアーロンBurstein、メーメトErsue、アリソン・マンキン、ランドルGellens、および関係者は詳細なコメントかテキストを提供しました。
11. References
11. 参照
11.1. Normative Reference
11.1. 引用規格
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。
11.2. Informative References
11.2. 有益な参照
[Bra00] Stefan A.: Rethinking Public Key Infrastructures and
Digital Certificates : Building in Privacy, MIT Press;
ISBN: 0262024918; 1st edition, August, 2000
[Bra00]ステファンA.: 意識改革公開鍵暗号基盤とデジタル証明書: プライバシーにおけるビル、MITプレス。 ISBN: 0262024918; 最初の版、2000年8月
[Cha85] Chaum, David: Security without Identification, Card
Computers to make Big Brother Obsolete. Original Version
appeared in: Communications of the ACM, vol. 28 no. 10,
October 1985 pp. 1030-1044. Revised version available at
http://www.chaum.com/articles/
[Cha85] Chaum、デヴィッド: Identification、ビッグブラザーObsoleteを作るCardコンピュータのないセキュリティ。 オリジナルのバージョンは以下に現れました。 ACMに関するコミュニケーション、vol.28No.10、1985年10月ページ 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 のTransborder流れ。
[Pfi01] Pfitzmann, Andreas; Koehntopp, Marit: Anonymity,
Unobservability, and Pseudonymity - A Proposal for
Terminology; in: H Federrath (Ed.): Designing Privacy
Enhancing Technologies; Proc. Workshop on Design Issues in
Anonymity and Unobservability; LNCS 2009; 2001; 1-9. Newer
versions available at
http://www.koehntopp.de/marit/pub/anon
[Pfi01] Pfitzmann、アンドレアス。 Koehntopp、マリット: 匿名、Unobservability、および偽名--用語のための提案。 中: H Federrath編: 技術を高める設計のプライバシー。 Proc。 匿名とUnobservabilityのデザイン問題に関するワークショップ。 LNCS2009。 2001; 1-9. http://www.koehntopp.de/marit/pub/anon で利用可能なより新しいバージョン
Cuellar, et al. Informational [Page 28] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [28ページ]情報のRFC3693Geopriv要件2004年2月
12. Authors' Addresses
12. 作者のアドレス
Jorge R Cuellar Siemens AG Corporate Technology CT IC 3 81730 Munich, Germany
ホルヘRクエリャルシーメンスの株式会社の法人の技術コネチカットIC3 81730ミュンヘン(ドイツ)
EMail: Jorge.Cuellar@siemens.com
メール: Jorge.Cuellar@siemens.com
John B. Morris, Jr. Director, Internet Standards, Technology & Privacy Project Center for Democracy & Technology 1634 I Street NW, Suite 1100 Washington, D.C. 20006 USA
民主主義のためのジョンB.モリス、Jr.ディレクター、インターネット規格、技術、およびプライバシープロジェクトセンターとNW、技術1634I通りスイート1100米国ワシントンDC20006
EMail: jmorris@cdt.org URI: http://www.cdt.org
メール: jmorris@cdt.org ユリ: http://www.cdt.org
Deirdre K. Mulligan Samuelson Law, Technology & Public Policy Clinic Boalt Hall School of Law University of California Berkeley, CA 94720 USA
ディアドラK.マリガンサミュエルソン法、技術、および公立の方針診療所ボールト・ホール法学大学院カリフォルニア大学バークレー、カリフォルニア94720米国
EMail: dmulligan@law.berkeley.edu URI: http://www.law.berkeley.edu/cenpro/samuelson/
メール: dmulligan@law.berkeley.edu ユリ: http://www.law.berkeley.edu/cenpro/samuelson/
Jon Peterson NeuStar, Inc. 1800 Sutter St Suite 5707 Concord, CA 94520 USA
5707年のジョンピーターソンNeuStar Inc.1800サター通りスイート一致、カリフォルニア94520米国
EMail: jon.peterson@neustar.biz URI: http://www.neustar.biz/
メール: jon.peterson@neustar.biz ユリ: http://www.neustar.biz/
James M. Polk Cisco Systems 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
ジェームスM.ポークシスコシステムズ2200の東社長のジョージ・ブッシュ・Turnpikeテキサス75082リチャードソン(米国)
EMail: jmpolk@cisco.com
メール: jmpolk@cisco.com
Cuellar, et al. Informational [Page 29] RFC 3693 Geopriv Requirements February 2004
クエリャル、他 [29ページ]情報のRFC3693Geopriv要件2004年2月
13. Full Copyright Statement
13. 完全な著作権宣言文
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)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Cuellar, et al. Informational [Page 30]
クエリャル、他 情報[30ページ]
一覧
スポンサーリンク
