A Document Format for Requesting Consent
Extracted elements (20)
Permission documents are based on Common Policy (RFC 4745), an XML document format for expressing privacy preferences. This reuse provides a well-defined structure of conditions, actions, and transformations without needing to define a new document format from scratch.
The return routability test authentication method (for SIP PUBLISH and HTTP GET) explicitly requires no authentication and therefore no identity matching procedures are defined for it. This is a deliberate design trade-off accepting lower assurance for ease of deployment in open scenarios.
The <trans-handling> element is explicitly described as informational rather than an action as defined in Common Policy (RFC 4745), meaning the Common Policy conflict resolution mechanism does not apply to it. This avoids unintended interactions with the conflict resolution framework.
Anonymous requests using the 'anonymous' digest username are considered unauthenticated and will not match the <identity> condition. However, if a request has a Privacy header field but still contains a P-Asserted-ID, the P-Asserted-ID identity is still used in authorization computations.
Instance documents utilizing these element definitions SHOULD be schema valid. Applications processing instance documents with content not understood MUST ignore that content.
The 'id' attribute in the elements <one> and <except> MUST contain a scheme when these elements appear in a permission document.
The <sphere> element is not applicable to permission documents. If present, <sphere> elements MUST be ignored.
The <validity> element is not applicable to permission documents; each <permission> element has an infinite lifetime and can be revoked via an independent mechanism. If present, <validity> elements MUST be ignored.
A permission document is an XML document formatted according to the Common Policy schema (RFC 4745), inheriting the MIME type 'application/auth-policy+xml'. It is composed of three parts: conditions, actions, and transformations.
For SIP Digest authentication, the sender identity is the SIP Address of Record (AOR) for the authenticated user. For P-Asserted-ID, the identity is the SIP URI in that header; if multiple values exist (sip URI and tel URI), each is used for comparisons.
Four authentication mechanisms are defined for recipients granting or denying permissions in SIP: SIP Identity (RFC 4474), P-Asserted-Identity (RFC 3325, closed networks only), Return Routability Test (no identity matching), and SIP Digest.
If the <one> or <except> element lacks a scheme, conversion to a SIP URI is done by prepending 'sip:' to the 'id' attribute value, provided the characters are valid for SIP URI user and hostpart components. If conversion is not possible (e.g., UTF-8 characters in user portion), the identity condition evaluates to FALSE.
The identity condition is matched against the URI of the sender of the request used as input for a translation. Acceptable authentication mechanisms are SIP Digest, Asserted Identity (P-Asserted-ID from trusted element), and Cryptographically Verified Identity (RFC 4474 Identity header).
The recipient condition is matched against the recipient URI of a translation. When performing a translation, a relay matches the recipient condition against the destination URI of the outgoing request; when receiving a grant/deny request, it matches against the identity of the granting/denying entity.
The target condition is matched against the target URI of a translation, typically the Request-URI of the incoming request. It can contain the same elements and attributes as identity conditions.
The <trans-handling> element provides URIs for a recipient to grant or deny relay permission to perform a translation. Each policy rule must contain at least two <trans-handling> elements: one with a URI to grant and one with a URI to deny permission.
This document registers the XML namespace 'urn:ietf:params:xml:ns:consent-rules' and the XML schema 'urn:ietf:params:xml:schema:consent-rules' in the IETF XML Registry per RFC 3688.
RFC 5360 discusses security-related issues directly related to this specification, including how to authenticate SIP and HTTP requests granting permissions and how to transport permission documents between relays and recipients. Implementers must consult RFC 5360 for the complete security model.
The <trans-handling> element contains a string value of either 'deny' or 'grant', and carries a required 'perm-uri' attribute of type xs:anyURI that provides the URI to invoke for granting or denying permission.
The XML schema defines <recipient> and <target> elements both typed as cp:identityType (from Common Policy namespace), and a <trans-handling> element extending trans-values ('deny'|'grant') with a required 'perm-uri' URI attribute. Namespace is 'urn:ietf:params:xml:ns:consent-rules'.