RE: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06

Paolo Argentieri <> Tue, 08 September 2020 01:01 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4F0223A0818 for <>; Mon, 7 Sep 2020 18:01:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.749
X-Spam-Status: No, score=-2.749 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HEADER_FROM_DIFFERENT_DOMAINS=0.249, MAILING_LIST_MULTI=-1, 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: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id Wx57oxobguSr for <>; Mon, 7 Sep 2020 18:01:04 -0700 (PDT)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2DD5C3A07FE for <>; Mon, 7 Sep 2020 18:01:04 -0700 (PDT)
Received: from lists by with local (Exim 4.92) (envelope-from <>) id 1kFRxy-00038m-VR for; Tue, 08 Sep 2020 00:58:35 +0000
Resent-Date: Tue, 08 Sep 2020 00:58:34 +0000
Resent-Message-Id: <>
Received: from ([]) by with esmtps (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kFRxx-00037s-MJ for; Tue, 08 Sep 2020 00:58:33 +0000
Received: from ([]) by with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from <>) id 1kFRxu-000775-79 for; Tue, 08 Sep 2020 00:58:32 +0000
Received: from pps.filterd ( []) by ( with SMTP id 0880wFhE028611; Mon, 7 Sep 2020 17:58:15 -0700
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=pps1; bh=BbQhyuFlPak8mqbi0PEWCkpo3wrHsGYs5e21Nyl6sLA=; b=s2Kc+CSXIK65hbGoRvPQtY2H9PrsxVo0qZCGX0yIO3hvB/IcY52e7fbTtsA4WfJD/DaQ HkOHuVgc4BlvSxuwsl0zW/QDR3VFnL0+gaWvB+9EG/fTnUcvh5Yn4hcNmjdfpniQc8MJ OzGHMN8L1MWYhqlFOmKbu6ud0+JxtMF67hj797Yt4j34tD7wM+dYg5ZXxZ+6s0jazdfH jWGxWJQZULu4EbxifqbuzJOTeM+qRIaABmY/ZJiytnmHhNh8k496bFbOaoCZAEfSeCdo yZylRCQcV5tdayYJShLkKGhAKDHtWGMOutvx0Q+ychwG5Bt2Kjxvv2UXjSMrc/c3Ys33 5g==
Received: from ( []) by with ESMTP id 33c86ahjs5-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 07 Sep 2020 17:58:15 -0700
Received: from ( by ( with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.1.2044.4; Mon, 7 Sep 2020 17:58:14 -0700
Received: from ([fe80::ede2:6391:7f33:ef66]) by ([fe80::ede2:6391:7f33:ef66%4]) with mapi id 15.01.2044.004; Mon, 7 Sep 2020 17:58:13 -0700
From: Paolo Argentieri <>
To: Mark Nottingham <>
CC: "" <>
Thread-Topic: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06
Thread-Index: AdaDLhITApZ9D9QiQsGQE9kbe964WwB+AliAAAaH+CA=
Date: Tue, 8 Sep 2020 00:58:13 +0000
Message-ID: <>
References: <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
x-c2processedorg: 96cc0e5e-91aa-499a-88f5-5c9e71ddb7d5
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:6.0.235,18.0.687 definitions=2020-09-07_11:2020-09-07,2020-09-07 signatures=0
X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 mlxscore=0 adultscore=0 spamscore=0 mlxlogscore=985 clxscore=1011 lowpriorityscore=0 impostorscore=0 phishscore=0 bulkscore=0 priorityscore=1501 suspectscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2006250000 definitions=main-2009080006
Received-SPF: pass client-ip=;;
X-W3C-Hub-Spam-Status: No, score=-4.8
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, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, W3C_AA=-1, W3C_WL=-1
X-W3C-Scan-Sig: 1kFRxu-000775-79 602b5ec64200087961282a9c35d09a9c
Subject: RE: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06
Archived-At: <>
X-Mailing-List: <> archive/latest/38032
Precedence: list
List-Id: <>
List-Help: <>
List-Post: <>
List-Unsubscribe: <>

Hi Mark,
Thanks. I understand that adding new features to cookies is a complex process and I welcome an alternative solutions to the use case below.
AFAIK, for all practical purposes, Secure HttpOnly cookies are the only client side secure persistent store available to web apps today.
The "__Host-" Prefix does not seem to provide what's needed.

Consider this use case:
- (A) : REST Web Service hosted in
- (B) : Web App hosted in, issues fetch requests to (A)
- (C) : Web App hosted in, issues fetch requests to (A)
- One user agent accessing both Web Apps (B) and (C)

Step 1: User navigates to (B), (B) connects to (A) and receives a Secure, HttpOnly cookie (B-A-AccessToken).
Step 2: User navigates to (C), (C) connects to (A) and receives a Secure, HttpOnly cookie (C-A-AccessToken).

In this use case, we want the user to explicitly grant (C) access to (A), and not hijack the existing (B-A-AccessToken) cookie.
The solution, that can be implemented today, is for the server (A) to keep track to what "origin", (B) or (C), the AccessToken cookie was first issued to.

The issue here is that when (C) issues fetch calls to (A) both (B-A-AccessToken) and (C-A-AccessToken) cookies are sent. E.g.

//JavaScript hosted in (C)
                credentials: "include",  //NOTE: Both (B-A-AccessToken) and (C-A-AccessToken) cookies are included but only (C-A-AccessToken), the one matching the request header Origin: (C), is considered by the server. 
                mode: "cors"
            }) .then(...

Ideally, the user agent would know to only send the (C-A-AccessToken) cookie in the first place.
My original proposal is an attempt to define a backwards compatible "Origin locked" cookie: conformant user agent would not set or send "Origin locked" cookies that don't "match" the Origin request header.


-----Original Message-----
From: Mark Nottingham <> 
Sent: Monday, September 7, 2020 12:50 AM
To: Paolo Argentieri <>
Subject: Re: "Origin locked" cookie prefix - draft-ietf-httpbis-rfc6265bis-06

Hi Paolo,

Are you familiar with the __Host prefix?[1]

Describing what you want to do in relation to it might be more helpful.

Also, from a procedural standpoint, we have a pretty high bar for adding new features to cookies in the current work; the proposals that are current in-scope needed to gain consensus for inclusion before we started the work. So, we'd need to see some pretty strong support for a new feature, given the state of the work.


1.*the-host-prefix__;Iw!!AD8y5q2f9OQ!4Ou-7lGJNdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_olqMau0eg$ [httpwg[.]org]

> On 5 Sep 2020, at 12:44 pm, Paolo Argentieri <> wrote:
> Hi all, first post here.
> I'd like to propose a new "__Origin-" cookie prefix with "origin locked" semantic.
> While it is possible to implement these cookies today, standardized user agent support would add a layer of optimization and security.
> The cookie name begins with prefix "__Origin-" followed by the domain that served the parent page (the origin) and, optionally, a name postfix. Example:
> Set-Cookie:; Secure; HttpOnly; SameSite=None
> A conformant user agent would ensure that the cookie will have been set with a "Secure" attribute and the domain following "__Origin-" matches the request Origin.
> In addition, a conformant user agent would not send an "__Origin-" cookie if the domain in the cookie name does not match the Origin, excluding port.
> A server should ignore "__Origin-"  cookies whose name doesn't match the Origin request header. This combination yields cookies that are pinned to a specific origin thus well suited to roundtrip session ids or JWTs (immune to XSS session hijacking attack).
> Regards,
> Paolo Argentieri

Mark Nottingham;!!AD8y5q2f9OQ!4Ou-7lGJNdcwlutbNABvViOLwBUnnnDFXEP36WrysTRzSlUWPKFboK8PlGbrb_olZcXJkUg$ [mnot[.]net]