Re: Proposal for new header field: SESSION_FORWARD_IDENTITY

In broad sense that have some similarities with

Sec-Http-State -header field proposal:

  Formalizing the HTTP State Tokens proposal.
  https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0249.html

  https://tools.ietf.org/html/draft-west-http-state-tokens-00

Except that token for Sec-Http-State -header field is generated by browser
so that web site can not store retrievable data, but it is not that 
ephemeral (default max-age is 3600 second (1 hour) and there is some kind
Token Storage). And HTTP State Token is not accessible from scripts.

Yes, when there is no local storage for  session_forward_identity,
cookie laws do not apply (at least if it is ephemeral (up to some hours)).

For Sec-Http-State that was questioned

   https://lists.w3.org/Archives/Public/ietf-http-wg/2019AprJun/0006.html

However if it is used for just for login sessions, opt-in is not required.
Also opt-in is not required for similar cookies.

I'm using http://ec.europa.eu/ipg/basics/legal/cookies/index_en.htm
here for reference

----------------------------------- start quote ---
 EU legislation on cookies

EUROPA websites must follow the Commission's guidelines on privacy and
data protection and inform users that cookies are not being used to
gather information unnecessarily.

The ePrivacy directive – more specifically Article 5(3) – requires
prior informed consent for storage or for access to information stored
on a user's terminal equipment. In other words, you must ask users if
they agree to most cookies and similar technologies (e.g. web beacons,
Flash cookies, etc.) before the site starts to use them.

For consent to be valid, it must be informed, specific, freely given
and must constitute a real indication of the individual's wishes.

However, some cookies are exempt from this requirement. Consent is not required if the cookie is:

‣    used for the sole purpose of carrying out the transmission of a communication, and

‣    strictly necessary in order for the provider of an information society service explicitly
     required by the user to provide that service.

Cookies clearly exempt from consent according to the EU advisory body on data protection- WP29pdf include:

‣    user‑input cookies (session-id) such as first‑party cookies to keep track of the user's input
     when filling online forms, shopping carts, etc., for the duration of a session or persistent
     cookies limited to a few hours in some cases
‣    authentication cookies, to identify the user once he has logged in, for the duration of a session
‣    user‑centric security cookies, used to detect authentication abuses, for a limited persistent duration
‣    multimedia content player cookies, used to store technical data to play back video or audio
     content, for the duration of a session
‣    load‑balancing cookies, for the duration of session
‣    user‑interface customisation cookies such as language or font preferences, for the duration
     of a session (or slightly longer)
‣    third‑party social plug‑in content‑sharing cookies, for logged‑in members of a social network.
----------------------------------- end quote ---




You mentioned that you implemented session_forward_identity header field.
That is with service workers, I guess ?

Have you intend to register session_forward_identity header field
or what ?

/ Kari Hurtta

> ---------- Forwarded message ---------
> From: Wesley Oliver <wesley.olis@gmail.com>
> Date: Sun, May 12, 2019 at 7:51 PM
> Subject: Proposal for new header field: SESSION_FORWARD_IDENTITY
> To: ietf-http-wg@w3.org Group <ietf-http-wg@w3.org>
> 
> 
> Hi all,
> 
> I am sure by now the the EU with there new cookie laws has drive everyone nuts already and annoyed them enough!
> 
> I would like to propose that for session tracker that we implemented a new session_forward_identitiy field header, in which the server will supply the value in the http response and the client browser will then for all further request to the server append the session_forward_dentitiy field header for that domain.
> 
> Similar to cookies, but there is no local storage of anything, its a pure ephemeral value and is basically lost, when one navigates away from the domain, it is lost. 
> 
> Basically like adding the tracking token onto the end of every url request made from your
> website/app, client browser request, which requires each url to be dynamic generated, which in most web apps is not a problem. But for simple reporting type pages that are tobe kept simple, then allowing the browser automatically do this for you in the background simplifiers things.
> 
> Hopefully this would reduce the amount of cookie type EU regulations we need to accept before entering a website, were by they can rather use other alternative forms that are potentially less subject to tracking a user outside the scope of the current domain requirements.
> 
> We might need to typically add another public accessible header variant version for google analytics and similar things, for personal web domains, which is more public to linking session information, but not out of the domain context, this could become difficult for 3rd party scripts that are loading into an application, that may look for this then send back to there server. But they would have to continually send information for each page back to there server, as they would n't be allowed to use any form of local storage, except for maybe single access once off granted access, similar to how mobile permissions handle things, to get long term webapp session key from local storage.
> 
> Just think that there is a simper way to get around all these EU cookies notifications
> and achieves what we require with looking to a future method, that suits 21st century http requirements.
> 
> Kind Regards,
> 
> Wesley Oliver
> -- 
> Web Site that I have developed:
> http://www.swimdynamics.co.za
> 
> 
> Skype: wezley_oliver
> MSN messenger: wesley.olis@gmail.com
> 
> 
> -- 
> -- 
> Web Site that I have developed:
> http://www.swimdynamics.co.za
> 
> 
> Skype: wezley_oliver
> MSN messenger: wesley.olis@gmail.com
> 
> ------------------

Received on Saturday, 25 May 2019 06:03:11 UTC