The IESG has approved the following document: - 'Trait-based Authorization Requirements for the Session Initiation Protocol (SIP) ' <draft-ietf-sipping-trait-authz-02.txt> as an Informational RFC This document is the product of the Session Initiation Proposal Investigation Working Group. The IESG contact person is Allison Mankin. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-sipping-trait-authz-02.txt Technical Summary This document lays out a set of requirements related to trait-based authorization for the Session Initiation Protocol. While some authentication mechanisms are described in the base SIP specification, trait-based authorization provides information used to make policy decisions based on the attributes of a participant or entity in a session. This approach provides a richer framework for authorization, as well as allowing greater privacy for users of an identity system. The examples include both end-user traits and privacy usages, and also authorization and authentication uses in SIP routing. Working Group Summary The WG agreed that trait-based authentication is an important topic and that the use of authorization assertion schemes is a good way to implement it. Other WGs such as Geopriv and SIP are already looking into SAML assertions (which are an example of an authorization assertion scheme) to resolve different issues. Protocol Quality Two of the authors have supervised student implementations related to this work. Allison Mankin is the Responsible Area Director. The WG chair shepherd for the document is Gonzalo Camarillo. Note to the RFC Editor Abstract OLD: This approach provides a richer framework for authorization, as well as allow greater privacy for users of an identity system. NEW: This approach provides a richer framework for authorization, as well as allowing greater privacy for users of an identity system. [s/allow/allowing/] Section 5, Trait-Based Authorization Requirements OLD: 7. The mechanism MUST have a single baseline mandatory-to- implement authorization assertion scheme. The mechanism MUST also allow support of other assertion schemes, which would be optional to implement. One example of an assertion scheme is SAML [6]. NEW: 7. The mechanism MUST have a single baseline mandatory-to- implement authorization assertion scheme. The mechanism MUST also allow support of other assertion schemes, which would be optional to implement. One example of an assertion scheme is SAML [6] and another is RFC 3281 X.509 Attribute Certificates [7]. Please add a new Informative reference [7] to RFC 3281. _______________________________________________ IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
