This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 16739 - Should the format of Session ID be more strictly defined?
Summary: Should the format of Session ID be more strictly defined?
Alias: None
Product: HTML WG
Classification: Unclassified
Component: Encrypted Media Extensions (show other bugs)
Version: unspecified
Hardware: All All
: P3 normal
Target Milestone: ---
Assignee: Mark Watson
QA Contact: HTML WG Bugzilla archive list
Depends on:
Reported: 2012-04-13 22:28 UTC by David Dorwin
Modified: 2012-12-07 01:25 UTC (History)
7 users (show)

See Also:


Description David Dorwin 2012-04-13 22:28:18 UTC
v0.1 does not give much guidance on the format of Session ID strings. [1]

Should the format of Session ID be more strictly defined or is anything other than null and "" valid? Would restricting allowed formats make application and server implementation easier?

Possible items for discussion:
 * Does the string need to represent a number? If so must it be positive, decimal/hex, etc.?
 * When may IDs be reused, if at all?
 * Must values increase or can they be random?
 * How unique must they be? Per page? Per renderer? Across the system?

Comment 1 Adrian Bateman [MSFT] 2012-08-28 21:18:34 UTC
Assigning to Mark. We should enforce greater uniqueness for systems that support key release. Mark will also investigate if any other restrictions are useful beyond key release.
Comment 2 Mark Watson 2012-09-26 16:10:48 UTC
I suggest we place no requirements on the SessionID other than that it must be unique within the browsing session (right term ?).

If proof of key release is supported we add the additional requirement that it be unique for this browser instance. This is the wrong term, but what I mean is the same thing that owns Local Storage, say. An application could then create a globally unique session Id by storing a unique 'browser instance id' in Location Storage and combining this with the session id. Anyone know the correct term ?.
Comment 3 Mark Watson 2012-10-29 16:51:16 UTC
I believe the correct terms would be "browsing context" if secure proof of key release is not supported or "origin" if it is.

Proposal: add the following text to Section 1.2.3:

"Each SessionID shall be unique within the browsing context in which it was created. If secure proof of key release is supported each Session ID shall be unique within the origin. Note that this last requirement implies that Session IDs shall be unique over time including across browsing sessions."
Comment 4 Mark Watson 2012-12-07 00:01:48 UTC