draft-ietf-sipping-consent-format-06.txt   draft-ietf-sipping-consent-format-07.txt 
SIPPING G. Camarillo SIPPING G. Camarillo
Internet-Draft Ericsson Internet-Draft Ericsson
Intended status: Standards Track February 15, 2008 Intended status: Standards Track May 29, 2008
Expires: August 18, 2008 Expires: November 30, 2008
A Document Format for Requesting Consent A Document Format for Requesting Consent
draft-ietf-sipping-consent-format-06.txt draft-ietf-sipping-consent-format-07.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 34 skipping to change at page 1, line 34
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on August 18, 2008. This Internet-Draft will expire on November 30, 2008.
Copyright Notice Copyright Notice
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
Abstract Abstract
This document defines an Extensible Markup Language (XML) format for This document defines an Extensible Markup Language (XML) format for
a permission document used to request consent. A permission document a permission document used to request consent. A permission document
written in this format is used by a relay to request a specific written in this format is used by a relay to request a specific
recipient permission to perform a particular routing translation. recipient permission to perform a particular routing translation.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3 2. Definitions and Terminology . . . . . . . . . . . . . . . . . 3
3. Permission Document Structure . . . . . . . . . . . . . . . . 4 3. Permission Document Structure . . . . . . . . . . . . . . . . 4
3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. Conditions . . . . . . . . . . . . . . . . . . . . . . . . 4
3.1.1. Recipient Condition . . . . . . . . . . . . . . . . . 4 3.1.1. Recipient Condition . . . . . . . . . . . . . . . . . 4
3.1.2. Identity Condition . . . . . . . . . . . . . . . . . . 5 3.1.2. Identity Condition . . . . . . . . . . . . . . . . . . 5
3.1.3. Target Condition . . . . . . . . . . . . . . . . . . . 7 3.1.3. Target Condition . . . . . . . . . . . . . . . . . . . 8
3.1.4. Validity Condition . . . . . . . . . . . . . . . . . . 8 3.1.4. Validity Condition . . . . . . . . . . . . . . . . . . 8
3.1.5. Sphere Condition . . . . . . . . . . . . . . . . . . . 8 3.1.5. Sphere Condition . . . . . . . . . . . . . . . . . . . 8
3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.2. Actions . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2.1. Translation Handling . . . . . . . . . . . . . . . . . 8 3.2.1. Translation Handling . . . . . . . . . . . . . . . . . 8
4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 8 4. Example Document . . . . . . . . . . . . . . . . . . . . . . . 9
5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. XML Schema . . . . . . . . . . . . . . . . . . . . . . . . . . 10
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. XML Namespace Registration . . . . . . . . . . . . . . . . 11 6.1. XML Namespace Registration . . . . . . . . . . . . . . . . 11
6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12 6.2. XML Schema Registration . . . . . . . . . . . . . . . . . 12
7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13
9.2. Informative References . . . . . . . . . . . . . . . . . . 13 9.2. Informative References . . . . . . . . . . . . . . . . . . 13
Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14
skipping to change at page 4, line 31 skipping to change at page 4, line 31
type of common policy documents, 'application/auth-policy+xml'. As type of common policy documents, 'application/auth-policy+xml'. As
described in [RFC4745], this type of document is composed of three described in [RFC4745], this type of document is composed of three
parts: conditions, actions, and transformations. parts: conditions, actions, and transformations.
This section defines the new conditions and actions defined by this This section defines the new conditions and actions defined by this
specification. This specification does not define any new specification. This specification does not define any new
transformation. transformation.
3.1. Conditions 3.1. Conditions
Note that, as discussed in [RFC4745], a permission document applies The conditions in a permission document are a set of expressions,
to a translation if all the expressions in its conditions part each of which evaluates to either TRUE or FALSE. Note that, as
evaluate to TRUE. discussed in [RFC4745], a permission document applies to a
translation if all the expressions in its conditions part evaluate to
TRUE.
3.1.1. Recipient Condition 3.1.1. Recipient Condition
The recipient condition is matched against the recipient URI of a The recipient condition is matched against the recipient URI of a
translation. Recipient conditions can contain the same elements and translation. Recipient conditions can contain the same elements and
attributes as identity conditions. attributes as identity conditions.
When performing a translation, a relay matches the recipient When performing a translation, a relay matches the recipient
condition of the permission document that was used to request condition of the permission document that was used to request
permission for that translation against the destination URI of the permission for that translation against the destination URI of the
outgoing request. When receiving a request granting or denying outgoing request. When receiving a request granting or denying
permissions (e.g., a SIP PUBLISH request as described in permissions (e.g., a SIP PUBLISH request as described in
[I-D.ietf-sip-consent-framework]), the relay matches the recipient [I-D.ietf-sip-consent-framework]), the relay matches the recipient
condition of the permission document that was used to request condition of the permission document that was used to request
permission against the identity of the entity granting or denying permission against the identity of the entity granting or denying
permissions (i.e., the sender of the PUBLISH request). permissions (i.e., the sender of the PUBLISH request). If there is a
match, the recipient condition evaluates to TRUE. Otherwise, the
recipient condition evaluates to FALSE.
This section defines acceptable means of authentication, which are in Since only authenticated identities can be matched, this section
line with those described in Section 5.6.1 of defines acceptable means of authentication, which are in line with
[I-D.ietf-sip-consent-framework]. those described in Section 5.6.1 of [I-D.ietf-sip-consent-framework].
The 'id' attribute in the elements <one> and <except> MUST contain a The 'id' attribute in the elements <one> and <except> MUST contain a
scheme when these elements appear in a permission document. scheme when these elements appear in a permission document.
When used with SIP, a recipient granting or denying a relay When used with SIP, a recipient granting or denying a relay
permissions is considered authenticated if one of the following permissions is considered authenticated if one of the following
techniques is used: techniques is used:
SIP Identity [RFC4474], as described in Section 5.6.1.1 of SIP Identity [RFC4474], as described in Section 5.6.1.1 of
[I-D.ietf-sip-consent-framework]. For PUBLISH requests that are [I-D.ietf-sip-consent-framework]. For PUBLISH requests that are
skipping to change at page 5, line 46 skipping to change at page 5, line 50
set equal to the SIP Address of Record (AOR) for the user that has set equal to the SIP Address of Record (AOR) for the user that has
authenticated themselves. authenticated themselves.
3.1.2. Identity Condition 3.1.2. Identity Condition
The identity condition, which is defined in [RFC4745], is matched The identity condition, which is defined in [RFC4745], is matched
against the URI of the sender of the request that is used as input against the URI of the sender of the request that is used as input
for a translation. for a translation.
When performing a translation, a relay matches the identity condition When performing a translation, a relay matches the identity condition
against the identity of the sender of the incoming request. against the identity of the sender of the incoming request. If they
match, the identity condition evaluates to TRUE. Otherwise, the
identity condition evaluates to FALSE.
The following subsections define acceptable means of authentication, Since only authenticated identities can be matched, the following
the procedure for representing the identity of the sender as a URI, subsections define acceptable means of authentication, the procedure
and the procedure for converting an identifier of the form for representing the identity of the sender as a URI, and the
user@domain, present in the 'id' attribute of the <one> and <except> procedure for converting an identifier of the form user@domain,
elements, into a URI. present in the 'id' attribute of the <one> and <except> elements,
into a URI.
3.1.2.1. Acceptable Means of Authentication 3.1.2.1. Acceptable Means of Authentication
When used with SIP, a request sent by a sender is considered When used with SIP, a request sent by a sender is considered
authenticated if one of the following techniques is used: authenticated if one of the following techniques is used:
SIP Digest: the relay authenticates the sender using SIP digest SIP Digest: the relay authenticates the sender using SIP digest
authentication [RFC2617]. However, if the anonymous authentication [RFC2617]. However, if the anonymous
authentication described on page 194 of [RFC3261] is used, the authentication described on page 194 of [RFC3261] is used, the
sender is not considered authenticated. sender is not considered authenticated.
skipping to change at page 7, line 25 skipping to change at page 7, line 32
a Privacy header field [RFC3323], but still contains a P-Asserted-ID a Privacy header field [RFC3323], but still contains a P-Asserted-ID
header field, the identity in the P-Asserted-ID header field is still header field, the identity in the P-Asserted-ID header field is still
used in the authorization computations; the fact that the request was used in the authorization computations; the fact that the request was
anonymous has no impact on the identity processing. However, if the anonymous has no impact on the identity processing. However, if the
request had traversed a trust boundary and the P-Asserted-ID header request had traversed a trust boundary and the P-Asserted-ID header
field and the Privacy header field had been removed, the request will field and the Privacy header field had been removed, the request will
be considered unauthenticated when it arrives at the relay, and thus be considered unauthenticated when it arrives at the relay, and thus
not match the <sender> condition. Finally, if a request contained an not match the <sender> condition. Finally, if a request contained an
Identity header field that was validated, and the From header field Identity header field that was validated, and the From header field
contained a URI of the form sip:anonymous@example.com, then the contained a URI of the form sip:anonymous@example.com, then the
watcher is considered authenticated, and it will have an identity sender is considered authenticated, and it will have an identity
equal to sip:anonymous@example.com. Had such an identity been placed equal to sip:anonymous@example.com. Had such an identity been placed
into a <one> or <except> element, there will be a match. into a <one> or <except> element, there will be a match.
3.1.2.3. Computing a SIP URI from the id Attribute 3.1.2.3. Computing a SIP URI from the id Attribute
If the <one> or <except> condition does not contain a scheme, If the <one> or <except> condition does not contain a scheme,
conversion of the value in the 'id' attribute to a SIP URI is done conversion of the value in the 'id' attribute to a SIP URI is done
trivially. If the characters in the 'id' attribute are valid trivially. If the characters in the 'id' attribute are valid
characters for the user and hostpart components of the SIP URI, a characters for the user and hostpart components of the SIP URI, a
'sip:' is appended to the contents of the 'id' attribute, and the 'sip:' is appended to the contents of the 'id' attribute, and the
result is the SIP URI. If the characters in the 'id' attribute are result is the SIP URI. If the characters in the 'id' attribute are
not valid for the user and hostpart components of the SIP URI, not valid for the user and hostpart components of the SIP URI,
conversion is not possible. This happens, for example, when the user conversion is not possible and, thus, the identity condition
portion of the 'id' attribute contain UTF-8 characters. evaluates to FALSE. This happens, for example, when the user portion
of the 'id' attribute contains UTF-8 characters.
3.1.3. Target Condition 3.1.3. Target Condition
The target condition is matched against the target URI of a The target condition is matched against the target URI of a
translation. The target condition can contain the same elements and translation. The target condition can contain the same elements and
attributes as identity conditions. attributes as identity conditions.
When performing a translation, a relay matches the target condition When performing a translation, a relay matches the target condition
against the destination of the incoming request, which is typically against the destination of the incoming request, which is typically
contained in the Request-URI. contained in the Request-URI. If they match, the target condition
evaluates to TRUE. Otherwise, the target condition evaluates to
FALSE.
3.1.4. Validity Condition 3.1.4. Validity Condition
The <validity> element is not applicable to this document. Each The <validity> element is not applicable to this document. Each
permission element has an infinite lifetime and can be revoked using permission element has an infinite lifetime and can be revoked using
an independent mechanism, as described in Section 5.8 of an independent mechanism, as described in Section 5.8 of
[I-D.ietf-sip-consent-framework]. In any case, as discussed in [I-D.ietf-sip-consent-framework]. In any case, as discussed in
Section 4.1 of [I-D.ietf-sip-consent-framework], permissions are only Section 4.1 of [I-D.ietf-sip-consent-framework], permissions are only
valid as long as the context where they were granted is valid. valid as long as the context where they were granted is valid. If
present, <validity> elements MUST be ignored.
3.1.5. Sphere Condition 3.1.5. Sphere Condition
The <sphere> element is not applicable to this document and therefore The <sphere> element is not applicable to this document and therefore
is not used. is not used. If present, <sphere> elements MUST be ignored.
3.2. Actions 3.2. Actions
The actions in a permission document provide URIs to grant or deny The actions in a permission document provide URIs to grant or deny
permission to perform the translation described in the document. permission to perform the translation described in the document.
Note that the <trans-handling> element is not an action, as Note that the <trans-handling> element is not an action, as
defined in Common Policy [RFC4745], but rather an informational defined in Common Policy [RFC4745], but rather an informational
element. Therefore, the conflict resolution mechanism does not element. Therefore, the conflict resolution mechanism does not
apply to it. apply to it.
skipping to change at page 13, line 5 skipping to change at page 13, line 5
security-related issues, such as how to authenticate SIP and HTTP security-related issues, such as how to authenticate SIP and HTTP
requests granting permissions and how to transport permission requests granting permissions and how to transport permission
documents between relays and recipients, that are directly related to documents between relays and recipients, that are directly related to
this specification. this specification.
8. Acknowledgements 8. Acknowledgements
Jonathan Rosenberg provided useful ideas on this document. Hannes Jonathan Rosenberg provided useful ideas on this document. Hannes
Tschofenig helped align this document with common policy. Ben Tschofenig helped align this document with common policy. Ben
Campbell and Mary Barnes performed a thorough review of this Campbell and Mary Barnes performed a thorough review of this
document. document. Lakshminath Dondeti provided useful comments.
9. References 9. References
9.1. Normative References 9.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
skipping to change at page 13, line 40 skipping to change at page 13, line 40
[RFC4474] Peterson, J. and C. Jennings, "Enhancements for [RFC4474] Peterson, J. and C. Jennings, "Enhancements for
Authenticated Identity Management in the Session Authenticated Identity Management in the Session
Initiation Protocol (SIP)", RFC 4474, August 2006. Initiation Protocol (SIP)", RFC 4474, August 2006.
[RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J., [RFC4745] Schulzrinne, H., Tschofenig, H., Morris, J., Cuellar, J.,
Polk, J., and J. Rosenberg, "Common Policy: A Document Polk, J., and J. Rosenberg, "Common Policy: A Document
Format for Expressing Privacy Preferences", RFC 4745, Format for Expressing Privacy Preferences", RFC 4745,
February 2007. February 2007.
[I-D.ietf-sip-consent-framework] [I-D.ietf-sip-consent-framework]
Rosenberg, J., "A Framework for Consent-Based Rosenberg, J., Camarillo, G., and D. Willis, "A Framework
Communications in the Session Initiation Protocol (SIP)", for Consent-based Communications in the Session Initiation
draft-ietf-sip-consent-framework-01 (work in progress), Protocol (SIP)", draft-ietf-sip-consent-framework-04 (work
November 2006. in progress), January 2008.
9.2. Informative References 9.2. Informative References
[RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers", [RFC3966] Schulzrinne, H., "The tel URI for Telephone Numbers",
RFC 3966, December 2004. RFC 3966, December 2004.
[RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private [RFC3325] Jennings, C., Peterson, J., and M. Watson, "Private
Extensions to the Session Initiation Protocol (SIP) for Extensions to the Session Initiation Protocol (SIP) for
Asserted Identity within Trusted Networks", RFC 3325, Asserted Identity within Trusted Networks", RFC 3325,
November 2002. November 2002.
 End of changes. 17 change blocks. 
30 lines changed or deleted 41 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/