Re: June Interim: call for topics
Rafal Pietrak <cookie.rp@ztk-rp.eu> Thu, 03 June 2021 17:45 UTC
Return-Path: <ietf-http-wg-request+bounce-httpbisa-archive-bis2juki=lists.ie@listhub.w3.org>
X-Original-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Delivered-To: ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A51403A1137 for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 3 Jun 2021 10:45:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -7.45
X-Spam-Level:
X-Spam-Status: No, score=-7.45 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_INVALID=0.1, DKIM_SIGNED=0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H4=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=fail (1024-bit key) reason="fail (message has been altered)" header.d=ztk-rp.eu
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id dyMqfi2gPffc for <ietfarch-httpbisa-archive-bis2Juki@ietfa.amsl.com>; Thu, 3 Jun 2021 10:45:43 -0700 (PDT)
Received: from lyra.w3.org (lyra.w3.org [128.30.52.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 61EDB3A1132 for <httpbisa-archive-bis2Juki@lists.ietf.org>; Thu, 3 Jun 2021 10:45:42 -0700 (PDT)
Received: from lists by lyra.w3.org with local (Exim 4.92) (envelope-from <ietf-http-wg-request@listhub.w3.org>) id 1lorKa-0008Sz-Vq for ietf-http-wg-dist@listhub.w3.org; Thu, 03 Jun 2021 17:40:45 +0000
Resent-Date: Thu, 03 Jun 2021 17:40:32 +0000
Resent-Message-Id: <E1lorKa-0008Sz-Vq@lyra.w3.org>
Received: from titan.w3.org ([128.30.52.76]) by lyra.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <cookie.rp@ztk-rp.eu>) id 1lorHy-0007UX-2m for ietf-http-wg@listhub.w3.org; Thu, 03 Jun 2021 17:37:59 +0000
Received: from hax2-04.wsisiz.edu.pl ([213.135.44.188] helo=zorro.ztk-rp.eu) by titan.w3.org with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <cookie.rp@ztk-rp.eu>) id 1lorHo-0000wq-En for ietf-http-wg@w3.org; Thu, 03 Jun 2021 17:37:45 +0000
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=ztk-rp.eu; s=2024; h=Subject:Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Sender:Reply-To:Content-ID :Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To: Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe:List-Subscribe :List-Post:List-Owner:List-Archive; bh=q8uob3SVjQxNZhrflp1wBgpB7u52+7Kx+yvJ7OzaiNE=; b=GlZx4jWif8bd3Dcg629Cg454iz Xa0Y1PtP1naLXNhSk4fFBAjD+tcCzJ1d+o17NnB9iQkpyZxq78S0zf+fo7BC3JLxmZiqlDm00cfQs HCQq72WnVPP3Dpqtv9Zkzb672BUkaQV2640y8YGCbWpEj3UJZbJzSpD4jsTP3Mu8WdoI=;
Received: from public-gprs414592.centertel.pl ([37.47.250.193]:3044 helo=[192.168.43.32]) by zorro.ztk-rp.eu with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (Exim 4.94.2) (envelope-from <cookie.rp@ztk-rp.eu>) id 1lorHO-00FIHl-QR; Thu, 03 Jun 2021 19:37:19 +0200
To: Daniel Veditz <dveditz@mozilla.com>, Mark Nottingham <mnot@mnot.net>
Cc: HTTP Working Group <ietf-http-wg@w3.org>
References: <D3DECA17-1574-4EC7-8B21-97F2EB042276@mnot.net> <082f23bc-ea78-2f95-4c78-4f9f88d6c47d@ztk-rp.eu> <CADYDTCAnCsQeP+8umkqTQCVqa3NhJ5+4QPZMffGWPXrF7_FB4A@mail.gmail.com>
From: Rafal Pietrak <cookie.rp@ztk-rp.eu>
Message-ID: <3cdc71e9-70a1-1ca9-39f3-9319c1ae291f@ztk-rp.eu>
Date: Thu, 03 Jun 2021 19:37:11 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.10.0
MIME-Version: 1.0
In-Reply-To: <CADYDTCAnCsQeP+8umkqTQCVqa3NhJ5+4QPZMffGWPXrF7_FB4A@mail.gmail.com>
Content-Type: text/plain; charset="utf-8"
Content-Language: en-US
Content-Transfer-Encoding: 8bit
X-SA-Exim-Connect-IP: 37.47.250.193
X-SA-Exim-Mail-From: cookie.rp@ztk-rp.eu
X-SA-Exim-Version: 4.2.1 (built Sat, 13 Feb 2021 17:57:42 +0000)
X-SA-Exim-Scanned: Yes (on zorro.ztk-rp.eu)
Received-SPF: pass client-ip=213.135.44.188; envelope-from=cookie.rp@ztk-rp.eu; helo=zorro.ztk-rp.eu
X-W3C-Hub-DKIM-Status: validation passed: (address=cookie.rp@ztk-rp.eu domain=ztk-rp.eu), signature is good
X-W3C-Hub-Spam-Status: No, score=-4.7
X-W3C-Hub-Spam-Report: BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, NICE_REPLY_A=-0.603, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: titan.w3.org 1lorHo-0000wq-En 8657b13086aecb25f46689711f1ebc61
X-Original-To: ietf-http-wg@w3.org
Subject: Re: June Interim: call for topics
Archived-At: <https://www.w3.org/mid/3cdc71e9-70a1-1ca9-39f3-9319c1ae291f@ztk-rp.eu>
Resent-From: ietf-http-wg@w3.org
X-Mailing-List: <ietf-http-wg@w3.org> archive/latest/38848
X-Loop: ietf-http-wg@w3.org
Resent-Sender: ietf-http-wg-request@w3.org
Precedence: list
List-Id: <ietf-http-wg.w3.org>
List-Help: <https://www.w3.org/Mail/>
List-Post: <mailto:ietf-http-wg@w3.org>
List-Unsubscribe: <mailto:ietf-http-wg-request@w3.org?subject=unsubscribe>
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
- June Interim: call for topics Mark Nottingham
- Re: June Interim: call for topics Erik Nygren
- Re: June Interim: call for topics Mark Nottingham
- Re: June Interim: call for topics Meiling Chen
- Re: June Interim: call for topics Rafal Pietrak
- Re: June Interim: call for topics Daniel Veditz
- Re: June Interim: call for topics W. Felix Handte
- Re: June Interim: call for topics Tommy Pauly
- draft-handte-httpbis-dict-sec Mark Nottingham
- Re: June Interim: call for topics Rafal Pietrak
- Re: June Interim: call for topics Mark Nottingham
- Re: Re: June Interim: call for topics Meiling Chen
- Re: June Interim: call for topics Rafal Pietrak