A Document Format for Requesting Consent

A permission document is an XML document, formatted according to the schema defined in . Permission documents inherit the MIME type of common policy documents, 'application/auth-policy+xml'. As described in , this type of document is composed of three parts: conditions, actions, and transformations. This section defines the new conditions and actions defined by this specification. This specification does not define any new transformation.

The conditions in a permission document are a set of expressions, each of which evaluates to either TRUE or FALSE. Note that, as discussed in , a permission document applies to a translation if all the expressions in its conditions part evaluate to TRUE.

The recipient condition is matched against the recipient URI of a translation. Recipient conditions can contain the same elements and attributes as identity conditions. When performing a translation, a relay matches the recipient condition of the permission document that was used to request permission for that translation against the destination URI of the outgoing request. When receiving a request granting or denying permissions (e.g., a SIP PUBLISH request as described in ), the relay matches the recipient condition of the permission document that was used to request permission against the identity of the entity granting or denying 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. Since only authenticated identities can be matched, this section defines acceptable means of authentication, which are in line with those described in Section 5.6.1 of . The 'id' attribute in the elements <one> and <except> MUST contain a scheme when these elements appear in a permission document. When used with SIP, a recipient granting or denying a relay permissions is considered authenticated if one of the following techniques is used: , as described in Section 5.6.1.1 of . For PUBLISH requests that are authenticated using the SIP Identity mechanism, the identity of the sender of the PUBLISH request is equal to the SIP URI in the From header field of the request, assuming that the signature in the Identity header field has been validated. (which can only be used in closed network environments) as described in Section 5.6.1.2 of . For PUBLISH requests that are authenticated using the P-Asserted-Identity mechanism, the identity of the sender of the PUBLISH request is equal to the P-Asserted-Identity header field of the request. as described in Section 5.6.1.3 of . It can be used for SIP PUBLISH and HTTP GET requests. No authentication is expected to be used with return routability tests and, therefore, no identity matching procedures are defined. as described in Section 5.6.1.4 of . The identity of the sender is set equal to the SIP Address of Record (AOR) for the user that has authenticated themselves.

The identity condition, which is defined in , is matched against the URI of the sender of the request that is used as input for a translation. When performing a translation, a relay matches the identity condition 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. Since only authenticated identities can be matched, the following subsections define acceptable means of authentication, the procedure for representing the identity of the sender as a URI, and the procedure for converting an identifier of the form user@domain, present in the 'id' attribute of the <one> and <except> elements, into a URI.

When used with SIP, a request sent by a sender is considered authenticated if one of the following techniques is used: the relay authenticates the sender using SIP digest authentication . However, if the anonymous authentication described on page 194 of is used, the sender is not considered authenticated. if a request contains a P-Asserted-ID header field and the request is coming from a trusted element, the sender is considered authenticated. if a request contains an Identity header field as defined in , and it validates the From header field of the request, the request is considered to be authenticated. Note that this is true even if the request contained a From header field of the form sip:anonymous@example.com. As long as the signature verifies that the request legitimately came from this identity, it is considered authenticated.

For requests that are authenticated using SIP Digest, the identity of the sender is set equal to the SIP Address of Record (AOR) for the user that has authenticated themselves. For example, consider the following "user record" in a database: SIP AOR: sip:alice@example.com digest username: ali digest password: f779ajvvh8a6s6 digest realm: example.com If the relay receives a request and challenges it with the realm set to "example.com", and the subsequent request contains an Authorization header field with a username of "ali" and a digest response generated with the password "f779ajvvh8a6s6", the identity used in matching operations is "sip:alice@example.com". For requests that are authenticated using , the identity of the sender is equal to the SIP URI in the P-Asserted-ID header field. If there are multiple values for the P-Asserted-ID header field (there can be one sip URI and one tel URI ), then each of them is used for the comparisons outlined in ; if either of them match a <one> or <except> element, it is considered a match. For requests that are authenticated using the SIP Identity mechanism , identity of the sender is equal to the SIP URI in the From header field of the request, assuming that the signature in the Identity header field has been validated. SIP also allows for anonymous requests. If a request is anonymous because the digest challenge/response used the "anonymous" username, the request is considered unauthenticated and will not match the <identity> condition. If a request is anonymous because it contains a Privacy header field , but still contains a P-Asserted-ID header field, the identity in the P-Asserted-ID header field is still used in the authorization computations; the fact that the request was anonymous has no impact on the identity processing. However, if the request had traversed a trust boundary and the P-Asserted-ID header field and the Privacy header field had been removed, the request will be considered unauthenticated when it arrives at the relay, and thus not match the <sender> condition. Finally, if a request contained an Identity header field that was validated, and the From header field contained a URI of the form sip:anonymous@example.com, then the sender is considered authenticated, and it will have an identity equal to sip:anonymous@example.com. Had such an identity been placed into a <one> or <except> element, there will be a match.

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 trivially. If the characters in the 'id' attribute are valid characters for the user and hostpart components of the SIP URI, a '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 not valid for the user and hostpart components of the SIP URI, conversion is not possible and, thus, the identity condition evaluates to FALSE. This happens, for example, when the user portion of the 'id' attribute contains UTF-8 characters.

The target condition is matched against the target URI of a translation. The target condition can contain the same elements and attributes as identity conditions. When performing a translation, a relay matches the target condition against the destination of the incoming request, which is typically contained in the Request-URI. If they match, the target condition evaluates to TRUE. Otherwise, the target condition evaluates to FALSE.

The <validity> element is not applicable to this document. Each <permission> element has an infinite lifetime and can be revoked using an independent mechanism, as described in Section 5.8 of . In any case, as discussed in Section 4.1 of , permissions are only valid as long as the context where they were granted is valid. If present, <validity> elements MUST be ignored.

The <sphere> element is not applicable to this document and therefore is not used. If present, <sphere> elements MUST be ignored.

The actions in a permission document provide URIs to grant or deny permission to perform the translation described in the document. Note that the <trans-handling> element is not an action, as defined in Common Policy , but rather an informational element. Therefore, the conflict resolution mechanism does not apply to it. Each policy rule contains at least two <trans-handling> elements; one element with a URI to grant and another with a URI to deny permission.

The <trans-handling> provides URIs for a recipient to grant or deny the relay permission to perform a translation. The defined values are: this action tells the relay not to perform the translation. this action tells the server to perform the translation. The 'perm-uri' attribute in the <trans-handling> element provides a URI to grant or deny permission to perform a translation.

Namespace for Permission Documents

urn:ietf:params:xml:ns:consent-rules