idnits 2.17.1
draft-ietf-simple-xcap-auth-usage-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
** Looks like you're using RFC 2026 boilerplate. This must be updated to
follow RFC 3978/3979, as updated by RFC 4748.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
== No 'Intended status' indicated for this document; assuming Proposed
Standard
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack a Security Considerations section.
** There are 6 instances of too long lines in the document, the longest one
being 7 characters in excess of 72.
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the RFC 3978 Section 5.4 Copyright Line does not
match the current year
== The document seems to lack the recommended RFC 2119 boilerplate, even if
it appears to use RFC 2119 keywords.
(The document does seem to have the reference to RFC 2119 which the
ID-Checklist requires).
-- The document seems to lack a disclaimer for pre-RFC5378 work, but may
have content which was first submitted before 10 November 2008. If you
have contacted all the original authors and they are all willing to grant
the BCP78 rights to the IETF Trust, then this is fine, and you can ignore
this comment. If not, you may need to add the pre-RFC5378 disclaimer.
(See the Legal Provisions document at
https://trustee.ietf.org/license-info for more information.)
-- The document date (October 27, 2003) is 7486 days in the past. Is this
intentional?
Checking references for intended status: Proposed Standard
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
== Unused Reference: '4' is defined on line 705, but no explicit reference
was found in the text
== Unused Reference: '6' is defined on line 710, but no explicit reference
was found in the text
== Unused Reference: '15' is defined on line 744, but no explicit reference
was found in the text
== Outdated reference: A later version (-12) exists of
draft-ietf-simple-xcap-00
-- Possible downref: Non-RFC (?) normative reference: ref. '3'
-- Possible downref: Non-RFC (?) normative reference: ref. '4'
** Obsolete normative reference: RFC 2141 (ref. '5') (Obsoleted by RFC 8141)
** Obsolete normative reference: RFC 3023 (ref. '6') (Obsoleted by RFC 7303)
** Downref: Normative reference to an Informational RFC: RFC 2648 (ref. '7')
** Obsolete normative reference: RFC 2617 (ref. '8') (Obsoleted by RFC
7235, RFC 7615, RFC 7616, RFC 7617)
** Obsolete normative reference: RFC 2633 (ref. '10') (Obsoleted by RFC
3851)
== Outdated reference: A later version (-10) exists of
draft-ietf-simple-rpid-00
== Outdated reference: A later version (-05) exists of
draft-ietf-simple-xcap-list-usage-00
Summary: 8 errors (**), 0 flaws (~~), 9 warnings (==), 4 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
1 SIMPLE J. Rosenberg
2 Internet-Draft dynamicsoft
3 Expires: April 26, 2004 October 27, 2003
5 Extensible Markup Language (XML) Configuration Access Protocol (XCAP)
6 Usages for Setting Presence Authorization
7 draft-ietf-simple-xcap-auth-usage-01
9 Status of this Memo
11 This document is an Internet-Draft and is in full conformance with
12 all provisions of Section 10 of RFC2026.
14 Internet-Drafts are working documents of the Internet Engineering
15 Task Force (IETF), its areas, and its working groups. Note that other
16 groups may also distribute working documents as Internet-Drafts.
18 Internet-Drafts are draft documents valid for a maximum of six months
19 and may be updated, replaced, or obsoleted by other documents at any
20 time. It is inappropriate to use Internet-Drafts as reference
21 material or to cite them other than as "work in progress."
23 The list of current Internet-Drafts can be accessed at http://
24 www.ietf.org/ietf/1id-abstracts.txt.
26 The list of Internet-Draft Shadow Directories can be accessed at
27 http://www.ietf.org/shadow.html.
29 This Internet-Draft will expire on April 26, 2004.
31 Copyright Notice
33 Copyright (C) The Internet Society (2003). All Rights Reserved.
35 Abstract
37 This document describes two usages of the Extensible Markup Language
38 (XML) Configuration Access Protocol (XCAP) that allow a client to
39 provide authorization decisions regarding watchers of their presence.
40 The first of these usages, called permission-statements, contains
41 statements about what permissions are to be granted to watchers of
42 presence. The second usage, called supported-permissions, allows a
43 client to determine what permissions are understood by the provider.
45 Table of Contents
47 1. Introduction . . . . . . . . . . . . . . . . . . . . . . 3
48 2. Structuring Presence Authorization . . . . . . . . . . . 4
49 3. Terminology . . . . . . . . . . . . . . . . . . . . . . 5
50 4. Permission Statements . . . . . . . . . . . . . . . . . 6
51 4.1 Application Unique ID . . . . . . . . . . . . . . . . . 6
52 4.2 Structure of Permission Statements . . . . . . . . . . . 6
53 4.2.1 Applying Statements to Watchers . . . . . . . . . . . . 6
54 4.2.2 Specifying Permissions . . . . . . . . . . . . . . . . . 8
55 4.2.2.1 Acceptance Permissions . . . . . . . . . . . . . . . . . 8
56 4.2.2.2 Content Permissions . . . . . . . . . . . . . . . . . . 10
57 4.2.2.2.1 Examples . . . . . . . . . . . . . . . . . . . . . . . . 11
58 4.3 Additional Constraints . . . . . . . . . . . . . . . . . 12
59 4.4 Naming Conventions . . . . . . . . . . . . . . . . . . . 12
60 4.5 Authorization Policies . . . . . . . . . . . . . . . . . 12
61 4.6 XML Schema . . . . . . . . . . . . . . . . . . . . . . . 13
62 5. Supported Permissions . . . . . . . . . . . . . . . . . 14
63 5.1 Application Unique ID . . . . . . . . . . . . . . . . . 14
64 5.2 Structure of Supported Permissions . . . . . . . . . . . 14
65 5.3 Naming Conventions . . . . . . . . . . . . . . . . . . . 15
66 5.4 Authorization Policies . . . . . . . . . . . . . . . . . 15
67 5.5 XML Schema . . . . . . . . . . . . . . . . . . . . . . . 16
68 5.6 Example Document . . . . . . . . . . . . . . . . . . . . 16
69 6. IANA Considerations . . . . . . . . . . . . . . . . . . 18
70 6.1 XCAP Application Usage IDs . . . . . . . . . . . . . . . 18
71 6.1.1 Permission Statements . . . . . . . . . . . . . . . . . 18
72 6.1.2 Supported Permissions . . . . . . . . . . . . . . . . . 18
73 6.2 URN Sub-Namespace Registrations . . . . . . . . . . . . 18
74 6.2.1 urn:ietf:params:xml:ns:permission-statements . . . . . . 18
75 6.2.2 urn:ietf:params:xml:ns:supported-permissions . . . . . . 19
76 6.3 XML Schema Registrations . . . . . . . . . . . . . . . . 20
77 6.3.1 Permissions Statements . . . . . . . . . . . . . . . . . 20
78 6.3.2 Supported Permissions . . . . . . . . . . . . . . . . . 20
79 Normative References . . . . . . . . . . . . . . . . . . 21
80 Informative References . . . . . . . . . . . . . . . . . 22
81 Author's Address . . . . . . . . . . . . . . . . . . . . 22
82 Intellectual Property and Copyright Statements . . . . . 23
84 1. Introduction
86 The Session Initiation Protocol (SIP) for Instant Messaging and
87 Presence (SIMPLE) specifications allow a user, called a watcher, to
88 subscribe to another user, called a presentity [13], in order to
89 learn their presence information [14]. This subscription is handed by
90 a presence agent. In order to process the subscription, the presence
91 agent must make a determination about whether the subscription is
92 authorized. This authorization decision includes whether or not to
93 accept the subscription, but also includes decisions about when the
94 watcher should receive notifications, and when it does receive them,
95 what the content of those notifications should be.
97 Typically, the authorization decision will be a combination of the
98 authorization policies of the provider, combined with the
99 authorization policices of the presentity. In order for the PA to
100 compute the final authorization decision, it needs access to the
101 presentity's authorization policies.
103 In order to provide this access, the XML Configuration Access
104 Protocol (XCAP) [2] is used. XCAP allows a client to manipulate XML
105 documents stored on a server. Those XML documents represent per-user
106 provisioning data on how an application should operate. XCAP has the
107 notion of an application usage, which is a definition of the XML
108 schema used by a particular application, along with other relevant
109 information. Each application usage is given a unique application
110 usage ID (AUID) which identifies it. This specification makes use of
111 three application usages.
113 2. Structuring Presence Authorization
115 This specification defines three application usages (each with their
116 own XML schema) that, put together, present a comprehensive solution
117 for allowing clients to specify authorization policies that a PA can
118 use when processing a subscription. The first of these application
119 usages has the AUID of permission-statements. This usage allows a
120 client to make statements about which permissions are granted to
121 which watchers. Each statement contains a definition of the watchers
122 to whom it applies, and then contains a list of permissions which are
123 granted to those watchers. The concept of a permission is central to
124 this specification. A permission is an atomic statement of consent. A
125 permission can indicate a condition under which a subscription is
126 accepted or rejected, a condition under which a notification is or is
127 not sent, or a piece of information which is revealed in a presence
128 document. The overall authorization for a watcher is represented by
129 the union of the permissions granted to that watcher.
131 This specification contains a basic set of primitive permissions. It
132 is anticipated that new ones will be standardized in the future. It
133 is also anticipated that vendors will define proprietary permissions.
134 In order for a client to connect to a server, and achieve
135 interoperability, it is neccesary for the client to know what
136 permissions are supported by the server. The second application
137 usage, supported-permissions, allows a client to read the list of
138 permissions understood by the server.
140 3. Terminology
142 In this document, the key words "MUST", "MUST NOT", "REQUIRED",
143 "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
144 and "OPTIONAL" are to be interpreted as described in RFC 2119 [1] and
145 indicate requirement levels for compliant implementations.
147 4. Permission Statements
149 4.1 Application Unique ID
151 XCAP requires application usages to define a unique application usage
152 ID (AUID) in either the IETF tree or a vendor tree. This
153 specification defines the "permission-statements" AUID within the
154 IETF tree, via the IANA registration in Section 6.
156 4.2 Structure of Permission Statements
158 A permission statement is an XML [3] document that MUST be
159 well-formed and SHOULD be valid. Permission statement documents MUST
160 be based on XML 1.0 and MUST be encoded using UTF-8. This
161 specification makes use of XML namespaces for identifying permission
162 statement documents and document fragments. The namespace URI for
163 elements defined for this purpose is a URN [5], using the namespace
164 identifier 'ietf' defined by [7] and extended by [11]. This URN is:
166 urn:ietf:params:xml:ns:permission-statements
168 A permission statement document begins with the root element tag
169 "permission-statements". It consists of any number of "statement"
170 elements. Each statement element defines a set of permissions and
171 identifies to whom they are granted.
173 Each "statement" element has a single attribute:
175 id: This is a string which serves as a way to uniquely identify
176 statements in the document. The attribute MUST be unique amongst
177 all statement elements in the document. This attribute is
178 mandatory.
180 Each statement is composed of a single "applies-to" element and a
181 single "permissions" element. The "permissions" element is composed
182 of one or more elements that grant permissions.
184 4.2.1 Applying Statements to Watchers
186 The "applies-to" element defines the set of watchers to whom the
187 statement applies. It contains one or more "uri" elements, "domain"
188 elements, "on-list" elements or a single "any" element, followed by
189 any number of "except" elements. The "uri" element identifies a
190 single watcher by specifying its URI. The "domain" element says that
191 the statement applies to all watchers from the specified domain. The
192 "on-list" element says that the statement applies to all users on the
193 specified presence list [17], identified with an HTTP URI that points
194 to the list. Finally, the "any" element says that the statement
195 applies to all watchers. Additional elements can be added that
196 express other ways of identifying the watchers to whom the statement
197 applies. When unioned together, the result of the "uri", "domain",
198 "on-list" and "any" elements define a set of users to whom the
199 permission statement applies. This list is reduced in size by the
200 "except" element, which removes a user or domain from the set. The
201 "except" element contains instances of the "uri", "domain" and
202 "on-list" elements, which specify the users, domains, lists to be
203 removed from the set.
205 The "uri", "domain", "on-list", and "any" elements all have the
206 following attributes:
208 id: This is a string which serves as a way to uniquely identify an
209 instance of this element within the enclosing "applies-to"
210 element. The attribute MUST be unique amongst all elements of the
211 same name within the enclosing "applies-to" element. This
212 attribute is mandatory.
214 display-name: This is a string that contains a display name, suitable
215 for rendering to a human user, the identity of the user or domain
216 implied by the element. This attribute is optional.
218 lang: This attribute identifies the language used to represent the
219 display name. It is imported from the XML namespace. This
220 attribute is optional.
222 When a subscription arrives at the PA, the PA performs an
223 authentication operation to determine the identity of the watcher. It
224 then uses the "applies-to" element in each statement within the
225 presentity's document, and determines the set of statements that
226 apply to the watcher. It is possible that multiple statements can
227 match a single subscription. In that case, the union of the
228 permissions across those statements is applied to the subscription.
229 It is also possible that none of the statements match, in which case
230 the subscription is considered "pending".
232 For example, the following XML fragment includes two statements, one
233 that applies to the user joe@example.com, and another that applies to
234 example.com. When Joe subscribes, both statements match. Therefore,
235 he is granted the union of the permissions across the two statements.
237
238
See RFCXXXX.
635 636 637 END 639 6.2.2 urn:ietf:params:xml:ns:supported-permissions 641 URI: The URI for this namespace is 642 urn:ietf:params:xml:ns:supported-permissions. 644 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 645 Jonathan Rosenberg (jdrosen@jdrosen.net). 647 XML: 649 BEGIN 650 651 653 654 655 657See RFCXXXX.
663 664 665 END 667 6.3 XML Schema Registrations 669 This section registers three XML schemas as per the procedures in 670 [11]. 672 6.3.1 Permissions Statements 674 URI: please assign. 676 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 677 Jonathan Rosenberg (jdrosen@jdrosen.net). 679 The XML for this schema can be found as the sole content of 680 Section 4.6. 682 6.3.2 Supported Permissions 684 URI: please assign. 686 Registrant Contact: IETF, SIMPLE working group, (simple@ietf.org), 687 Jonathan Rosenberg (jdrosen@jdrosen.net). 689 The XML for this schema can be found as the sole content of 690 Section 5.5. 692 Normative References 694 [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement 695 Levels", BCP 14, RFC 2119, March 1997. 697 [2] Rosenberg, J., "The Extensible Markup Language (XML) 698 Configuration Access Protocol (XCAP)", 699 draft-ietf-simple-xcap-00 (work in progress), June 2003. 701 [3] Bray, T., Paoli, J., Sperberg-McQueen, C. and E. Maler, 702 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 703 REC REC-xml-20001006, October 2000. 705 [4] Clark, J. and S. DeRose, "XML Path Language (XPath) Version 706 1.0", W3C REC REC-xpath-19991116, November 1999. 708 [5] Moats, R., "URN Syntax", RFC 2141, May 1997. 710 [6] Murata, M., St. Laurent, S. and D. Kohn, "XML Media Types", RFC 711 3023, January 2001. 713 [7] Moats, R., "A URN Namespace for IETF Documents", RFC 2648, 714 August 1999. 716 [8] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., 717 Leach, P., Luotonen, A. and L. Stewart, "HTTP Authentication: 718 Basic and Digest Access Authentication", RFC 2617, June 1999. 720 [9] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., 721 Peterson, J., Sparks, R., Handley, M. and E. Schooler, "SIP: 722 Session Initiation Protocol", RFC 3261, June 2002. 724 [10] Ramsdell, B., "S/MIME Version 3 Message Specification", RFC 725 2633, June 1999. 727 [11] Mealling, M., "The IETF XML Registry", 728 draft-mealling-iana-xmlns-registry-05 (work in progress), June 729 2003. 731 [12] Schulzrinne, H., "RPID -- Rich Presence Information Data 732 Format", draft-ietf-simple-rpid-00 (work in progress), July 733 2003. 735 Informative References 737 [13] Day, M., Rosenberg, J. and H. Sugano, "A Model for Presence and 738 Instant Messaging", RFC 2778, February 2000. 740 [14] Rosenberg, J., "A Presence Event Package for the Session 741 Initiation Protocol (SIP)", draft-ietf-simple-presence-10 (work 742 in progress), January 2003. 744 [15] Sugano, H. and S. Fujimoto, "Presence Information Data Format 745 (PIDF)", draft-ietf-impp-cpim-pidf-08 (work in progress), May 746 2003. 748 [16] Jennings, C., Peterson, J. and M. Watson, "Private Extensions 749 to the Session Initiation Protocol (SIP) for Asserted Identity 750 within Trusted Networks", RFC 3325, November 2002. 752 [17] Rosenberg, J., "An Extensible Markup Language (XML) 753 Configuration Access Protocol (XCAP) Usage for Presence 754 Lists", draft-ietf-simple-xcap-list-usage-00 (work in 755 progress), June 2003. 757 Author's Address 759 Jonathan Rosenberg 760 dynamicsoft 761 600 Lanidex Plaza 762 Parsippany, NJ 07052 763 US 765 Phone: +1 973 952-5000 766 EMail: jdrosen@dynamicsoft.com 767 URI: http://www.jdrosen.net 769 Intellectual Property Statement 771 The IETF takes no position regarding the validity or scope of any 772 intellectual property or other rights that might be claimed to 773 pertain to the implementation or use of the technology described in 774 this document or the extent to which any license under such rights 775 might or might not be available; neither does it represent that it 776 has made any effort to identify any such rights. Information on the 777 IETF's procedures with respect to rights in standards-track and 778 standards-related documentation can be found in BCP-11. Copies of 779 claims of rights made available for publication and any assurances of 780 licenses to be made available, or the result of an attempt made to 781 obtain a general license or permission for the use of such 782 proprietary rights by implementors or users of this specification can 783 be obtained from the IETF Secretariat. 785 The IETF invites any interested party to bring to its attention any 786 copyrights, patents or patent applications, or other proprietary 787 rights which may cover technology that may be required to practice 788 this standard. Please address the information to the IETF Executive 789 Director. 791 Full Copyright Statement 793 Copyright (C) The Internet Society (2003). All Rights Reserved. 795 This document and translations of it may be copied and furnished to 796 others, and derivative works that comment on or otherwise explain it 797 or assist in its implementation may be prepared, copied, published 798 and distributed, in whole or in part, without restriction of any 799 kind, provided that the above copyright notice and this paragraph are 800 included on all such copies and derivative works. However, this 801 document itself may not be modified in any way, such as by removing 802 the copyright notice or references to the Internet Society or other 803 Internet organizations, except as needed for the purpose of 804 developing Internet standards in which case the procedures for 805 copyrights defined in the Internet Standards process must be 806 followed, or as required to translate it into languages other than 807 English. 809 The limited permissions granted above are perpetual and will not be 810 revoked by the Internet Society or its successors or assignees. 812 This document and the information contained herein is provided on an 813 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 814 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 815 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 816 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 817 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 819 Acknowledgement 821 Funding for the RFC Editor function is currently provided by the 822 Internet Society.