1. SIP Extensions for Network-Asserted Caller Identity and Privacy within Trusted Networks Flemming Andreasen (fandreas@cisco.com) W. Marshall, K. K. Ramakrishnan, E. Miller, G. Russell, B. Beser, M. Mannette, K. Steinbrenner, D. Oran, F. Andreasen, J. Pickens, P. Lalwaney, J. Fellows, D. Evans, K. Kelly, M. Watson IETF - March 2002

2. Draft Status Lots of list discussion and off-line comments Currently in WG Last Call

3. Overview of Changes Applicability Statement about appropriate use –Within administrative domain or cooperating domains –Draft is for network-asserted identity, not user-asserted Anonymity header removed –Issue of IP address privacy still described, but no solution offered (general service invocation issue) Extensions must be documented in an RFC and undergo designated expert review Grammar fixes and 2543bis alignment Various editorial changes

4. Open Issue #1 Proxy handling of a Remote-Party-ID received from untrusted entity (proxy or UA) –Option 1 If verifiable, set “screen=yes” If not verifiable, set “screen=no” –Option 2 Always remove untrusted Remote-Party-ID If identity can be determined, add new Remote-Party-ID with identity information –Option 1 more general than option 2 Option 1 allows unsupported identity types to be passed while still supporting the general privacy handling functions Option 2 assumes that an untrusted Remote-Party-ID is always useless. Option 1 lets the user decide –Recommendation:Option 1

5. Open Issue #2 Explicitly indicate the party type (rpi-pty-type) or infer from message –Option 1 Explicit “calling” and “called” party types –Option 2 Always infer from message, i.e. “calling” in request and “called” in response Deprecate rpi-pty-type –Option 1 more general than option 2 Allows “calling” and “called” in other messages than requests and response respectively (European requirement (?)) Allows for other types of party information in the future (related extensibility issue) –Recommendation:Option 1

6. Open Issue #3 Types of Identity Information (rpi-id-type) –Option 1 User, Subscriber, and Terminal –Option 2 User only (inferred) Deprecate rpi-id-type –Option 1 more general than option 2 Allows different types of identity information to be conveyed which could be important for some network based services Allows for other types of identity information in the future (related extensibility issue) –Recommendation:Option 1

7. Open Issue #4 Define “privacy” parameter as a general URI parameter or restrict to Remote-Party-ID –Option 1 Let “privacy” parameter apply only to Remote-Party-ID. –Option 2 Let “privacy” parameter be a general URI parameter –Option 2 more general than option 1 Not clear why the UA couldn’t just make other URIs “private” to begin with Significant draft change –More discussion needed

8. Open Issue #5 Extensibility of rpi-pty-type and rpi-id-type –Option 1 Make them extensible Require RFC and designated expert review –Option 2 Do not make them extensible –Option 1 more general than option 2 Enables use of existing privacy mechanism for new types of party and identity information in the future Potential for abuse, however the required designated expert review can prevent this –Recommendation:Option 1

9. Open Issue #6 Names of rpi-pty-types –Currently “calling” and “called”, however somewhat misleading –Alternative suggestions welcome

10. Open Issue #7 Cryptographically random identifier in From header field –Leftover from 2543 –No longer required given From-tag uniqueness requirement Recommendation: –Use “anonymous@localhost” instead