RFC4745 日本語訳
4745 Common Policy: A Document Format for Expressing PrivacyPreferences. H. Schulzrinne, H. Tschofenig, J. Morris, J. Cuellar, J.Polk, J. Rosenberg. February 2007. (Format: TXT=63602 bytes) (Status: PROPOSED STANDARD)
プログラムでの自動翻訳です。
英語原文
Network Working Group H. Schulzrinne
Request for Comments: 4745 Columbia U.
Category: Standards Track H. Tschofenig
Siemens Networks GmbH & Co KG
J. Morris
CDT
J. Cuellar
Siemens
J. Polk
J. Rosenberg
Cisco
February 2007
Schulzrinneがコメントのために要求するワーキンググループH.をネットワークでつないでください: 4745年のコロンビアU.カテゴリ: 標準化過程H.TschofenigジーメンスネットワークGmbHと共同kg J.モリスCDT J.クエリャルシーメンスJ.ポークJ.ローゼンバーグコクチマス2007年2月
Common Policy: A Document Format for Expressing Privacy Preferences
共通政策: プライバシー好みを言い表すためのドキュメント・フォーマット
Status of This Memo
このメモの状態
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。
Copyright Notice
版権情報
Copyright (C) The IETF Trust (2007).
IETFが信じる著作権(C)(2007)。
Abstract
要約
This document defines a framework for authorization policies controlling access to application-specific data. This framework combines common location- and presence-specific authorization aspects. An XML schema specifies the language in which common policy rules are represented. The common policy framework can be extended to other application domains.
このドキュメントはアプリケーション特有のデータへのアクセスを制御する承認方針のためにフレームワークを定義します。 このフレームワークは一般的な位置と存在特有の承認局面を結合します。 XML図式は共通政策規則が表される言語を指定します。 他のアプリケーションドメインに共通政策フレームワークを広げることができます。
Schulzrinne, et al. Standards Track [Page 1] RFC 4745 Common Policy February 2007
Schulzrinne、他 方針2007年2月に一般的な標準化過程[1ページ]RFC4745
Table of Contents
目次
1. Introduction ....................................................3
2. Terminology .....................................................4
3. Modes of Operation ..............................................4
3.1. Passive Request-Response - PS as Server (Responder) ........5
3.2. Active Request-Response - PS as Client (Initiator) .........5
3.3. Event Notification .........................................5
4. Goals and Assumptions ...........................................6
5. Non-Goals .......................................................7
6. Basic Data Model and Processing .................................8
6.1. Identification of Rules ....................................9
6.2. Extensions .................................................9
7. Conditions .....................................................10
7.1. Identity Condition ........................................10
7.1.1. Overview ...........................................10
7.1.2. Matching One Entity ................................11
7.1.3. Matching Multiple Entities .........................11
7.2. Single Entity .............................................14
7.3. Sphere ....................................................15
7.4. Validity ..................................................16
8. Actions ........................................................17
9. Transformations ................................................18
10. Procedure for Combining Permissions ...........................18
10.1. Introduction .............................................18
10.2. Combining Rules (CRs) ....................................18
10.3. Example ..................................................19
11. Meta Policies .................................................21
12. Example .......................................................21
13. XML Schema Definition .........................................22
14. Security Considerations .......................................25
15. IANA Considerations ...........................................25
15.1. Common Policy Namespace Registration .....................25
15.2. Content-type Registration for
'application/auth-policy+xml' ............................26
15.3. Common Policy Schema Registration ........................27
16. References ....................................................27
16.1. Normative References .....................................27
16.2. Informative References ...................................28
Appendix A. Contributors ..........................................29
Appendix B. Acknowledgments .......................................29
1. 序論…3 2. 用語…4 3. 操作のモード…4 3.1. 受動態要求応答(サーバ(応答者)としてのPS)…5 3.2. 能動態要求応答(クライアント(創始者)としてのPS)…5 3.3. イベント通知…5 4. 目標と仮定…6 5. 非目標…7 6. 基礎データモデルと処理…8 6.1. 規則の識別…9 6.2. 拡大…9 7. 状態…10 7.1. アイデンティティ状態…10 7.1.1. 概要…10 7.1.2. マッチング1実体…11 7.1.3. 複数の実体を合わせます…11 7.2. 単一体…14 7.3. 球…15 7.4. 正当性…16 8. 動作…17 9. 変換…18 10. 許容を結合するための手順…18 10.1. 序論…18 10.2. 結合は(CRs)を統治します…18 10.3. 例…19 11. メタ方針…21 12. 例…21 13. XML図式定義…22 14. セキュリティ問題…25 15. IANA問題…25 15.1. 共通政策名前空間登録…25 15.2. 'アプリケーション/auth-方針+xml'のための文書内容登録…26 15.3. 共通政策図式登録…27 16. 参照…27 16.1. 標準の参照…27 16.2. 有益な参照…28 付録A.貢献者…29 付録B.承認…29
Schulzrinne, et al. Standards Track [Page 2] RFC 4745 Common Policy February 2007
Schulzrinne、他 方針2007年2月に一般的な標準化過程[2ページ]RFC4745
1. Introduction
1. 序論
This document defines a framework for creating authorization policies for access to application-specific data. This framework is the result of combining the common aspects of single authorization systems that more specifically control access to presence and location information and that previously had been developed separately. The benefit of combining these two authorization systems is two-fold. First, it allows building a system that enhances the value of presence with location information in a natural way and reuses the same underlying authorization mechanism. Second, it encourages a more generic authorization framework with mechanisms for extensibility. The applicability of the framework specified in this document is not limited to policies controlling access to presence and location information data, but can be extended to other application domains.
このドキュメントは、アプリケーション特有のデータへのアクセスのための承認方針を作成するためにフレームワークを定義します。 このフレームワークはただ一つの承認システムの一般相を結合するという以前に別々により明確に存在、位置情報、およびそれへのコントロールアクセスを開発してあったという結果です。 これらの2台の承認システムを結合する利益は二面です。 まず最初に、それで、位置情報で自然な方法で存在の値を高めて、同じ基本的な承認メカニズムを再利用するシステムを構築します。 2番目に、それはaを奨励します。伸展性のためのメカニズムがある、より多くのジェネリック承認フレームワーク。 本書では指定されたフレームワークの適用性を存在へのアクセスを制御する方針と位置のインフォメーション・データに制限されませんが、他のアプリケーションドメインに広げることができます。
The general framework defined in this document is intended to be accompanied and enhanced by application-specific policies specified elsewhere. The common policy framework described here is enhanced by domain-specific policy documents, including presence [7] and location [8]. This relationship is shown in Figure 1.
本書では定義された一般的なフレームワークは、ほかの場所で指定されたアプリケーション特定保険証券で伴われて、高められることを意図します。 ここで説明された共通政策フレームワークは存在[7]と位置[8]を含むドメイン特定保険証券ドキュメントによって高められます。 この関係は図1に示されます。
+-----------------+
| |
| Common |
| Policy |
| |
+---+---------+---+
/|\ /|\
| |
+-------------------+ | | +-------------------+
| | | enhance | | |
| Location-specific | | | | Presence-specific |
| Policy |----+ +----| Policy |
| | | |
+-------------------+ +-------------------+
+-----------------+ | | | 一般的| | 方針| | | +---+---------+---+ /|\ /|\ | | +-------------------+ | | +-------------------+ | | | 機能アップ| | | | 位置の特有です。| | | | 存在特有です。| | 方針|----+ +----| 方針| | | | | +-------------------+ +-------------------+
Figure 1: Common Policy Enhancements
図1: 共通政策増進
This document starts with an introduction to the terminology in Section 2, an illustration of basic modes of operation in Section 3, a description of goals (see Section 4) and non-goals (see Section 5) of the policy framework, followed by the data model in Section 6. The structure of a rule, namely, conditions, actions, and transformations, is described in Sections 7, 8, and 9. The procedure for combining permissions is explained in Section 10 and used when conditions for more than one rule are satisfied. A short description
このドキュメントはセクション2の用語に序論から始まります、とセクション3の基本的な運転モードのイラスト、目標の記述(セクション4を見る)、および方針フレームワークの非目標(セクション5を見る)はセクション6のデータモデルで次に続かせました。 すなわち、規則、状態の構造(動作、および変換)は、セクション7、8、および9で説明されます。 1つ以上の規則のための状態が満たされているとき、許容を結合するための手順は、セクション10で説明されて、用いられます。 短い記述
Schulzrinne, et al. Standards Track [Page 3] RFC 4745 Common Policy February 2007
Schulzrinne、他 方針2007年2月に一般的な標準化過程[3ページ]RFC4745
of meta policies is given in Section 11. An example is provided in Section 12. The XML schema will be discussed in Section 13. IANA considerations in Section 15 follow security considerations in Section 14.
メタでは、セクション11で方針を与えます。 セクション12に例を提供します。 セクション13でXML図式について議論するでしょう。 セクション15のIANA問題はセクション14のセキュリティ問題に従います。
2. Terminology
2. 用語
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 [1].
キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTは[1]で説明されるように本書では解釈されることであるべきですか?
This document introduces the following terms:
このドキュメントは次の用語を紹介します:
PT - Presentity / Target: The PT is the entity about whom
information has been requested.
PT--Presentity/目標: 太平洋標準時は情報が要求されている実体です。
RM - Rule Maker: The RM is an entity that creates the authorization
rules that restrict access to data items.
RM--メーカーを統治してください: RMはアクセスをデータ項目に制限する承認規則を作成する実体です。
PS - (Authorization) Policy Server: This entity has access to both
the authorization policies and the data items. In location-
specific applications, the entity PS is labeled as location
server (LS).
PS--(承認)方針サーバ: この実体は承認方針とデータ項目の両方に近づく手段を持っています。位置の特定のアプリケーションでは、実体PSは位置のサーバ(LS)としてラベルされます。
WR - Watcher / Recipient: This entity requests access to data items
of the PT. An access operation might be a read, a write, or any
other operation.
WR--ウォッチャー/受取人: この実体は太平洋標準時のデータ項目へのアクセスを要求します。 アクセス操作は読書、aが書くということであるかもしれませんかいかなる他の、が操作です。
A policy is given by a 'rule set' that contains an unordered list of 'rules'. A 'rule' has a 'conditions', an 'actions', and a 'transformations' part.
方針は'規則'の順不同のリストを含む'規則セット'によって与えられています。 '規則'には、'状態'、'動作'、および'変換'部分があります。
The term 'permission' indicates the action and transformation components of a 'rule'.
'許可'という用語は'規則'の動作と変換コンポーネントを示します。
The term 'using protocol' is defined in [9]. It refers to the protocol used to request access to and to return privacy-sensitive data items.
'プロトコルを使用する'という用語は[9]で定義されます。 それは項目と、そして、リターンプライバシー極秘データ項目へのアクセスを要求するのに使用されるプロトコルを示します。
3. Modes of Operation
3. 運転モード
The abstract sequence of operations can roughly be described as follows. The PS receives a query for data items for a particular PT, via the using protocol. The using protocol (or more precisely, the authentication protocol) provides the identity of the requestor, either at the time of the query or at the subscription time. The authenticated identity of the WR, together with other information provided by the using protocol or generally available to the server,
以下の通り手荒く操作の抽象的な系列について説明できます。 PSは特定のPTのために使用プロトコルでデータ項目のための質問を受けます。 使用プロトコル(より正確に、認証は議定書を作る)は質問時点か購読時に要請者のアイデンティティを提供します。 使用プロトコルで提供されたか一般に、サーバに利用可能な他の情報に伴うWRの認証されたアイデンティティ
Schulzrinne, et al. Standards Track [Page 4] RFC 4745 Common Policy February 2007
Schulzrinne、他 方針2007年2月に一般的な標準化過程[4ページ]RFC4745
is then used for searching through the rule set. All matching rules are combined according to a permission combining algorithm described in Section 10. The combined rules are applied to the application data, resulting in the application of privacy based on the transformation policies. The resulting application data is returned to the WR.
そして、規則セットを隅々まで捜すために、使用されます。 セクション10で説明された許可結合アルゴリズムによると、すべての合っている規則が結合されます。 変換方針に基づくプライバシーのアプリケーションをもたらして、結合した規則はアプリケーションデータに適用されます。 結果として起こるアプリケーションデータをWRに返します。
Three different modes of operation can be distinguished:
3つの異なった運転モードを区別できます:
3.1. Passive Request-Response - PS as Server (Responder)
3.1. 受け身の要求応答--サーバとしてのPS(応答者)
In a passive request-response mode, the WR queries the PS for data items about the PT. Examples of protocols following this mode of operation include HTTP, FTP, LDAP, finger, and various remote procedure call (RPC) protocols, including Sun RPC, Distributed Computing Environment (DCE), Distributed Component Object Model (DCOM), common object request broker architecture (Corba), and Simple Object Access Protocol (SOAP). The PS uses the rule set to determine whether the WR is authorized to access the PT's information, refusing the request if necessary. Furthermore, the PS might filter information by removing elements or by reducing the resolution of elements.
受け身の要求応答モードで、WRは太平洋標準時頃にデータ項目のためにPSについて質問します。 この運転モードに従うプロトコルに関する例はHTTP、FTP、LDAP、指、および様々な遠隔手続き呼び出し(RPC)プロトコルを含んでいます、Sun RPC、Distributed Computing Environment(DCE)、分散型コンポーネント・オブジェクト・モデル(DCOM)、一般的なオブジェクト要求ブローカーアーキテクチャ(Corba)、およびSimple Object Access Protocol(SOAP)を含んでいて。 PSはWRがPTの情報にアクセスするのが認可されるかどうか決定するのに規則セットを使用します、必要なら、要求を拒否して。 その上、PSは、要素を取り除くか、または要素の解決を抑えることによって、情報をフィルターにかけるかもしれません。
3.2. Active Request-Response - PS as Client (Initiator)
3.2. 活発な要求応答--クライアントとしてのPS(創始者)
Alternatively, the PS may contact the WR and convey data items. Examples include HTTP, SIP session setup (INVITE request), H.323 session setup or SMTP.
あるいはまた、PSはWRに連絡して、データ項目を伝えるかもしれません。例はHTTP、SIPセッションセットアップ(INVITE要求)、H.323セッションセットアップまたはSMTPを含んでいます。
3.3. Event Notification
3.3. イベント通知
Event notification adds a subscription phase to the "Active Request- Response - PS as Client (Initiator)" mode of operation. A watcher or subscriber asks to be added to the notification list for a particular presentity or event. When the presentity changes state or the event occurs, the PS sends a message to the WR containing the updated state. (Presence is a special case of event notification; thus, we often use the term interchangeably.)
イベント通知は「能動態は応答を要求します--クライアント(創始者)としてのPS」という運転モードに購読フェーズを追加します。 ウォッチャーか加入者が、特定のpresentityかイベントのための通知リストに追加されるように頼みます。 変化が述べるpresentityかイベントが起こると、PSはアップデートされた状態を含むWRにメッセージを送ります。 (存在はイベント通知の特別なケースです; その結果、私たちはしばしば用語を互換性を持って使用します。)
In addition, the subscriber may itself add a filter to the subscription, limiting the rate or content of the notifications. If an event, after filtering by the rule-maker-provided rules and by the subscriber-provided rules, only produces the same notification content that was sent previously, no event notification is sent.
それ自体が購読にフィルタを加えて、制限されて、さらに、加入者はそうするかもしれません。通知のレートか内容。 イベントが規則メーカーが提供された規則と加入者によって提供された規則によるフィルタリングの後に以前に送られたのと同じ通知内容を作り出すだけであるなら、イベント通知を全く送りません。
Schulzrinne, et al. Standards Track [Page 5] RFC 4745 Common Policy February 2007
Schulzrinne、他 方針2007年2月に一般的な標準化過程[5ページ]RFC4745
A single PS may authorize access to data items in more than one mode. Rather than having different rule sets for different modes all three modes are supported with a one rule set schema. Specific instances of the rule set can omit elements that are only applicable to the subscription model.
独身のPSは1つ以上のモードによるデータ項目へのアクセスを認可するかもしれません。 すべての3つのモードが1つの規則セット図式でサポートされる異なったモードのための異なった規則セットを持っているよりむしろ。 規則セットの特定のインスタンスは購読モデルだけに適切な要素を省略できます。
4. Goals and Assumptions
4. 目標と仮定
Below, we summarize our design goals and constraints.
以下に、私たちはデザイン目標と規制をまとめます。
Table representation:
表現を見送ってください:
Each rule must be representable as a row in a relational database.
This design goal should allow efficient policy implementation by
utilizing standard database optimization techniques.
それぞれの規則は関係型データベースの行として「表-可能」であるに違いありません。 このデザイン目標は、標準のデータベース最適化手法を利用することによって、効率的な政策の実施を許容するべきです。
Permit only:
許可証専用:
Rules only provide permissions rather than denying them. Removing
a rule can never increase permissions. Depending on the
interpretation of 'deny' and 'permit' rules, the ordering of rules
might matter, making updating rule sets more complicated since
such update mechanisms would have to support insertion at specific
locations in the rule set. Additionally, it would make
distributed rule sets more complicated. Hence, only 'permit'
actions are allowed that result in more efficient rule processing.
This also implies that rule ordering is not important.
Consequently, to make a policy decision requires processing all
rules.
規則はそれらを否定するよりむしろ許容を提供するだけです。 規則を取り除くと、許容を決して増強できません。 '''許可証を否定してください'の解釈によるのは統治されて、規則の注文は重要であるかもしれません、作成がそのようなアップデートメカニズムが特定の位置で規則セットで挿入をサポートしなければならないでしょう、したがって、さらに複雑にされた規則セットをアップデートして。 さらに、それで、分散規則セットをさらに複雑にするでしょう。 より効率的な規則処理におけるその結果は'許可証'動作だけに許容されています。 また、これは、規則注文が重要でないことを含意します。 その結果、政策決定をするのは、すべての規則を処理するのを必要とします。
Additive permissions:
付加的な許容:
A query for access to data items is matched against the rules in
the rule database. If several rules match, then the overall
permissions granted to the WR are the union of those permissions.
A more detailed discussion is provided in Section 10.
データ項目へのアクセスのための質問は規則データベースの規則に取り組まされます。 いくつかの規則が合っているなら、WRに承諾された総合的な許容はそれらの許容の組合です。 より詳細な議論をセクション10に提供します。
Upgradeable:
Upgradeable:
It should be possible to add additional rules later, without
breaking PSs that have not been upgraded. Any such upgrades must
not degrade privacy constraints, but PSs not yet upgraded may
reveal less information than the rule maker would have chosen.
後でアップグレードしていない壊れているPSsなしで付則を加えるのは可能であるべきです。 どんなそのようなアップグレードもプライバシー規制を下がらせてはいけませんが、まだアップグレードしていなかったPSsは、規則メーカーより少ない情報が選ばれたのを明らかにするかもしれません。
Schulzrinne, et al. Standards Track [Page 6] RFC 4745 Common Policy February 2007
Schulzrinne、他 方針2007年2月に一般的な標準化過程[6ページ]RFC4745
Capability support:
能力サポート:
In addition to the previous goal, a RM should be able to determine
which extensions are supported by the PS. The mechanism used to
determine the capability of a PS is outside the scope of this
specification.
前の目標に加えて、RMは、どの拡大がPSによってサポートされるかを決定するはずであることができます。メカニズムは、以前はよくこの仕様の範囲の外にPSの能力があることを決定していました。
Protocol-independent:
プロトコル独立者:
The rule set supports constraints on both notifications or queries
as well as subscriptions for event-based systems such as presence
systems.
規則セットは存在システムなどのイベントベースのシステムのための通知か質問と購読の両方で規制をサポートします。
No false assurance:
誤った保証がありません:
It appears more dangerous to give the user the impression that the
system will prevent disclosure automatically, but fail to do so
with a significant probability of operator error or
misunderstanding, than to force the user to explicitly invoke
simpler rules. For example, rules based on weekday and time-of-
day ranges seem particularly subject to misinterpretation and
false assumptions on part of the RM. (For example, a non-
technical RM would probably assume that the rules are based on the
time zone of his current location, which may not be known to other
components of the system.)
システムが自動的に公開を防ぐという印象をユーザに与えるのが、より危険に見えますが、したがって、オペレータエラーか誤解の重要な確率を処理しないでください、ユーザにより簡単な規則を明らかに呼び出させるより。 例えば、規則はRMの一部で平日、-特に誤解を条件として日では、範囲が見える時、および誤った前提を基礎づけました。 (例えば、非技術的なRMは、たぶん規則が彼の現在の位置の時間帯に基づいていると仮定するでしょう。)位置はシステムの他の部品に知られていないかもしれません。
5. Non-Goals
5. 非目標
We explicitly decided that a number of possibly worthwhile capabilities are beyond the scope of this first version. Future versions may include these capabilities, using the extension mechanism described in this document. Non-goals include:
私たちは、多くのことによると価値がある能力がこの最初のバージョンの範囲を超えていると明らかに決めました。 本書では説明された拡張機能を使用して、将来のバージョンはこれらの能力を含むかもしれません。 非目標は:
No external references:
外部参照がありません:
Attributes within specific rules cannot refer to external rule
sets, databases, directories, or other network elements. Any such
external reference would make simple database implementation
difficult and hence they are not supported in this version.
特定の規則の中の属性は外部の規則セット、データベース、ディレクトリ、または他のネットワーク要素を参照できません。 どんなそのような外部参照でも簡単なデータベース実装は難しくなるでしょう、そして、したがって、それらはこのバージョンでサポートされません。
No regular expressions:
正規表現がありません:
Conditions are matched on equality or 'greater-than'-style
comparisons, not regular expressions, partial matches such as the
SQL LIKE operator (e.g., LIKE "%foo%"), or glob-style matches
("*@example.com"). Most of these are better expressed as explicit
elements.
または、「状態が平等で合わせられている、'、すばらしさ、-、'正規表現ではなく、比較を流行に合わせてください、SQL LIKEオペレータなどの部分的なマッチ、(例えば」 %がfooするLIKE、%、」、)、または、塊スタイルマッチ(" *@example.com ")。 これらの大部分は明白な要素として言い表されるほうがよいです。
Schulzrinne, et al. Standards Track [Page 7] RFC 4745 Common Policy February 2007
Schulzrinne、他 方針2007年2月に一般的な標準化過程[7ページ]RFC4745
No repeat times:
反復時間がありません:
Repeat times (e.g., every day from 9 am to 4 pm) are difficult to
make work correctly, due to the different time zones that PT, WR,
PS, and RM may occupy. It appears that suggestions for including
time intervals are often based on supporting work/non-work
distinctions, which unfortunately are difficult to capture by time
alone. Note that this feature must not be confused with the
'Validity' element that provides a mechanism to restrict the
lifetime of a rule.
反復時間(例えば毎午前9時から午後4時までの日)は正確に言えば、そんなに太平洋標準時の異なった時間帯、WR、PS、およびRMへの支払われるべきものが占領するかもしれない仕事をするのは難しいです。 非仕事/仕事が残念ながら、時間までに単独でキャプチャするのが難しい区別であるとサポートするのに時間間隔を含むための提案がしばしば基づいているように見えます。 この特徴が規則の生涯を制限するためにメカニズムを提供する'正当性'要素に混乱してはいけないことに注意してください。
6. Basic Data Model and Processing
6. 基礎データモデルと処理
A rule set (or synonymously, a policy) consists of zero or more rules. The ordering of these rules is irrelevant. The rule set can be stored at the PS and conveyed from RM to PS as a single document, in subsets or as individual rules. A rule consists of three parts: conditions (see Section 7), actions (see Section 8), and transformations (see Section 9).
または、規則がセットした、(同じ意味で、方針) ゼロか、より多くの規則から成ります。 これらの規則の注文は無関係です。 ただ一つのドキュメントとして、または、部分集合か独特の規則として規則セットをPSに保存して、RMからPSまで運ぶことができます。 規則は3つの部品から成ります: 条件(セクション7を見る)、動作(セクション8を見る)、および変換(セクション9を見ます)。
The conditions part is a set of expressions, each of which evaluates to either TRUE or FALSE. When a WR asks for information about a PT, the PS goes through each rule in the rule set. For each rule, it evaluates the expressions in the conditions part. If all of the expressions evaluate to TRUE, then the rule is applicable to this request. Generally, each expression specifies a condition based on some variable that is associated with the context of the request. These variables can include the identity of the WR, the domain of the WR, the time of day, or even external variables, such as the temperature or the mood of the PT.
状態部分は1セットの式です。それのそれぞれがTRUEかFALSEをどちらかに評価します。 WRが太平洋標準時の1時頃に照会するとき、PSは規則セットにおける各規則に直面しています。 各規則のために、それは状態部分で式を評価します。 式のすべてがTRUE、規則が適切であるその時まで評価する、この要求。 一般に、各式は要求の文脈に関連している何らかの変数に基づく状態を指定します。 これらの変数はWRのアイデンティティ、WR、時刻のドメイン、または太平洋標準時の温度かムードなどの外部の変数さえ含むことができます。
Assuming that the rule is applicable to the request, the actions and transformations (commonly referred to as permissions) in the rule specify how the PS is supposed to handle this request. If the request is to view the location of the PT, or to view its presence, the typical action is "permit", which allows the request to proceed.
規則による規則が要求に適切であると仮定する、動作、および変換(一般的に許容と呼ばれる)はPSがどうこの要求を扱うべきであるかを指定します。 要求が太平洋標準時の位置を見るか、または存在を見ることであるなら、典型的な動きは続くという要求を許す「許可証」です。
Assuming the action allows the request to proceed, the transformations part of the rule specifies how the information about the PT -- their location information, their presence, etc. -- is modified before being presented to the WR. These transformations are in the form of positive permissions. That is, they always specify a piece of information that is allowed to be seen by the WR. When a PS processes a request, it takes the transformations specified across all rules that match, and creates the union of them. For computing this union, the data type, such as Integer, Boolean, Set, or the Undef data type, plays a role. The details of the algorithm for combining permissions is described in Section 10. The resulting
動作が続くという要求を許すと仮定して、規則の変換部分がその方法を指定する、太平洋標準時頃の情報--それらの位置情報、それらの存在、など -- WRに提示される前に、変更されます。 これらの変換が積極的な許容の形にあります。 すなわち、彼らはいつもWRが見ることができる1つの情報を指定します。 PSが要求を処理するとき、それは、合っているすべての規則の向こう側に指定された変換を取って、それらの組合を創設します。 この組合を計算するために、Integerなどのようなブールのデータ型(Set、またはUndefデータ型)は、役割を果たします。 許容を結合するためのアルゴリズムの詳細はセクション10で説明されます。 結果になること
Schulzrinne, et al. Standards Track [Page 8] RFC 4745 Common Policy February 2007
Schulzrinne、他 方針2007年2月に一般的な標準化過程[8ページ]RFC4745
union effectively represents a "mask" -- it defines what information is exposed to the WR. This mask is applied to the actual location or presence data for the PT, and the data that is permitted by the mask is shown to the WR. If the WR requests a subset of information only (such as city-level civic location data only, instead of the full civic location information), the information delivered to the WR MUST be the intersection of the permissions granted to the WR and the data requested by the WR.
事実上、組合は「マスク」を表します--それは、どんな情報がWRに暴露されるかを定義します。 このマスクは太平洋標準時の間の実際の場所か存在データに付けられます、そして、マスクによって受入れられるデータはWRに示されます。 WRが部分集合を要求するなら、唯一であり(完全な都市の位置情報の代わりに都市レベルの都市の位置のデータだけなどの)、情報がWR MUSTに配送されたという情報では、WRに承諾された許容とWRによって要求されたデータの交差点になってください。
Rules are encoded in XML. To this end, Section 13 contains an XML schema defining the Common Policy Markup Language. This, however, is purely an exchange format between RM and PS. The format does not imply that the RM or the PS use this format internally, e.g., in matching a query with the policy rules. The rules are designed so that a PS can translate the rules into a relational database table, with each rule represented by one row in the database. The database representation is by no means mandatory; we will use it as a convenient and widely-understood example of an internal representation. The database model has the advantage that operations on rows have tightly defined meanings. In addition, it appears plausible that larger-scale implementations will employ a backend database to store and query rules, as they can then benefit from existing optimized indexing, access control, scaling, and integrity constraint mechanisms. Smaller-scale implementations may well choose different implementations, e.g., a simple traversal of the set of rules.
規則はXMLでコード化されます。 このために、セクション13はCommon Policy Markup Languageを定義するXML図式を含みます。 しかしながら、これは純粋にRMとPSの間の交換形式です。形式は、RMかPSが内部的にこの形式を使用するのを含意しません、例えば、政策ルールに質問に合う際に。 規則はPSが関係型データベーステーブルに規則を翻訳できるように、設計されています、各規則がデータベースの1つの行によって表されている状態で。 データベース表現は決して義務的ではありません。 私たちは内部の表現の便利で広く理解されている例としてそれを使用するつもりです。 データベースモデルには、利点があります。行における操作はしっかり意味を定義しました。 さらに、より大きいスケール実装が規則を保存して、質問するのにバックエンドデータベースを使うようにもっともらしく見えます、次に、既存の最適化されたインデックス、アクセスコントロール、スケーリング、および保全規制メカニズムの利益を得ることができるとき。よりわずかなスケール実装はたぶん異なった実装を選ぶでしょう、例えば、規則のセットの簡単な縦断。
6.1. Identification of Rules
6.1. 規則の識別
Each rule is equipped with a parameter that identifies the rule. This rule identifier is an opaque token chosen by the RM. A RM MUST NOT use the same identifier for two rules that are available to the PS at the same time for a given PT. If more than one RM modifies the same rule set, then it needs to be ensured that a unique identifier is chosen for each rule. A RM can accomplish this goal by retrieving the already specified rule set and choosing a new identifier for a rule that is different from the existing rule set.
各規則は規則を特定するパラメタを備えています。 この規則識別子はRMによって選ばれた不透明なトークンです。 A RM MUST NOTはaに、PTを考えて、同時にPSに利用可能な2つの規則に同じ識別子を使用します。 1RMが各規則に選ばれた状態でユニークな識別子がそれが確実にされるために必要とするその時ですが、設定された同じ規則を変更するなら。 RMは、既存の規則セットと異なった規則に既に指定された規則セットを検索して、新しい識別子を選ぶことによって、この目標を達成できます。
6.2. Extensions
6.2. 拡大
The policy framework defined in this document is meant to be extensible towards specific application domains. Such an extension is accomplished by defining conditions, actions, and transformations that are specific to the desired application domain. Each extension MUST define its own namespace.
本書では定義された方針フレームワークが特定のアプリケーションドメインに向かって広げることができることが意味されます。 そのような拡大は、必要なアプリケーションドメインに特定の状態、動作、および変換を定義することによって、実行されます。 各拡大はそれ自身の名前空間を定義しなければなりません。
Schulzrinne, et al. Standards Track [Page 9] RFC 4745 Common Policy February 2007
Schulzrinne、他 方針2007年2月に一般的な標準化過程[9ページ]RFC4745
Extensions cannot change the schema defined in this document, and this schema is not expected to change except via revision to this specification. Therefore, no versioning procedures for this schema or namespace are provided.
拡張子は本書では定義された図式を変えることができません、そして、この仕様への改正以外に、この図式が変化しないと予想されます。 したがって、この図式か名前空間のためのversioningしていない手順を提供します。
7. Conditions
7. 状態
The access to data items needs to be matched with the rule set stored at the PS. Each instance of a request has different attributes (e.g., the identity of the requestor) that are used for authorization. A rule in a rule set might have a number of conditions that need to be met before executing the remaining parts of a rule (i.e., actions and transformations). Details about rule matching are described in Section 10. This document specifies only a few conditions (i.e., identity, sphere, and validity). Further condition elements can be added via extensions to this document. If a child element of the <conditions> element is in a namespace that is not known or not supported, then this child element evaluates to FALSE.
データ項目へのアクセスは、PSに保存される規則セットに匹敵される必要があります。要求の各インスタンスには、承認に使用される異なった属性(例えば、要請者のアイデンティティ)があります。 規則セットにおける規則には、規則(すなわち、動作と変換)の残存部分を実行する前に会われる必要がある多くの状態があるかもしれません。 規則マッチングに関する詳細はセクション10で説明されます。 このドキュメントはほんのいくつかの条件(すなわち、アイデンティティ、球、および正当性)を指定します。 このドキュメントへの拡大でさらなる状態要素を加えることができます。 名前空間に<状態>要素の子供要素があるなら、それは、知られないか、またはサポートされません、この子供要素がFALSEに評価するその時。
As noted in Section 5, conditions are matched on equality or "greater than" style comparisons, rather than regular expressions. Equality is determined according to the rules for the data type associated with the element in the schema given in Section 13, unless explicit comparison steps are included in this document. For xs:anyURI types, readers may wish to consult [2] for its discussion xs:anyURI, as well as the text in Section 13.
または、状態がセクション5に述べられるように平等で合わせられている、「」 正規表現よりむしろスタイル比較よりすばらしいです。 セクション13で与えられた図式で要素に関連しているデータ型のための規則に従って、平等は決定しています、明白な比較ステップが本書では含まれていない場合。 xsのために: anyURIタイプ、読者は議論xsのための[2]に相談したがっているかもしれません: anyURI、およびセクション13のテキスト。
7.1. Identity Condition
7.1. 同一性条件
7.1.1. Overview
7.1.1. 概要
The identity condition restricts matching of a rule either to a single entity or a group of entities. Only authenticated entities can be matched; acceptable means of authentication are defined in protocol-specific documents. If the <identity> element is absent, identities are not considered, and thus, other conditions in the rule apply to any user, authenticated or not.
同一性条件は規則のマッチングを単一体か実体のグループに制限します。 認証された実体しか合わせることができません。 認証の許容できる手段はプロトコル特有のドキュメントで定義されます。 <アイデンティティ>要素が欠けるなら、アイデンティティは考えられません、そして、その結果、規則による他の状態は認証されたどんなユーザにも適用されます。
The <identity> condition is considered TRUE if any of its child elements (e.g., the <one/> and the <many/> elements defined in this document) evaluate to TRUE, i.e., the results of the individual child element are combined using a logical OR.
<アイデンティティ>状態はもしあれば要素(例えば、<1/>と多くの/>要素が本書では定義した<)がTRUEに評価する子供のTRUEであると考えられます、すなわち、個々の子供要素の結果は、論理的なORを使用することで結合されています。
If a child element of the <identity> element is in a namespace that is not known or not supported, then this child element evaluates to FALSE.
名前空間に<アイデンティティ>要素の子供要素があるなら、それは、知られないか、またはサポートされません、この子供要素がFALSEに評価するその時。
Schulzrinne, et al. Standards Track [Page 10] RFC 4745 Common Policy February 2007
Schulzrinne、他 方針2007年2月に一般的な標準化過程[10ページ]RFC4745
7.1.2. Matching One Entity
7.1.2. マッチング1実体
The <one> element matches the authenticated identity (as contained in the 'id' attribute) of exactly one entity or user. For considerations regarding the 'id' attribute, refer to Section 7.2.
The <one> element matches the authenticated identity (as contained in the 'id' attribute) of exactly one entity or user. For considerations regarding the 'id' attribute, refer to Section 7.2.
An example is shown below:
An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:alice@example.com"/>
<one id="tel:+1-212-555-1234" />
<one id="mailto:bob@example.net" />
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="f3g44r1"> <conditions> <identity> <one id="sip:alice@example.com"/> <one id="tel:+1-212-555-1234" /> <one id="mailto:bob@example.net" /> </identity> </conditions> <actions/> <transformations/> </rule>
</ruleset>
</ruleset>
This example matches if the authenticated identity of the WR is either sip:alice@example.com, tel:+1-212-555-1234, or mailto:bob@example.net.
This example matches if the authenticated identity of the WR is either sip:alice@example.com, tel:+1-212-555-1234, or mailto:bob@example.net.
7.1.3. Matching Multiple Entities
7.1.3. Matching Multiple Entities
The <many> element is a mechanism to perform authorization decisions based on the domain part of the authenticated identity. As such, it allows matching a large and possibly unknown number of users within a domain.
The <many> element is a mechanism to perform authorization decisions based on the domain part of the authenticated identity. As such, it allows matching a large and possibly unknown number of users within a domain.
Furthermore, it is possible to include one or multiple <except> elements to exclude either individual users or users belonging to a specific domain. Excluding individual entities is implemented using a <except id="..."/> statement. The semantic of the 'id' attribute of the <except> element has the same meaning as the 'id' attribute of the <one> element (see Section 7.2). Excluding users belonging to a specific domain is implemented using the <except domain="..."/> element that excludes any user from the indicated domain.
Furthermore, it is possible to include one or multiple <except> elements to exclude either individual users or users belonging to a specific domain. Excluding individual entities is implemented using a <except id="..."/> statement. The semantic of the 'id' attribute of the <except> element has the same meaning as the 'id' attribute of the <one> element (see Section 7.2). Excluding users belonging to a specific domain is implemented using the <except domain="..."/> element that excludes any user from the indicated domain.
If multiple <except> elements are listed as child elements of the <many> element, then the result of each <except> element is combined using a logical OR.
If multiple <except> elements are listed as child elements of the <many> element, then the result of each <except> element is combined using a logical OR.
Schulzrinne, et al. Standards Track [Page 11] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 11] RFC 4745 Common Policy February 2007
Common policy MUST either use UTF-8 or UTF-16 to store domain names in the 'domain' attribute. For non-IDNs (Internationalized Domain Names), lowercase ASCII SHOULD be used. For the comparison operation between the value stored in the 'domain' attribute and the domain value provided via the using protocol (referred to as "protocol domain identifier"), the following rules are applicable:
Common policy MUST either use UTF-8 or UTF-16 to store domain names in the 'domain' attribute. For non-IDNs (Internationalized Domain Names), lowercase ASCII SHOULD be used. For the comparison operation between the value stored in the 'domain' attribute and the domain value provided via the using protocol (referred to as "protocol domain identifier"), the following rules are applicable:
1. Translate percent-encoding for either string.
1. Translate percent-encoding for either string.
2. Convert both domain strings using the ToASCII operation described
in RFC 3490 [3].
2. Convert both domain strings using the ToASCII operation described in RFC 3490 [3].
3. Compare the two domain strings for ASCII equality, for each
label. If the string comparison for each label indicates
equality, the comparison succeeds. Otherwise, the domains are
not equal.
3. Compare the two domain strings for ASCII equality, for each label. If the string comparison for each label indicates equality, the comparison succeeds. Otherwise, the domains are not equal.
If the conversion fails in step (2), the domains are not equal.
If the conversion fails in step (2), the domains are not equal.
7.1.3.1. Matching Any Authenticated Identity
7.1.3.1. Matching Any Authenticated Identity
The <many/> element without any child elements or attributes matches any authenticated user.
The <many/> element without any child elements or attributes matches any authenticated user.
The following example shows such a rule that matches any authenticated user:
The following example shows such a rule that matches any authenticated user:
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r5">
<conditions>
<identity>
<many/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="f3g44r5"> <conditions> <identity> <many/> </identity> </conditions> <actions/> <transformations/> </rule>
</ruleset>
</ruleset>
Schulzrinne, et al. Standards Track [Page 12] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 12] RFC 4745 Common Policy February 2007
7.1.3.2. Matching Any Authenticated Identity Except Enumerated
Domains/Identities
7.1.3.2. Matching Any Authenticated Identity Except Enumerated Domains/Identities
The <many> element enclosing one or more <except domain="..."/> elements matches any user from any domain except those enumerated. The <except id="..."/> element excludes particular users. The semantics of the 'id' attribute of the <except> element is described in Section 7.2. The results of the child elements of the <many> element are combined using a logical OR.
The <many> element enclosing one or more <except domain="..."/> elements matches any user from any domain except those enumerated. The <except id="..."/> element excludes particular users. The semantics of the 'id' attribute of the <except> element is described in Section 7.2. The results of the child elements of the <many> element are combined using a logical OR.
An example is shown below:
An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<sphere value="work"/>
<identity>
<many>
<except domain="example.com"/>
<except domain="example.org"/>
<except id="sip:alice@bad.example.net"/>
<except id="sip:bob@good.example.net"/>
<except id="tel:+1-212-555-1234" />
<except id="sip:alice@example.com"/>
</many>
</identity>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="f3g44r1"> <conditions> <sphere value="work"/> <identity> <many> <except domain="example.com"/> <except domain="example.org"/> <except id="sip:alice@bad.example.net"/> <except id="sip:bob@good.example.net"/> <except id="tel:+1-212-555-1234" /> <except id="sip:alice@example.com"/> </many> </identity> <validity> <from>2003-12-24T17:00:00+01:00</from> <until>2003-12-24T19:00:00+01:00</until> </validity> </conditions> <actions/> <transformations/> </rule>
</ruleset>
</ruleset>
This example matches all users except any user in example.com, or any user in example.org or the particular users alice@bad.example.net, bob@good.example.net, and the user with the telephone number 'tel:+1-212-555-1234'. The last 'except' element is redundant since alice@example.com is already excluded through the first line.
This example matches all users except any user in example.com, or any user in example.org or the particular users alice@bad.example.net, bob@good.example.net, and the user with the telephone number 'tel:+1-212-555-1234'. The last 'except' element is redundant since alice@example.com is already excluded through the first line.
Schulzrinne, et al. Standards Track [Page 13] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 13] RFC 4745 Common Policy February 2007
7.1.3.3. Matching Any Authenticated Identity within a Domain Except
Enumerated Identities
7.1.3.3. Matching Any Authenticated Identity within a Domain Except Enumerated Identities
The <many> element with a 'domain' attribute and zero or more <except id="..."/> elements matches any authenticated user from the indicated domain except those explicitly enumerated. The semantics of the 'id' attribute of the <except> element is described in Section 7.2.
The <many> element with a 'domain' attribute and zero or more <except id="..."/> elements matches any authenticated user from the indicated domain except those explicitly enumerated. The semantics of the 'id' attribute of the <except> element is described in Section 7.2.
It is nonsensical to have domains in the 'id' attribute that do not match the value of the 'domain' attribute in the enclosing <many> element.
It is nonsensical to have domains in the 'id' attribute that do not match the value of the 'domain' attribute in the enclosing <many> element.
An example is shown below:
An example is shown below:
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<many domain="example.com">
<except id="sip:alice@example.com"/>
<except id="sip:bob@example.com"/>
</many>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="f3g44r1"> <conditions> <identity> <many domain="example.com"> <except id="sip:alice@example.com"/> <except id="sip:bob@example.com"/> </many> </identity> </conditions> <actions/> <transformations/> </rule>
</ruleset>
</ruleset>
This example matches any user within example.com (such as carol@example.com) except alice@example.com and bob@example.com.
This example matches any user within example.com (such as carol@example.com) except alice@example.com and bob@example.com.
7.2. Single Entity
7.2. Single Entity
The 'id' attribute used in the <one> and in the <except> element refers to a single entity. In the subsequent text, we use the term 'single-user entity' as a placeholder for the <one> and the <except> element. The <except> element fulfills the purpose of excluding elements from the solution set.
The 'id' attribute used in the <one> and in the <except> element refers to a single entity. In the subsequent text, we use the term 'single-user entity' as a placeholder for the <one> and the <except> element. The <except> element fulfills the purpose of excluding elements from the solution set.
A single-user entity matches the authenticated identity (as contained in the 'id' attribute) of exactly one entity or user. If there is a match, the single-user entity is considered TRUE. The single-user entity MUST NOT contain a 'domain' attribute.
A single-user entity matches the authenticated identity (as contained in the 'id' attribute) of exactly one entity or user. If there is a match, the single-user entity is considered TRUE. The single-user entity MUST NOT contain a 'domain' attribute.
Schulzrinne, et al. Standards Track [Page 14] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 14] RFC 4745 Common Policy February 2007
The 'id' attribute contains an identity that MUST first be expressed as a URI. Applications using this framework must describe how the identities they are using can be expressed as URIs.
The 'id' attribute contains an identity that MUST first be expressed as a URI. Applications using this framework must describe how the identities they are using can be expressed as URIs.
7.3. Sphere
7.3. Sphere
The <sphere> element belongs to the group of condition elements. It can be used to indicate a state (e.g., 'work', 'home', 'meeting', 'travel') the PT is currently in. A sphere condition matches only if the PT is currently in the state indicated. The state may be conveyed by manual configuration or by some protocol. For example, RPID [10] provides the ability to inform the PS of its current sphere. The application domain needs to describe in more detail how the sphere state is determined. Switching from one sphere to another causes a switch between different modes of visibility. As a result, different subsets of rules might be applicable.
The <sphere> element belongs to the group of condition elements. It can be used to indicate a state (e.g., 'work', 'home', 'meeting', 'travel') the PT is currently in. A sphere condition matches only if the PT is currently in the state indicated. The state may be conveyed by manual configuration or by some protocol. For example, RPID [10] provides the ability to inform the PS of its current sphere. The application domain needs to describe in more detail how the sphere state is determined. Switching from one sphere to another causes a switch between different modes of visibility. As a result, different subsets of rules might be applicable.
The content of the 'value' attribute of the <sphere> element MAY contain more than one token. The individual tokens MUST be separated by a blank character. A logical OR is used for the matching the tokens against the sphere settings of the PT. As an example, if the content of the 'value' attribute in the sphere attribute contains two tokens 'work' and 'home' then this part of the rule matches if the sphere for a particular PT is either 'work' OR 'home'. To compare the content of the 'value' attribute in the <sphere> element with the stored state information about the PT's sphere setting a case-insensitive string comparison MUST be used for each individual token. There is neither a registry for these values nor a language- specific indication of the sphere content. As such, the tokens are treated as opaque strings.
The content of the 'value' attribute of the <sphere> element MAY contain more than one token. The individual tokens MUST be separated by a blank character. A logical OR is used for the matching the tokens against the sphere settings of the PT. As an example, if the content of the 'value' attribute in the sphere attribute contains two tokens 'work' and 'home' then this part of the rule matches if the sphere for a particular PT is either 'work' OR 'home'. To compare the content of the 'value' attribute in the <sphere> element with the stored state information about the PT's sphere setting a case-insensitive string comparison MUST be used for each individual token. There is neither a registry for these values nor a language- specific indication of the sphere content. As such, the tokens are treated as opaque strings.
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r2">
<conditions>
<sphere value="work"/>
<identity>
<one id="sip:andrew@example.com"/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="f3g44r2"> <conditions> <sphere value="work"/> <identity> <one id="sip:andrew@example.com"/> </identity> </conditions> <actions/> <transformations/> </rule>
Schulzrinne, et al. Standards Track [Page 15] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 15] RFC 4745 Common Policy February 2007
<rule id="y6y55r2">
<conditions>
<sphere value="home"/>
<identity>
<one id="sip:allison@example.com"/>
</identity>
</conditions>
<actions/>
<transformations/>
</rule>
<rule id="y6y55r2"> <conditions> <sphere value="home"/> <identity> <one id="sip:allison@example.com"/> </identity> </conditions> <actions/> <transformations/> </rule>
<rule id="z6y55r2">
<conditions>
<identity>
<one id="sip:john@doe.example.com"/>
</identity>
<sphere value="home work"/>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
<rule id="z6y55r2"> <conditions> <identity> <one id="sip:john@doe.example.com"/> </identity> <sphere value="home work"/> </conditions> <actions/> <transformations/> </rule> </ruleset>
The rule example above illustrates that the rule with the entity andrew@example.com matches if the sphere is been set to 'work'. In the second rule, the entity allison@example.com matches if the sphere is set to 'home'. The third rule also matches since the value in the sphere element also contains the token 'home'.
The rule example above illustrates that the rule with the entity andrew@example.com matches if the sphere is been set to 'work'. In the second rule, the entity allison@example.com matches if the sphere is set to 'home'. The third rule also matches since the value in the sphere element also contains the token 'home'.
7.4. Validity
7.4. Validity
The <validity> element is the third condition element specified in this document. It expresses the rule validity period by two attributes, a starting and an ending time. The validity condition is TRUE if the current time is greater than or equal to at least one <from> child, but less than the <until> child after it. This represents a logical OR operation across each <from> and <until> pair. Times are expressed in XML dateTime format. A rule maker might not always have access to the PS to invalidate some rules that grant permissions. Hence, this mechanism allows invalidating granted permissions automatically without further interaction between the rule maker and the PS. The PS does not remove the rules; instead the rule maker has to clean them up.
The <validity> element is the third condition element specified in this document. It expresses the rule validity period by two attributes, a starting and an ending time. The validity condition is TRUE if the current time is greater than or equal to at least one <from> child, but less than the <until> child after it. This represents a logical OR operation across each <from> and <until> pair. Times are expressed in XML dateTime format. A rule maker might not always have access to the PS to invalidate some rules that grant permissions. Hence, this mechanism allows invalidating granted permissions automatically without further interaction between the rule maker and the PS. The PS does not remove the rules; instead the rule maker has to clean them up.
Schulzrinne, et al. Standards Track [Page 16] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 16] RFC 4745 Common Policy February 2007
An example of a rule fragment is shown below:
An example of a rule fragment is shown below:
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r3">
<conditions>
<validity>
<from>2003-08-15T10:20:00.000-05:00</from>
<until>2003-09-15T10:20:00.000-05:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
<rule id="f3g44r3"> <conditions> <validity> <from>2003-08-15T10:20:00.000-05:00</from> <until>2003-09-15T10:20:00.000-05:00</until> </validity> </conditions> <actions/> <transformations/> </rule> </ruleset>
The <validity> element MUST have the <from> and <until> subelements in pairs. Multiple <from> and <until> elements might appear in pairs (i.e., without nesting of <from> and <until> elements). Using multiple <validity> elements as subelements of the <conditions> element is not useful since all subelements of the <conditions> element are combined as a logical AND.
The <validity> element MUST have the <from> and <until> subelements in pairs. Multiple <from> and <until> elements might appear in pairs (i.e., without nesting of <from> and <until> elements). Using multiple <validity> elements as subelements of the <conditions> element is not useful since all subelements of the <conditions> element are combined as a logical AND.
8. Actions
8. Actions
While conditions are the 'if'-part of rules, actions and transformations form their 'then'-part. The actions and transformations parts of a rule determine which operations the PS MUST execute after having received from a WR a data access request that matches all conditions of this rule. Actions and transformations only permit certain operations; there is no 'deny' functionality. Transformations exclusively specify PS-side operations that lead to a modification of the data items requested by the WR. Regarding location data items, for instance, a transformation could force the PS to lower the precision of the location information that is returned to the WR.
While conditions are the 'if'-part of rules, actions and transformations form their 'then'-part. The actions and transformations parts of a rule determine which operations the PS MUST execute after having received from a WR a data access request that matches all conditions of this rule. Actions and transformations only permit certain operations; there is no 'deny' functionality. Transformations exclusively specify PS-side operations that lead to a modification of the data items requested by the WR. Regarding location data items, for instance, a transformation could force the PS to lower the precision of the location information that is returned to the WR.
Actions, on the other hand, specify all remaining types of operations the PS is obliged to execute, i.e., all operations that are not of transformation type. Actions are defined by application-specific usages of this framework. The reader is referred to the corresponding extensions to see examples of such elements.
Actions, on the other hand, specify all remaining types of operations the PS is obliged to execute, i.e., all operations that are not of transformation type. Actions are defined by application-specific usages of this framework. The reader is referred to the corresponding extensions to see examples of such elements.
Schulzrinne, et al. Standards Track [Page 17] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 17] RFC 4745 Common Policy February 2007
9. Transformations
9. Transformations
Two sub-parts follow the conditions part of a rule: transformations and actions. As defined in Section 8, transformations specify operations that the PS MUST execute and that modify the result that is returned to the WR. This functionality is particularly helpful in reducing the granularity of information provided to the WR, as, for example, required for location privacy. Transformations are defined by application-specific usages of this framework.
Two sub-parts follow the conditions part of a rule: transformations and actions. As defined in Section 8, transformations specify operations that the PS MUST execute and that modify the result that is returned to the WR. This functionality is particularly helpful in reducing the granularity of information provided to the WR, as, for example, required for location privacy. Transformations are defined by application-specific usages of this framework.
A simple transformation example is provided in Section 10.
A simple transformation example is provided in Section 10.
10. Procedure for Combining Permissions
10. Procedure for Combining Permissions
10.1. Introduction
10.1. Introduction
This section describes how rules are selected and how actions and permissions are determined. When a PS receives a request for access to privacy-sensitive data, the request is matched against the rule set. A rule matches if all conditions contained as child elements in the <conditions> element of a rule evaluate to TRUE. Each type of condition defines when it is TRUE. All rules where the conditions match the request form the matching rule set. The permissions in the matching rule set are combined using a set of combining rules (CRs) described in Section 10.2.
This section describes how rules are selected and how actions and permissions are determined. When a PS receives a request for access to privacy-sensitive data, the request is matched against the rule set. A rule matches if all conditions contained as child elements in the <conditions> element of a rule evaluate to TRUE. Each type of condition defines when it is TRUE. All rules where the conditions match the request form the matching rule set. The permissions in the matching rule set are combined using a set of combining rules (CRs) described in Section 10.2.
10.2. Combining Rules (CRs)
10.2. Combining Rules (CRs)
Each type of permission is combined across all matching rules. Each type of action or transformation is combined separately and independently. The combining rules generate a combined permission. The combining rules depend only on the data type of permission. If a particular permission type has no value in a rule, it assumes the lowest possible value for that permission for the purpose of computing the combined permission. That value is given by the data type for booleans (FALSE) and sets (empty set), and MUST be defined by any extension to the Common Policy for other data types.
Each type of permission is combined across all matching rules. Each type of action or transformation is combined separately and independently. The combining rules generate a combined permission. The combining rules depend only on the data type of permission. If a particular permission type has no value in a rule, it assumes the lowest possible value for that permission for the purpose of computing the combined permission. That value is given by the data type for booleans (FALSE) and sets (empty set), and MUST be defined by any extension to the Common Policy for other data types.
For boolean permissions, the resulting permission is TRUE if and only if at least one permission in the matching rule set has a value of TRUE and FALSE otherwise. For integer, real-valued and date-time permissions, the resulting permission is the maximum value across the permission values in the matching set of rules. For sets, it is the union of values across the permissions in the matching rule set.
For boolean permissions, the resulting permission is TRUE if and only if at least one permission in the matching rule set has a value of TRUE and FALSE otherwise. For integer, real-valued and date-time permissions, the resulting permission is the maximum value across the permission values in the matching set of rules. For sets, it is the union of values across the permissions in the matching rule set.
Schulzrinne, et al. Standards Track [Page 18] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 18] RFC 4745 Common Policy February 2007
10.3. Example
10.3. Example
In the following example we illustrate the process of combining permissions. We will consider three conditions for our purpose, namely those of name identity (WR-ID), sphere, and validity (from,until). The ID column is used as a rule identifier. For editorial reasons we omit the domain part of the WR's identity.
In the following example we illustrate the process of combining permissions. We will consider three conditions for our purpose, namely those of name identity (WR-ID), sphere, and validity (from,until). The ID column is used as a rule identifier. For editorial reasons we omit the domain part of the WR's identity.
We use two actions in our example, namely X and Y. The values of X and Y are of data types Boolean and Integer, respectively.
We use two actions in our example, namely X and Y. The values of X and Y are of data types Boolean and Integer, respectively.
The transformation, referred to as Z, uses values that can be set either to '+' (or 3), 'o' (or 2) or '-' (or 1). Permission Z allows us to show the granularity reduction whereby a value of '+' shows the corresponding information unrestricted, and '-' shows nothing. This permission might be related to location information or other presence attributes like mood. Internally, we use the data type Integer for computing the permission of this attribute.
The transformation, referred to as Z, uses values that can be set either to '+' (or 3), 'o' (or 2) or '-' (or 1). Permission Z allows us to show the granularity reduction whereby a value of '+' shows the corresponding information unrestricted, and '-' shows nothing. This permission might be related to location information or other presence attributes like mood. Internally, we use the data type Integer for computing the permission of this attribute.
The label 'NULL' in the table indicates that no value is available for a particular cell.
The label 'NULL' in the table indicates that no value is available for a particular cell.
Conditions Actions/Transformations
+---------------------------------+---------------------+
| Id WR-ID sphere from until | X Y Z |
+---------------------------------+---------------------+
| 1 bob home A1 A2 | TRUE 10 o |
| 2 alice work A1 A2 | FALSE 5 + |
| 3 bob work A1 A2 | TRUE 3 - |
| 4 tom work A1 A2 | TRUE 5 + |
| 5 bob work A1 A3 | NULL 12 o |
| 6 bob work B1 B2 | FALSE 10 - |
+---------------------------------+---------------------+
Conditions Actions/Transformations +---------------------------------+---------------------+ | Id WR-ID sphere from until | X Y Z | +---------------------------------+---------------------+ | 1 bob home A1 A2 | TRUE 10 o | | 2 alice work A1 A2 | FALSE 5 + | | 3 bob work A1 A2 | TRUE 3 - | | 4 tom work A1 A2 | TRUE 5 + | | 5 bob work A1 A3 | NULL 12 o | | 6 bob work B1 B2 | FALSE 10 - | +---------------------------------+---------------------+
Again for editorial reasons, we use the following abbreviations for the two <validity> attributes 'from' and 'until':
Again for editorial reasons, we use the following abbreviations for the two <validity> attributes 'from' and 'until':
A1=2003-12-24T17:00:00+01:00
A2=2003-12-24T21:00:00+01:00
A3=2003-12-24T23:30:00+01:00
B1=2003-12-22T17:00:00+01:00
B2=2003-12-23T17:00:00+01:00
A1=2003-12-24T17:00:00+01:00 A2=2003-12-24T21:00:00+01:00 A3=2003-12-24T23:30:00+01:00 B1=2003-12-22T17:00:00+01:00 B2=2003-12-23T17:00:00+01:00
Note that B1 < B2 < A1 < A2 < A3.
Note that B1 < B2 < A1 < A2 < A3.
The entity 'bob' acts as a WR and requests data items. The rule set consists of the six rules shown in the table and identified by the values 1 to 6 in the 'Id' column. The PS receives the query at
The entity 'bob' acts as a WR and requests data items. The rule set consists of the six rules shown in the table and identified by the values 1 to 6 in the 'Id' column. The PS receives the query at
Schulzrinne, et al. Standards Track [Page 19] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 19] RFC 4745 Common Policy February 2007
2003-12-24T17:15:00+01:00, which falls between A1 and A2. In our example, we assume that the sphere value of the PT is currently set to 'work'.
2003-12-24T17:15:00+01:00, which falls between A1 and A2. In our example, we assume that the sphere value of the PT is currently set to 'work'.
As a first step, it is necessary to determine which rules fire by evaluating the conditions part of each of them.
As a first step, it is necessary to determine which rules fire by evaluating the conditions part of each of them.
Rule 1 does not match since the sphere condition does not match. Rule 2 does not match as the identity of the WR (here 'alice') does not equal 'bob'. Rule 3 matches since all conditions evaluate to TRUE. Rule 4 does not match as the identity of the WR (here 'tom') does not equal 'bob'. Rule 5 matches. Rule 6 does not match since the rule is not valid anymore.
Rule 1 does not match since the sphere condition does not match. Rule 2 does not match as the identity of the WR (here 'alice') does not equal 'bob'. Rule 3 matches since all conditions evaluate to TRUE. Rule 4 does not match as the identity of the WR (here 'tom') does not equal 'bob'. Rule 5 matches. Rule 6 does not match since the rule is not valid anymore.
Only rules 3 and 5 fire. We use the actions and transformations part of these two rules to determine the combined permission, as shown below.
Only rules 3 and 5 fire. We use the actions and transformations part of these two rules to determine the combined permission, as shown below.
Actions/Transformations
+-----+-----------------------+
| Id | X Y Z |
+-----+-----------------------+
| 3 | TRUE 3 - |
| 5 | NULL 12 o |
+-----+-----------------------+
Actions/Transformations +-----+-----------------------+ | Id | X Y Z | +-----+-----------------------+ | 3 | TRUE 3 - | | 5 | NULL 12 o | +-----+-----------------------+
Each column is treated independently. The combined value of X is set to TRUE since the NULL value equals FALSE according to the description in Section 10.2. For the column with the name Y, we apply the maximum of 3 and 12, so that the combined value of Y is 12. For column Z, we again compute the maximum of 'o' and '-' (i.e., 2 and 1) which is 'o' (2).
Each column is treated independently. The combined value of X is set to TRUE since the NULL value equals FALSE according to the description in Section 10.2. For the column with the name Y, we apply the maximum of 3 and 12, so that the combined value of Y is 12. For column Z, we again compute the maximum of 'o' and '-' (i.e., 2 and 1) which is 'o' (2).
The combined permission for all three columns is therefore:
The combined permission for all three columns is therefore:
Actions/Transformations
+-----------------------+
| X Y Z |
+-----------------------+
| TRUE 12 o |
+-----------------------+
Actions/Transformations +-----------------------+ | X Y Z | +-----------------------+ | TRUE 12 o | +-----------------------+
Schulzrinne, et al. Standards Track [Page 20] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 20] RFC 4745 Common Policy February 2007
11. Meta Policies
11. Meta Policies
Meta policies authorize a rule maker to insert, update, or delete a particular rule or an entire rule set. Some authorization policies are required to prevent unauthorized modification of rule sets. Meta policies are outside the scope of this document.
Meta policies authorize a rule maker to insert, update, or delete a particular rule or an entire rule set. Some authorization policies are required to prevent unauthorized modification of rule sets. Meta policies are outside the scope of this document.
A simple implementation could restrict access to the rule set only to the PT but more sophisticated mechanisms could be useful. As an example of such policies, one could think of parents configuring the policies for their children.
A simple implementation could restrict access to the rule set only to the PT but more sophisticated mechanisms could be useful. As an example of such policies, one could think of parents configuring the policies for their children.
12. Example
12. Example
This section gives an example of an XML document valid with respect to the XML schema defined in Section 13. Semantically richer examples can be found in documents that extend this schema with application-domain-specific data (e.g., location or presence information).
This section gives an example of an XML document valid with respect to the XML schema defined in Section 13. Semantically richer examples can be found in documents that extend this schema with application-domain-specific data (e.g., location or presence information).
Below a rule is shown with a condition that matches for a given authenticated identity (bob@example.com) and within a given time period. Additionally, the rule matches only if the target has set its sphere to 'work'.
Below a rule is shown with a condition that matches for a given authenticated identity (bob@example.com) and within a given time period. Additionally, the rule matches only if the target has set its sphere to 'work'.
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<?xml version="1.0" encoding="UTF-8"?> <ruleset xmlns="urn:ietf:params:xml:ns:common-policy">
<rule id="f3g44r1">
<conditions>
<identity>
<one id="sip:bob@example.com"/>
</identity>
<sphere value="work"/>
<validity>
<from>2003-12-24T17:00:00+01:00</from>
<until>2003-12-24T19:00:00+01:00</until>
</validity>
</conditions>
<actions/>
<transformations/>
</rule>
</ruleset>
<rule id="f3g44r1"> <conditions> <identity> <one id="sip:bob@example.com"/> </identity> <sphere value="work"/> <validity> <from>2003-12-24T17:00:00+01:00</from> <until>2003-12-24T19:00:00+01:00</until> </validity> </conditions> <actions/> <transformations/> </rule> </ruleset>
Schulzrinne, et al. Standards Track [Page 21] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 21] RFC 4745 Common Policy February 2007
13. XML Schema Definition
13. XML Schema Definition
This section provides the XML schema definition for the common policy markup language described in this document.
This section provides the XML schema definition for the common policy markup language described in this document.
<?xml version="1.0" encoding="UTF-8"?>
<xs:schema targetNamespace="urn:ietf:params:xml:ns:common-policy"
xmlns:cp="urn:ietf:params:xml:ns:common-policy"
xmlns:xs="http://www.w3.org/2001/XMLSchema"
elementFormDefault="qualified" attributeFormDefault="unqualified">
<!-- /ruleset -->
<xs:element name="ruleset">
<xs:complexType>
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="rule" type="cp:ruleType"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:element>
<!-- /ruleset/rule -->
<xs:complexType name="ruleType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:element name="conditions"
type="cp:conditionsType" minOccurs="0"/>
<xs:element name="actions"
type="cp:extensibleType" minOccurs="0"/>
<xs:element name="transformations"
type="cp:extensibleType" minOccurs="0"/>
</xs:sequence>
<xs:attribute name="id" type="xs:ID" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //rule/conditions -->
<xs:complexType name="conditionsType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice maxOccurs="unbounded">
<xs:element name="identity"
type="cp:identityType" minOccurs="0"/>
<xs:element name="sphere"
type="cp:sphereType" minOccurs="0"/>
<?xml version="1.0" encoding="UTF-8"?> <xs:schema targetNamespace="urn:ietf:params:xml:ns:common-policy" xmlns:cp="urn:ietf:params:xml:ns:common-policy" xmlns:xs="http://www.w3.org/2001/XMLSchema" elementFormDefault="qualified" attributeFormDefault="unqualified"> <!-- /ruleset --> <xs:element name="ruleset"> <xs:complexType> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:element name="rule" type="cp:ruleType" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:element> <!-- /ruleset/rule --> <xs:complexType name="ruleType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:element name="conditions" type="cp:conditionsType" minOccurs="0"/> <xs:element name="actions" type="cp:extensibleType" minOccurs="0"/> <xs:element name="transformations" type="cp:extensibleType" minOccurs="0"/> </xs:sequence> <xs:attribute name="id" type="xs:ID" use="required"/> </xs:restriction> </xs:complexContent> </xs:complexType> <!-- //rule/conditions --> <xs:complexType name="conditionsType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:choice maxOccurs="unbounded"> <xs:element name="identity" type="cp:identityType" minOccurs="0"/> <xs:element name="sphere" type="cp:sphereType" minOccurs="0"/>
Schulzrinne, et al. Standards Track [Page 22] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 22] RFC 4745 Common Policy February 2007
<xs:element name="validity"
type="cp:validityType" minOccurs="0"/>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //conditions/identity -->
<xs:complexType name="identityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="1" maxOccurs="unbounded">
<xs:element name="one" type="cp:oneType"/>
<xs:element name="many" type="cp:manyType"/>
<xs:any namespace="##other" processContents="lax"/>
</xs:choice>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //identity/one -->
<xs:complexType name="oneType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other"
minOccurs="0" processContents="lax"/>
</xs:sequence>
<xs:attribute name="id"
type="xs:anyURI" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //identity/many -->
<xs:complexType name="manyType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:choice minOccurs="0" maxOccurs="unbounded">
<xs:element name="except" type="cp:exceptType"/>
<xs:any namespace="##other"
minOccurs="0" processContents="lax"/>
</xs:choice>
<xs:attribute name="domain"
use="optional" type="xs:string"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //many/except -->
<xs:element name="validity" type="cp:validityType" minOccurs="0"/> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:choice> </xs:restriction> </xs:complexContent> </xs:complexType> <!-- //conditions/identity --> <xs:complexType name="identityType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:choice minOccurs="1" maxOccurs="unbounded"> <xs:element name="one" type="cp:oneType"/> <xs:element name="many" type="cp:manyType"/> <xs:any namespace="##other" processContents="lax"/> </xs:choice> </xs:restriction> </xs:complexContent> </xs:complexType> <!-- //identity/one --> <xs:complexType name="oneType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any namespace="##other" minOccurs="0" processContents="lax"/> </xs:sequence> <xs:attribute name="id" type="xs:anyURI" use="required"/> </xs:restriction> </xs:complexContent> </xs:complexType> <!-- //identity/many --> <xs:complexType name="manyType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:choice minOccurs="0" maxOccurs="unbounded"> <xs:element name="except" type="cp:exceptType"/> <xs:any namespace="##other" minOccurs="0" processContents="lax"/> </xs:choice> <xs:attribute name="domain" use="optional" type="xs:string"/> </xs:restriction> </xs:complexContent> </xs:complexType> <!-- //many/except -->
Schulzrinne, et al. Standards Track [Page 23] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 23] RFC 4745 Common Policy February 2007
<xs:complexType name="exceptType">
<xs:attribute name="domain" type="xs:string" use="optional"/>
<xs:attribute name="id" type="xs:anyURI" use="optional"/>
</xs:complexType>
<!-- //conditions/sphere -->
<xs:complexType name="sphereType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:attribute name="value"
type="xs:string" use="required"/>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //conditions/validity -->
<xs:complexType name="validityType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence minOccurs="1" maxOccurs="unbounded">
<xs:element name="from" type="xs:dateTime"/>
<xs:element name="until" type="xs:dateTime"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
<!-- //rule/actions or //rule/transformations -->
<xs:complexType name="extensibleType">
<xs:complexContent>
<xs:restriction base="xs:anyType">
<xs:sequence>
<xs:any namespace="##other" processContents="lax"
minOccurs="0" maxOccurs="unbounded"/>
</xs:sequence>
</xs:restriction>
</xs:complexContent>
</xs:complexType>
</xs:schema>
<xs:complexType name="exceptType"> <xs:attribute name="domain" type="xs:string" use="optional"/> <xs:attribute name="id" type="xs:anyURI" use="optional"/> </xs:complexType> <!-- //conditions/sphere --> <xs:complexType name="sphereType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:attribute name="value" type="xs:string" use="required"/> </xs:restriction> </xs:complexContent> </xs:complexType> <!-- //conditions/validity --> <xs:complexType name="validityType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence minOccurs="1" maxOccurs="unbounded"> <xs:element name="from" type="xs:dateTime"/> <xs:element name="until" type="xs:dateTime"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> <!-- //rule/actions or //rule/transformations --> <xs:complexType name="extensibleType"> <xs:complexContent> <xs:restriction base="xs:anyType"> <xs:sequence> <xs:any namespace="##other" processContents="lax" minOccurs="0" maxOccurs="unbounded"/> </xs:sequence> </xs:restriction> </xs:complexContent> </xs:complexType> </xs:schema>
Schulzrinne, et al. Standards Track [Page 24] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 24] RFC 4745 Common Policy February 2007
14. Security Considerations
14. Security Considerations
This document describes a framework for policies. This framework is intended to be enhanced elsewhere by application-domain-specific data. Security considerations are to a great extent application-data dependent, and therefore need to be covered by documents that extend the framework defined in this specification. However, new action and transformation permissions along with their allowed values must be defined in a way so that the usage of the permissions combining rules of Section 10 does not lower the level of privacy protection. See Section 10 for more details on this privacy issue.
This document describes a framework for policies. This framework is intended to be enhanced elsewhere by application-domain-specific data. Security considerations are to a great extent application-data dependent, and therefore need to be covered by documents that extend the framework defined in this specification. However, new action and transformation permissions along with their allowed values must be defined in a way so that the usage of the permissions combining rules of Section 10 does not lower the level of privacy protection. See Section 10 for more details on this privacy issue.
15. IANA Considerations
15. IANA Considerations
This section registers a new XML namespace, a new XML schema, and a new MIME type. This section registers a new XML namespace per the procedures in [4].
This section registers a new XML namespace, a new XML schema, and a new MIME type. This section registers a new XML namespace per the procedures in [4].
15.1. Common Policy Namespace Registration
15.1. Common Policy Namespace Registration
URI: urn:ietf:params:xml:ns:common-policy
URI: urn:ietf:params:xml:ns:common-policy
Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne
(hgs+geopriv@cs.columbia.edu).
Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne (hgs+geopriv@cs.columbia.edu).
XML:
XML:
BEGIN
<?xml version="1.0"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN"
"http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">
<head>
<meta http-equiv="content-type"
content="text/html;charset=iso-8859-1"/>
<title>Common Policy Namespace</title>
</head>
<body>
<h1>Namespace for Common Authorization Policies</h1>
<h2>urn:ietf:params:xml:ns:common-policy</h2>
<p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4745.txt">
RFC 4745</a>.</p>
</body>
</html>
END
BEGIN <?xml version="1.0"?> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML Basic 1.0//EN" "http://www.w3.org/TR/xhtml-basic/xhtml-basic10.dtd"> <html xmlns="http://www.w3.org/1999/xhtml"> <head> <meta http-equiv="content-type" content="text/html;charset=iso-8859-1"/> <title>Common Policy Namespace</title> </head> <body> <h1>Namespace for Common Authorization Policies</h1> <h2>urn:ietf:params:xml:ns:common-policy</h2> <p>See <a href="ftp://ftp.rfc-editor.org/in-notes/rfc4745.txt"> RFC 4745</a>.</p> </body> </html> END
Schulzrinne, et al. Standards Track [Page 25] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 25] RFC 4745 Common Policy February 2007
15.2. Content-type Registration for 'application/auth-policy+xml'
15.2. Content-type Registration for 'application/auth-policy+xml'
This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [5] and guidelines in RFC 3023 [6].
This specification requests the registration of a new MIME type according to the procedures of RFC 4288 [5] and guidelines in RFC 3023 [6].
MIME media type name: application
MIME media type name: application
MIME subtype name: auth-policy+xml
MIME subtype name: auth-policy+xml
Mandatory parameters: none
Mandatory parameters: none
Optional parameters: charset
Optional parameters: charset
Indicates the character encoding of enclosed XML.
Indicates the character encoding of enclosed XML.
Encoding considerations:
Encoding considerations:
Uses XML, which can employ 8-bit characters, depending on the
character encoding used. See RFC 3023 [6], Section 3.2.
Uses XML, which can employ 8-bit characters, depending on the character encoding used. See RFC 3023 [6], Section 3.2.
Security considerations:
Security considerations:
This content type is designed to carry authorization policies.
Appropriate precautions should be adopted to limit disclosure of
this information. Please refer to Section 14 of RFC 4745 and to
the security considerations described in Section 10 of RFC 3023
[6] for more information.
This content type is designed to carry authorization policies. Appropriate precautions should be adopted to limit disclosure of this information. Please refer to Section 14 of RFC 4745 and to the security considerations described in Section 10 of RFC 3023 [6] for more information.
Interoperability considerations: None
Interoperability considerations: None
Published specification: RFC 4745
Published specification: RFC 4745
Applications which use this media type:
Applications which use this media type:
Presence- and location-based systems
Presence- and location-based systems
Additional information:
Additional information:
Magic Number: None
Magic Number: None
File Extension: .apxml
File Extension: .apxml
Macintosh file type code: 'TEXT'
Macintosh file type code: 'TEXT'
Personal and email address for further information:
Hannes Tschofenig, Hannes.Tschofenig@siemens.com
Personal and email address for further information: Hannes Tschofenig, Hannes.Tschofenig@siemens.com
Schulzrinne, et al. Standards Track [Page 26] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 26] RFC 4745 Common Policy February 2007
Intended usage: LIMITED USE
Intended usage: LIMITED USE
Author:
Author:
This specification is a work item of the IETF GEOPRIV working
group, with mailing list address <geopriv@ietf.org>.
This specification is a work item of the IETF GEOPRIV working group, with mailing list address <geopriv@ietf.org>.
Change controller:
Change controller:
The IESG <iesg@ietf.org>
The IESG <iesg@ietf.org>
15.3. Common Policy Schema Registration
15.3. Common Policy Schema Registration
URI: urn:ietf:params:xml:schema:common-policy
URI: urn:ietf:params:xml:schema:common-policy
Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne
(hgs+geopriv@cs.columbia.edu).
Registrant Contact: IETF GEOPRIV working group, Henning Schulzrinne (hgs+geopriv@cs.columbia.edu).
XML: The XML schema to be registered is contained in Section 13.
Its first line is
XML: The XML schema to be registered is contained in Section 13. Its first line is
<?xml version="1.0" encoding="UTF-8"?>
<?xml version="1.0" encoding="UTF-8"?>
and its last line is
and its last line is
</xs:schema>
</xs:schema>
16. References
16. References
16.1. Normative References
16.1. Normative References
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
[1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[2] Duerst, M. and M. Suignard, "Internationalized Resource
Identifiers (IRIs)", RFC 3987, January 2005.
[2] Duerst, M. and M. Suignard, "Internationalized Resource Identifiers (IRIs)", RFC 3987, January 2005.
[3] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing
Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[3] Faltstrom, P., Hoffman, P., and A. Costello, "Internationalizing Domain Names in Applications (IDNA)", RFC 3490, March 2003.
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
January 2004.
[4] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, January 2004.
[5] Freed, N. and J. Klensin, "Media Type Specifications and
Registration Procedures", BCP 13, RFC 4288, December 2005.
[5] Freed, N. and J. Klensin, "Media Type Specifications and Registration Procedures", BCP 13, RFC 4288, December 2005.
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types",
RFC 3023, January 2001.
[6] Murata, M., St. Laurent, S., and D. Kohn, "XML Media Types", RFC 3023, January 2001.
Schulzrinne, et al. Standards Track [Page 27] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 27] RFC 4745 Common Policy February 2007
16.2. Informative References
16.2. Informative References
[7] Rosenberg, J., "Presence Authorization Rules", Work in Progress,
June 2006.
[7] Rosenberg, J., "Presence Authorization Rules", Work in Progress, June 2006.
[8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J.
Polk, "A Document Format for Expressing Privacy Preferences for
Location Information", Work in Progress, February 2006.
[8] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., and J. Polk, "A Document Format for Expressing Privacy Preferences for Location Information", Work in Progress, February 2006.
[9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J.
Polk, "Geopriv Requirements", RFC 3693, February 2004.
[9] Cuellar, J., Morris, J., Mulligan, D., Peterson, J., and J. Polk, "Geopriv Requirements", RFC 3693, February 2004.
[10] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg,
"RPID: Rich Presence Extensions to the Presence Information Data
Format (PIDF)", RFC 4480, July 2006.
[10] Schulzrinne, H., Gurbani, V., Kyzivat, P., and J. Rosenberg, "RPID: Rich Presence Extensions to the Presence Information Data Format (PIDF)", RFC 4480, July 2006.
Schulzrinne, et al. Standards Track [Page 28] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 28] RFC 4745 Common Policy February 2007
Appendix A. Contributors
Appendix A. Contributors
We would like to thank Christian Guenther for his help with initial versions of this document.
We would like to thank Christian Guenther for his help with initial versions of this document.
Appendix B. Acknowledgments
Appendix B. Acknowledgments
This document is partially based on the discussions within the IETF GEOPRIV working group. Discussions at the Geopriv Interim Meeting 2003 in Washington, D.C., helped the working group to make progress on the authorization policies based on the discussions among the participants.
This document is partially based on the discussions within the IETF GEOPRIV working group. Discussions at the Geopriv Interim Meeting 2003 in Washington, D.C., helped the working group to make progress on the authorization policies based on the discussions among the participants.
We particularly want to thank Allison Mankin <mankin@psg.com>, Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, and Jon Peterson <jon.peterson@neustar.biz> for discussing a number of details with us. They helped us to improve the quality of this document. Allison, Ted, and Andrew also helped us to make good progress with the internationalization support of the identifier/ domain attributes.
We particularly want to thank Allison Mankin <mankin@psg.com>, Randall Gellens <rg+ietf@qualcomm.com>, Andrew Newton <anewton@ecotroph.net>, Ted Hardie <hardie@qualcomm.com>, and Jon Peterson <jon.peterson@neustar.biz> for discussing a number of details with us. They helped us to improve the quality of this document. Allison, Ted, and Andrew also helped us to make good progress with the internationalization support of the identifier/ domain attributes.
Furthermore, we would like to thank the IETF SIMPLE working group for their discussions of J. Rosenberg's draft on presence authorization policies. We would also like to thank Stefan Berg, Murugaraj Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki Niemi, Eva Maria Leppanen, Josip Matanovic, and Mark Baker for their comments. Martin Thomson helped us with the XML schema. Mark Baker provided a review of the media type. Scott Brim provided a review on behalf of the General Area Review Team.
Furthermore, we would like to thank the IETF SIMPLE working group for their discussions of J. Rosenberg's draft on presence authorization policies. We would also like to thank Stefan Berg, Murugaraj Shanmugam, Christian Schmidt, Martin Thomson, Markus Isomaki, Aki Niemi, Eva Maria Leppanen, Josip Matanovic, and Mark Baker for their comments. Martin Thomson helped us with the XML schema. Mark Baker provided a review of the media type. Scott Brim provided a review on behalf of the General Area Review Team.
Schulzrinne, et al. Standards Track [Page 29] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 29] RFC 4745 Common Policy February 2007
Authors' Addresses
Authors' Addresses
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
Henning Schulzrinne Columbia University Department of Computer Science 450 Computer Science Building New York, NY 10027 USA
Phone: +1 212 939 7042 EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
Phone: +1 212 939 7042 EMail: schulzrinne@cs.columbia.edu URI: http://www.cs.columbia.edu/~hgs
Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Hannes Tschofenig Siemens Networks GmbH & Co KG Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
EMail: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com
EMail: Hannes.Tschofenig@siemens.com URI: http://www.tschofenig.com
John B. Morris, Jr. Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 USA
John B. Morris, Jr. Center for Democracy and Technology 1634 I Street NW, Suite 1100 Washington, DC 20006 USA
EMail: jmorris@cdt.org URI: http://www.cdt.org
EMail: jmorris@cdt.org URI: http://www.cdt.org
Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
Jorge R. Cuellar Siemens Otto-Hahn-Ring 6 Munich, Bavaria 81739 Germany
EMail: Jorge.Cuellar@siemens.com
EMail: Jorge.Cuellar@siemens.com
Schulzrinne, et al. Standards Track [Page 30] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 30] RFC 4745 Common Policy February 2007
James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
James Polk Cisco 2200 East President George Bush Turnpike Richardson, Texas 75082 USA
EMail: jmpolk@cisco.com
EMail: jmpolk@cisco.com
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, New York 07054 USA
Jonathan Rosenberg Cisco Systems 600 Lanidex Plaza Parsippany, New York 07054 USA
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
EMail: jdrosen@cisco.com URI: http://www.jdrosen.net
Schulzrinne, et al. Standards Track [Page 31] RFC 4745 Common Policy February 2007
Schulzrinne, et al. Standards Track [Page 31] RFC 4745 Common Policy February 2007
Full Copyright Statement
Full Copyright Statement
Copyright (C) The IETF Trust (2007).
Copyright (C) The IETF Trust (2007).
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.
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.
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, THE IETF TRUST 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.
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, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
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.
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.
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.
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.
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.
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.
Acknowledgement
Acknowledgement
Funding for the RFC Editor function is currently provided by the Internet Society.
Funding for the RFC Editor function is currently provided by the Internet Society.
Schulzrinne, et al. Standards Track [Page 32]
Schulzrinne, et al. Standards Track [Page 32]
一覧
スポンサーリンク
