Re: [Insipid] Alissa Cooper's Discuss on draft-ietf-insipid-session-id-26: (with DISCUSS and COMMENT)

["Ben Campbell" <[e-mail]>]

On 16 Aug 2016, at 21:20, Paul Giralt (pgiralt) wrote:

[...]

> == Section 12 ==
>>
>> "This document allows for additional parameters (generic-param) to be
>>   included in the Session-ID header.  This is done to allow for 
>> future
>>   extensions while preserving backward compatibility with this
>>   document.  To protect privacy, the data for any generic-param
>>   included in the Session-ID header value MUST NOT include any user 
>> or
>>   device information."
>>
>> To preserve the privacy properties of the session identifier, I think
>> this prohibition needs to extend further -- not just to any user or
>> device information, but to any identifier that persists beyond the
>> current session. Otherwise some parameter defined in the future could
>> easily be used to correlate sessions, while the identifier is 
>> currently
>> specified so as to avoid that.
>>
>
>
>
> I agree with your assessment, however I think the restriction has to 
> be carefully worded because I think the ability to correlate sessions 
> in some meaningful way could be something a future extension might 
> want to do. For example, in an omni-channel contact center 
> environment, we might want to be able to correlate the different 
> channels of communications by including some other identifier (which 
> would have to adhere to the privacy restrictions put in place here). 
> Another potential use would be to include something like a “Related 
> Session-ID” when two sessions are merged together in a way that is 
> not addressed by this specification and it is desirable to include 
> information to link the two sessions together.
>
> I think your concern is more around temporal correlation where two 
> unrelated sessions from the same user could be somehow be associated 
> with each other. If I’m understanding the concern correctly, I can 
> add some verbiage to address this concern without completely 
> eliminating the possibility of a future version having the ability to 
> somehow correlate related sessions that cannot be correlated with the 
> specification as it stands.

I don't object to this path forward, but I think we will need to be 
careful that the future use cases we enable do not become the exact 
persistent correlation issue that Alissa was concerned about. Is the 
potential  not already covered by the rather expansive definition of a 
"communication session"?

[...]

Thanks!

Ben.