Subject: FW: [SIP] I-D ACTION:draft-ietf-sip-privacy-00.txt

From: "Mark Watson" <[email-masked]>
Date: Fri, 22 Dec 2000 11:36:06 -0000

All,

I notice this draft was discussed at the IETF and it was noted that not many
comments had been received. Hopefully I can address that :-)

I would like to propose some enhancements to the draft. As it stands it is
deficient in a number of aspects. I would propose:
1) to provide full support for European regulatory requirements (which are
doubtless duplicated in other markets) relating to Caller Identity
2) to include identity information relating to multiple types of party
involved in the session
3) to include multiple types of identity information about each party
4) to make privacy handling more generic
5) to include location information

If there are a significant number of people interested in discussing such
enhancements, I would be happy to set up an off-line discussion group, or we
can have discussions on the main list - I would look to the WG chairs for
guidance on this.

[[Unfortunately, I won't be able to answer comments on my comments until
15th Jan, as I will be on vacation]]

More details are below:

1) Regulatory requirements

European Data Protection regulations, and I suspect similar regulations in
other markets, place strict controls on what can/cannot be done with users
personal information (e.g. their identity) with/without their permission.

This gives rise to a requirement to signal whether or not a user has given
permission for their identity information to be disclosed to third parties.

Further, though, there may be cases where the user's information cannot be
divulged to a third party, but where the user has NOT explicitly asked for
it to be witheld, for example where the users wishes cannot be ascertained.
There is therefore a need for three classifications with regard to privacy:
a) Information may be disclosed because the user has consented to this
b) Information may not be disclosed because the user has requested
non-disclosure
c) Information may not be disclosed for reasons other than user request

The third category is, of course, something of a 'catch-all' to cover all
cases except the explicit user request case.

An example of where this level of discrimination is required is the
Anonymous Caller Rejection service which is required (by explicit European
regulation) to reject those calls where the *caller has requested* that they
remain anonymous. A distinction is required between cases where anonymity is
due to explicit caller request and those where it is due to some other
reason.

2)Types of Party

There are many types of party that could be involved in a call/session. We
should be capable of providing information about any/all of them. Support
for the following types is suggested as a starting point
i) Calling Party
ii) Called Party (whose terminal is alerting)
iii) Connected party (who answers the call)
iv) Redirecting Party
v) Redirected-to Party

3) Types of identity

A party involved in a session may have several kinds of identity. Support
should be provided for signalling any/all of them:

i) Subscriber identity - who owns the network subscription under which the
session is being established
ii) User identity
iii) Display/Alias identity - the identity that the party wishes to be known
as
iv) Contact identity - the identity to be used to contact the party (e.g. to
establish a return call/session)
v) Terminal identity

In many partical scenarios one or all of these identities are in fact the
same and the same as the User identity, and so all do not need to be
signalled separately. In any given application scenario it should be
specified what these identities refer to.

4) Handling of privacy requirements

Privacy requirements are generaly driven by Data Protection legislation -
this is certainly the case here in Europe and I expect in other markets.

The requirement is generally that personal information of any party should
not be disclosed to other parties without permission. Where permission has
been witheld, the requirement can often be met simply by omitting the
information in question from any signalling messages. However, sometimes
this information is required by entities within Service Provider Networks
and so must still be included in messages to these entities, but not in
messages to users.

The privacy requirement is therefore particular to each piece of Party
Information and should be signalled as a parameter to each piece of
information. It should be noted that hiding the calling users IP address
used for the RTP stream is a service in itself, not just the non-disclosure
of personal information.

A simple Internet Telephony service cannot, by definition, operate without
disclosing this address, so a user who requires this address to be kept
secret is effectively electing not to use this simple service.

A more advanced service which hides the IP address by routing the RTP stream
via an anonymiser would be required, but to my mind this is a separate
service in itself and need not be addresses with these privacy requirements.

5) Location Information

A further type of Party information is the physical location of the Party.
This is useful for calls to emergency service centers and for geographic
routing services.

Proposal
--------

I suggest replacing Remote-Party-ID and Anonymity with a single header,
which may be repeated, as follows:

Party-id = "Party-ID" ":" party-type party-id-type [display-name] 
		 ["<" addr-spec ">"] *(";" pi-parameter )

party-type = "cg" | "cd" | "cn" | "rdir" | "rto" | token
party-id-type = "sub" | "user" | "alias" | "contact" | "term" | token

pi-parameter = pi-validity-parm | pi-privacy-parm | pi-other-parm
pi-other-parm = token [ "=" ( token | quoted-string ) ]

pi-validity-parm = "verified" | token
pi-privacy-parm = "privacy" "=" ( "none" | "user" | "other" | token )

The values of party-type and party-id-type are as described above.

The pi-validity-parm is included by an entity which has verified the user
information to be correct, to the best of its ability. Receipt of this
parameter means that the information can be trusted to the same level as the
entity from which it was received it is trusted.

The pi-privacy-parm indicates who has requested that the information be kept
secret. If omitted, the default is 'none' - indicating that the information
need not be kept secret. If the value is anything other than 'none' the
information may not be disclosed.

Examples
--------

The identity of the calling user could be signalled as follows:

Party-ID: cg user "Watson" <sip:[email-masked]>; verified

The identify of the calling subscriber, which has been explicitly witheld by
the caller would be

Party-ID: cg sub "Watson" <sip:[email-masked]>; verified;
privacy=user

A call from an Agent at a Call Centre might include:

Party-ID: cg user "A Agent" <sip:[email-masked]>; privacy=other
Party-ID: cg sub "Window World" <sip:[email-masked]>; verified
Party-ID: cg contact "Window World" <sip:[email-masked]>

Indicating that 'Window World' wish to be contacted by their 1-800 number,
that the fact that the call did originate from Window World is vouched for
by whomever sent the message (e.g. local proxy), and that the users identity
must not be disclosed, for example because the Call Agents have no choice
about whether to release their own identity or not.

Regards,

Mark Watson
Nortel Networks
[email-masked]

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]
Sent: 13 November 2000 12:41
To: IETF-Announce
Cc: [email-masked]
Subject: [SIP] I-D ACTION:draft-ietf-sip-privacy-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts
directories.
This draft is a work item of the Session Initiation Protocol Working Group
of the IETF.

	Title		: SIP Extensions for Caller Identity and Privacy
	Author(s)	: W. Marshall et al.
	Filename	: draft-ietf-sip-privacy-00.txt
	Pages		: 16
	Date		: 10-Nov-00
	
This document describes two extensions to the Session Initiation
Protocol (SIP) [4]. The extensions allow callers and callees to
maintain their privacy in an environment where one or more proxies
serve as intermediaries which can provide the identity of the
parties either directly or indirectly. The extensions allow the
parties to be identified either by name or by type, the latter of
which can be used to identify some group of callers and callees.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-00.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-sip-privacy-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-sip-privacy-00.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

Date: Fri, 22 Dec 2000 11:36:07 -0000