Re: June Interim: call for topics

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