Server/Site opt-in | Re: Formalizing the HTTP State Tokens proposal.

[Kari Hurtta <[e-mail]>]

> I see some issues:
> 
> - This mechanism looks to lack server opt-in, which runs into issues
>   with EU "cookie law". Specifically, it does not seem to be possible
>   to use this for any purpose without triggering disclaimer
>   requirements. Whereas there are still usecases cookies that do not
>   necressarily do so (for example, login).

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

My suggestion #2 for server opt-in (*)

( This also includes my delivery=none suggestion
  <[e-mail]>
  https://lists.w3.org/Archives/Public/ietf-http-wg/2019JanMar/0251.html
)

3.1.  HTTP State Tokens
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-3.1

"delivery" metadata is enum  of either

	  "query", "void", "none",
	  same-origin", "same-site", or "cross-site"

Initial value for "delivery" is "query".

4.1.  The 'Sec-Http-State' HTTP Header Field
https://tools.ietf.org/html/draft-west-http-state-tokens-00#section-4.1

I assume that site / server uses Sec-Http-State: request field for
indication that HTTP State Tokens are supported by browser
(and Cookie need not be generated).

Therefore  "Sec-Http-State:"  dictionary member, whose key is "token",
have value which is ether binary content (sh-binary) or token (sh-token). 

Allowed token (sh-token) values for "token" are
"query" and "void".


4.2.  The 'Sec-Http-State-Options' HTTP Header Field

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



"Sec-Http-State-Options:"  dictionary member's,  whose key is
"delivery",  allowed token (sh-token) values 
are  "void", "none", "same-origin", "same-site", or "cross-site"

( Note that "query" is missed. It is just initial value "delivery" metadata
  and can not be set by site / server .)



1) If HTTP State Token's "delivery" property have value "query",
generated request header field is
    
  Sec-HTTP-State: token=query

This indicates that browser supports HTTP State Tokens but
opt-in is needed.

2) If HTTP State Token's "delivery" property have value "void",
generated request header field is

  Sec-HTTP-State: token=void

This indicates that browser supports HTTP State Tokens but
site/server or user is opt-out for  HTTP State Tokens

Site should not longer prompt consent frum user either
(also should not set Cookies either for same reason).


3) If HTTP State Token's "delivery" property have value "none",
 Sec-HTTP-State: request header field is NOT generated.

This is for sites/origins which want minimize request size (these
sites/origins naturally also do NOT set Cooies.) These origins
proviedes static content (images, styles, javascript and so on which
do not need state).


4) If HTTP State Token's "delivery" property have value
 same-origin", "same-site", or "cross-site" then
 "value" property for HTTP State Token is generated
 (256 cryptographically random bits) and
generated request header field is

  Sec-HTTP-State: token=*(base64 encoding of "value" property)*

The 'Sec-Http-State' HTTP Header Field may also include
other dictionat memebers than "token".



If  HTTP State Token's "delivery" property have value "query",
there neeed also method for Javascript to set that
to other value. This allows site/server use Javascript based consent
from user.

( Server / Site can set this with Sec-Http-State-Options:
  response header feld. )


/ Kari Hurtta



(*) My previous suggestion was:

<[e-mail]>
https://lists.w3.org/Archives/Public/ietf-http-wg/2018JulSep/0222.html

( or perhaps not )