Subject: [SIP] SIP Privacy Draft

From: "Mark Watson" <[email-masked]>
Date: Thu, 1 Feb 2001 15:49:24 -0000

All,

I sent some comments on this draft to the list in December. Below is an
update to these comments based on some off-line discussions. (The draft
itself is at
http://www.ietf.org/internet-drafts/draft-ietf-sip-privacy-00.txt)

Five enhancements to the draft are proposed:
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 generic
5) to include location information

The basic object is to make Remote-Party-ID a general purpose header which
can be used for any type of identity information requiring standard privacy
and authenticity handling.

More details are below. If there is support for these kind of enhancements,
I will come up with a detailed proposal.

1) Regulatory requirements

It's required in some markets to make a distinction between identity
information which the user has explicitly requested be kept secret, and
identity information which cannot be released for some other reason (usually
Data Protection). It's proposed to add this distinction by having two
'witheld' indications, one for 'user witheld' and another for 'network
witheld'.

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 and be
easily able to add more if required. 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)

Whilst these three types of party can be derived from the context (INVITE
implies (i), 1xx => (ii) and 2xx => (iii)), it would be valuable to include
an explicit indication of the party type so that new types can easily be
added in future.

For example, diversion services could use this header to indicate the
redirecting and redirecting-to parties thereby taking advantage of generic
privacy/authenticity handling (see (4) below). These other identity types
could be addressed in the appropriate I-D defining the diversion service.

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 - a human being
iii) Display/Alias identity - the identity that the party wishes to be known
as
iv) Return identity - the identity to be used to contact the party (e.g. to
establish a return call/session)
v) Terminal identity

In many practical 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

The above implies that the Remote-Party-ID header could be repeated to
specify multiple parties and multiple types of identity for each party.
Because of this the privacy handling should be on a per-Remote-Party-ID
basis - i.e. by tags in the header, not a separate Anonymity header.

Privacy handling can also be carried out by proxies without an understanding
of the party type or identity type. Basically, if the message is to be sent
to an 'untrusted' entity, private information is encrypted or removed. If it
is to be sent to a 'trusted' entity, the information is forwarded unchanged.

So, the header becomes a generic mechanism for any identity information with
privacy requirements. We can add new identity types as these become
necessary for new services, and get the privacy handling for free.

Similarly, authenticity handling can be made generic. Specifically, if
information is received from an untrusted source, the proxy marks it
'verified' or 'unverified' based on its own ability to verify the
information. If information is received from a trusted source, the
verification markings are left unchanged.

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. There is apparantly a URL format for geographic location,
so this could be used for this purpose.

Regards,

Mark Watson
Nortel Networks
[email-masked]

---

From: Flemming Andreasen <[email-masked]>
Date: Thu, 01 Feb 2001 22:05:46 -0500

Mark Watson wrote:

<snip>

> specify multiple parties and multiple types of identity for each
> party. Because of this the privacy handling should be on a
> per-Remote-Party-ID basis - i.e. by tags in the header, not a separate
> Anonymity header.

Just to clarify, we still need the Anonymity header for the IP-address
privacy case.

-- Flemming

--
Flemming Andreasen
Cisco Systems

---

From: Jiri Kuthan <[email-masked]>
Date: Sat, 03 Feb 2001 22:48:30 +0100

> Mark Watson wrote:
[...]
> 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. There is apparantly a URL format for geographic location, so this could be used for this purpose.

Where is the URL format specified?

I agree that URL is a good place to accomodate geographical location and it
would be useful to have a standardized notation. draft-daviel-http-geo-header-02.txt
specifies header fields for conveying location in HTTP. However as the position 
identifies services and may be used with more protocols than just HTTP I would 
prefer conveying it in URLs.

Henning's 911 draft also addresses many of related issues. 

Is there interest in going ahead with such URLs?

Jiri

------------
P.S. It seems to me there are some geo-service points on which some folks 
like to disagree. Let me give a couple of more details from my perspective 
so that we can save a couple of RTTs if there is interest in discussing this.
- URL format for conveying geo-info is a URL format and nothing else. There 
  are three orthogonal jobs: 1) determining geo-info, 2) finding a server 
  providing location-base services and 3) conveying the geo-info to it. 
  Geo-info in URLs would make only the third job. 
- The geo-info may be gained from anywhere: access providers, from GPS provider, 
  typed-in by sextant-equipped user, from IPv6 address, etc. It does not have to 
  indicate your current position; for example, when planning a trip a travelling 
  agent may want to get connected to a hotel nearby his client's destination.
- Both end-devices and proxies (if they know it) may insert geo-info. The latter
  case may be subject to privacy issues -- users may not be always happy to 
  disseminate geo-info.  
- No limitations are put on how to find location-based services. They may be
  located at an outbound proxy discovered automatically using DHCP but they
  may be at Jeff's pizza server advertised in newspaper as well.
- No assumptions are made about what the services are; it is service providers'
  discretion to implement "conntact a Pizza Inc. rep in caller's proximity", 
  "notify my parents whenever I move", "emergency", etc.

_______________________________________________
This list is for continuing development of the SIP protocol.
The sip-implementer's list is the place to discuss implementation,
and to receive advice on understanding existing sip.
To subscribe to it, send mail to [email-masked] with
"subscribe sip-implementors" in the body.