- From: Rafal Pietrak <cookie.rp@ztk-rp.eu>
- Date: Thu, 3 Jun 2021 19:37:11 +0200
- To: Daniel Veditz <dveditz@mozilla.com>, Mark Nottingham <mnot@mnot.net>
- Cc: HTTP Working Group <ietf-http-wg@w3.org>
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 <cookie.rp@ztk-rp.eu > <mailto:cookie.rp@ztk-rp.eu>> 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
Received on Thursday, 3 June 2021 17:38:36 UTC