Re: WWW-Authenticate proposal: timeout flag

One thing that jumped out at me was the Viewport visibility overriding the
specified Domain. Don't do that! Either make setting a too-broad domain an
error and reject the cookie (as we did with __Host- prefixed cookies), or
accept that the server knows what it's doing and honor the domain. If, as a
web author, you restrict cookies to a viewport you still might have all
kinds of sub-resource requests from sibling origins in the same domain. Why
break that?

It's the "Secure" attribute, not "SecureOnly"

4 different visibility levels sounds like a PITA to implement, or even
define. If a site is using "Tabs" visibility and they do a
window.open(<same-origin>), does it have the same cookies or not? That used
to be a popup, so new window == no cookies. In the last decade or so
browsers (only one kind of user agent) have converged on having that be a
new tab in the same window (has cookies). If the author specifies size
attributes then it's back to a separate window (no cookies). But that's not
part of the HTML specifications, it's just conventions that User Agents
have adopted. It would be better to define a cookie spec based on concepts
that are specified somewhere and aren't just conventions. You need to come
up with some compelling reasons for why each of the levels is necessary and
when it would be useful.

Please restrict this to "session" cookies (no set expiration time). I don't
know how I'd store a "Viewport" cookie (on disk, between browser runs if it
has a long expiration) that makes sense after you close that one viewport.
Or tab, or window.

Would your use-cases be served by the HTML "sessionStorage" feature? It's
not sent in HTTP requests so it's definitely not the same, but that is
explicitly scoped to the current document and not shared with other
documents of the same origin (similar to your Viewport, but excludes
same-origin frames).

-Dan Veditz

On Fri, Apr 30, 2021 at 4:37 AM Rafal Pietrak <cookie.rp@ztk-rp.eu> wrote:

> Hi everyone,
>
> W dniu 29.04.2021 o 22:50, Soni L. pisze:
> >
> >
> > On 2021-04-29 5:42 p.m., Daniel Stenberg wrote:
> >> On Thu, 29 Apr 2021, Soni L. wrote:
> >>
> >>> We'd like to be able to specify a timeout value for WWW-Authenticate,
> >>> in particular `timeout=0` so the HTTP authentication can be converted
> >>> into session cookies rather than sending the password in plaintext
> >>> (sure, it gets sent over TLS, but that doesn't matter) on every
> >>> request. Would anyone be interested in such proposal?
> >>
> >> What should happen when the time runs out? Is that just an ask to the
> >> client that it should drop the auth status at that point?
> >>
> >> I don't think this is enough to make people stop using cookies for
> >> logged in session status even if you would get someone to adopt.
> >>
> >
> > It's to stop using forms, not cookies. Cookies are more secure because
> > they don't keep re-sending the password such that a malicious or
> > compromised server could exfiltrate the plaintext. Using cookies for
> > logged in session status is a good thing.
> >
>
> Still, cookies have their problems.
>
> Would somebody be so kind and have a look at my proposal regarding
> cookies at: https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/
>
> ... and naturally give it a comment or two :)
>
> Best regards,
>
> -R
> --
> Rafał Pietrak
>
>