Re: [sipcore] Understanding Privacy: history invoked by UAS

[Paul Kyzivat <[e-mail]>]

Inline

On 11/10/2010 11:50 AM, Shida Schubert wrote:
>
>   I think RFC4244 was quite vague about how privacy is
> requested and due to that, both privacy header outside
> H-I header or part of hi-entry are used without any clear
> distinction.
>
>   Thus for backward compatibility, I don't think we can
> eliminate the use of Privacy:history, I think we can definitely
> clarify the use of them by saying proxy SHOULD or MUST
> use privacy=header and UAC uses Privacy:history.
>
>   I do think we should clarify the procedure of how history-info
> is anonymized, may be something along the line as follows.

What you outline here is a great improvement.

> 1. Setting privacy indication.
>
>   UAC sets privacy by setting privacy:header or privacy:history
>   Proxy/UAS sets privacy by setting privacy=history in hi-entry
>
> 2. Applying privacy to request.
>
>   Privacy service at the boundary of domain checks if privacy:header
> or privacy:history exists.
>
>   If privacy:history or privacy:header exists then it anonymize all the
> hi-entry from its responsible domain by changing the hi-target-to-uri
> to URI with anonymous.invalid.
>
>   If the hi-entry that is a target of anonymization and has privacy=history,
> it will remove the privacy=history after anonymizing the hi-entry.
>
>   If the hi-entry is already anonymized (URI with anonymous.invalid) it
> will leave the entry as is.
>
>   After anonymizing all the hi-entry from its responsible domain it will
> remove the priv-value of "history" from Privacy header (real header).
>
>   If there are no priv-value remaining in the Privacy header then it will
> remove the Privacy header itself following the procedure in RFC3323.
>
>   If there is no priv-value of "history" or "header", privacy service
> looks through hi-entries and see if there are URI from its domain
> with privacy=history.
>
>   For each hi-entry with privacy=history, privacy service will anonymize
> the hi-target-to-uri and remove the privacy=history after anonymizing
> the hi-entry.
>
> 3. Privacy:none
>
>   With regards to privacy:none, it's tad tricky because
> as Ian said, how it's honored depends on the regulation etc.

ISTM that privacy:none is pretty explicit about how it is to be 
implemented. Either you comply or you don't. If you feel that allowing 
the request to proceed while complying with privacy:none is contrary to 
your policy, then you have the option of failing the call, and just be 
up front with your users that you don't permit them to use privacy:none. 
Then they can decide if they still want to do business with you.

	Thanks,
	Paul

>   Regards
>    Shida
>
> On Nov 10, 2010, at 10:30 AM, Elwell, John wrote:
>
>> In which case we don't need Privacy: history in the response, since it is only a partial solution?
>>
>> John
>>
>>> -----Original Message-----
>>> From: Shida Schubert [mailto:[e-mail]]
>>> Sent: 09 November 2010 06:24
>>> To: Elwell, John
>>> Cc: [e-mail]
>>> Subject: Re: [sipcore] Understanding Privacy: history invoked by UAS
>>>
>>>
>>> Hi John;
>>>
>>> In practice, if C cares about its privacy, there should be
>>> a priori arrangement with the service provider or
>>> configuration in proxy to withhold its identity.
>>>
>>> This will allow the proxy sending the 4xx which sets the hi-entry
>>> to ensure privacy is applied by setting escaped privacy header
>>> or Privacy:header.
>>>
>>> Regards
>>>   Shida
>>>
>>> On Nov 9, 2010, at 11:32 AM, Elwell, John wrote:
>>>
>>>> Suppose a request from A is targeted initially at B, this
>>> is mapped to C, and then to registered contact D. The UAS (D)
>>> puts Privacy: history in the response, and therefore prevents
>>> A learning about C and D. Fine.
>>>>
>>>> Now, supposing D is not registered at the time, i.e., there
>>> is no registered contact for C. This results in a 4xx
>>> response to A. How do we ensure that the identity of C is not
>>> disclosed to A, in line with what is achieved when D is registered?
>>>>
>>>> John
>>>>
>>>> _______________________________________________
>>>> sipcore mailing list
>>>> [e-mail]
>>>> https://www.ietf.org/mailman/listinfo/sipcore
>>>
>>>
>
> _______________________________________________
> sipcore mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/sipcore
>