Re: June Interim: call for topics

[Mark Nottingham <[e-mail]>]

Hi Rafal,

First, I'll address your question about presenting in the meeting. Generally -- and especially for cookie modifications -- we like to see on-list interest before devoting meeting time to a topic.  In the IETF, mailing lists are the primary mechanism for discussion, not meetings. So please continue to discuss this on the list; if we get to a point where meeting time is necessary to make progress, we'll schedule it.
 
Now, regarding your proposal -- As I understand it, you want to authenticate users on the server side in a way that's limited to a per-top level browsing context (e.g., window or tab). Cookies are not adequate for that purpose because servers can't distinguish cookies from two different browsing contexts in the same browser. HTML session state isn't adequate because it can't modify requests to the server (unless it does so by modifying the URL, which is clunky and arguably unreasonable).

Is that about right?

If so, I can see why you're proposing a change to cookies. However, be aware that cookies are a very widely-deployed technology with significant impact on privacy, security, and interoperability. The only way to make a change to them is to convince implementers (primarily, browsers) that the use case is so compelling that it overcomes the risks and costs of implementing it. Furthermore, to make it interoperable, you need to convince all of the browser engines to do so, and to use it, you need to wait until enough users update to the browser versions that implement it (an aspect that's more tricky because you seem to want to rely on support for a new feature to deliver some security properties that are important to you). 

In other words, it's not impossible to introduce a change like this, but it's not easy, at all. As Dan points out, you're going to need to convince people. I'd suggest that you focus on stating the requirements that you have as clearly as possible, establishing that those requirements are shared by others, and showing that they can't be met by existing approaches. The exact specification text doesn't matter very much at this stage (and may actually distract from the core issues you want to address).

This topic is suitable for this mailing list, but if there isn't more interest demonstrated here (and folks, please chime in if you have thoughts!), you might try posting about what you're trying to do on the WICG Discourse.[1] That venue is watched by a number of folks who work for browsers across the stack, and their input might help refine your proposal.

Cheers,


P.S. Did you look at using a ServiceWorker to add authentication credentials to requests, based upon the client.id of the FetchEvent? I haven't tried this, but it looks like it might be a fruitful direction, if I understand your use case correctly.

1. https://discourse.wicg.io



> On 4 Jun 2021, at 3:37 am, Rafal Pietrak <[e-mail]> wrote:
> 
> Hello Daniel and Everybody,
> 
> W dniu 21.05.2021 o 23:36, Daniel Veditz pisze:
>> On Fri, May 21, 2021 at 8:03 AM Rafal Pietrak <[e-mail]
>> <mailto:[e-mail]>> wrote:
>> 
>>    If possible, I'd appreciate a couple of minutes for my cookies radius
>>    proposal
>>    (https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/
>>    <https://datatracker.ietf.org/doc/draft-pietrak-cookie-scope/>)
>> 
>> 
>> Mark's answer[1] to another recent cookie proposal applies here too. For
> 
> I think, I've followed those guidelines from the very beginning:
> 1. I've drafted my proposal
> 2. I've tried to get WG attention on this list.
> 
> Should there be anything else for me to do, pls advise.
> 
>> now the group is only considering cookie proposals as part of
>> RFC6265bis. This is on the agenda for this meeting but your proposal
>> does not yet have the support to be incorporated into it.
> 
> OK.
> 
> Although I'm responding so late, because I've tried to work my way out
> into the RFC6265bis, but that proved to be more difficult then I've
> initially expected, and while I haven't received much response to my
> proposal, I started to feel, that even if my proposal gets through into
> the RFC6265bis, It'll be in an entirely different form, that I currently
> imagine. So the work of merging my draft into RFC6265bis would be a
> complete waste.
> 
> For the time being I'd rather assume, that discussion around words in my
> draft-01 could be more up-to-the-point, then discussion if-where-how to
> incorporate it within RFC6265bis.
> 
> So, I'd appreciate if I could have a couple of minutes during the June
> meeting for cookie-radius presentation.
> 
> [-----------]
>> This IS the group for the topic, and anywhere else you try is likely to
>> bounce you back here. What you really need to do is drum up support for
>> this. Are there web sites that want to use this functionality enough to
>> change their code to use it? Are there client implementers fired up to
>> support Radius (browsers of course, but more than just browsers)? Is
>> there only support for part of it, and if so could that be solved in a
>> different way?
> 
> Different way? NO.
> 
> I tried all other approaches, may be I miss knowledge and imagination,
> but I couldn't find any way joggling HTTP/cookies/Local/session-store,
> that could possibly substitute security token as-part-of-URL ... keeping
> the functionality of URL: different TAB -> differet URL.
> 
> If there is any, I'll be happy to walk away with it and forget the
> "readius".
> 
>> 
>> My own prejudice is that I would never want "World" because I don't
>> trust sharing my cookies with all those other unknown apps. The
>> distinction between Tabs and Windows is lost on me because in at least
>> some browsers you can drag tabs or groups of tabs from window to window.
>> "Viewport" as a stricter definition of how "session" is often
>> interpreted by browsers might be interesting, and better backwards
>> compatibility than simply redefining/clarifying the meaning of a session
>> cookie.  For some uses, like banks, the existing clear-site-data feature
>> might be good enough, so you'll need to sell folks on why it isn't.
> 
> I can elaborate, But basically my design follows this basic principle
> line of logic:
> 1. a change is NECESARY -> current cookies (or any other auth mechanism)
> don't provide URL-like separation of security contexts between separate
> viewports.
> 2. So. The proposal does introduce that, keeping the definition as
> minimal as possible to provide required missing functionality
> 3. then I turn back, and check is by just a little extra that definition
> could provide more functionality (at close to none cost, like cost of
> 3-5 extra words to recognise)
> 4. if so, I put that extra into the design.
> 
> This is where "world" and "tabs" originated. The targeted functionality
> does not need them, but I wouldn't bet if those COULD be liked by other
> web designers. And those may come at no extra implementation cost.
> 
> To make it work, one must make sure, that those "extra" keywords are
> well defined. I  have made an effort to define them well, but It's
> possible I failed there. Still, I think it's worth spending time on
> making them defined "perfectly". But, should that couldn't be done, let
> them go away. They don't matter for the goal at hand.
> 
> If I was to make a hasty  "fine tuning" of my definitions here, I'd say:
> 1. "world" is basically for web-designers, that "want-to-grab-them-all"
> - meaning, no matter where user turns, he/she'll always returns those
> same cookies to the server - designers "may" like that. I'm not a judge
> here, I wouldn't need it, but I can foresee others would.
> 2. "tab" cookie is possibly ill-defined. I admit. It should probably be
> scratched at this point. I thought: when there is an "object", there
> should be a "token/distinction" for it. But you're probably right. There
> is no imaginable value in distinguishing windows from tabs.
> 
> So: would it be possible for me to have a quick (5min?) presentation of
> the cookie-radius proposal during the June meeting? (Cc: to Mark
> Nottingham, is to address this question to the chair of the group
> formally - I'm new here, and don't really know my way around, pls
> forgive if that's not appropriate)
> 
> Naturally, should there be anything I could improve in my draft, I'll be
> happy to pick up from discussion here on the list, before the meeting.
> 
> -R

--
Mark Nottingham   https://www.mnot.net/