Re: [OAUTH-WG] [UNVERIFIED SENDER] OAuth Topics for Vancouver

"Richard Backman, Annabelle" <> Mon, 20 January 2020 22:09 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1B2BF120045 for <>; Mon, 20 Jan 2020 14:09:15 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.5
X-Spam-Status: No, score=-14.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, USER_IN_DEF_SPF_WL=-7.5] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 8z92ig_nNYvD for <>; Mon, 20 Jan 2020 14:09:11 -0800 (PST)
Received: from ( []) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7BFAA120018 for <>; Mon, 20 Jan 2020 14:09:11 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=amazon201209; t=1579558151; x=1611094151; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=CJcNH291ur/ZMXAcpTEu26KC47esHMZS0/nxYz8jqgw=; b=ahgR3EbRX0KuJQmLvlmVE+46X7NAf8nnRMBk2nRDv2v1zShXoAnxivew 2/Q/dxaX8zIrOjxwu3nh5WdxG7Q/fdkEJW+NVxjKX6fMMomLzmeHqvlJ3 kOGAw8LjNDigQhXg1Hu8pxwj3plBMwXuCRj4UprWpVN+7IYVe2RtOV5ZA Q=;
IronPort-SDR: IRLlxGiF9iIBUrM6ayxRWSZov7BfX5EipiB47/lrNFIaPh2/vddZKWbKBy7BgIils6k5AxcZlL WLeXdkqx/T/A==
X-IronPort-AV: E=Sophos; i="5.70,343,1574121600"; d="scan'208,217"; a="11469235"
Received: from (HELO ([]) by with ESMTP; 20 Jan 2020 22:08:59 +0000
Received: from ( []) by (Postfix) with ESMTPS id 598C7A23C9; Mon, 20 Jan 2020 22:08:58 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Jan 2020 22:08:57 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Jan 2020 22:08:56 +0000
Received: from ([]) by ([]) with mapi id 15.00.1367.000; Mon, 20 Jan 2020 22:08:56 +0000
From: "Richard Backman, Annabelle" <>
To: Rifaat Shekh-Yusef <>, oauth <>
Thread-Topic: [UNVERIFIED SENDER] [OAUTH-WG] OAuth Topics for Vancouver
Thread-Index: AQHVz9noSMX41D1sF0OdpKI6rvVIGKfzlpoA
Date: Mon, 20 Jan 2020 22:08:56 +0000
Message-ID: <>
References: <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
user-agent: Microsoft-MacOutlook/10.1d.0.190908
x-ms-exchange-messagesentrepresentingtype: 1
x-ms-exchange-transport-fromentityheader: Hosted
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_670F3DAF2FAD42F5AD6DE158F05D396Aamazoncom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] OAuth Topics for Vancouver
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jan 2020 22:09:15 -0000

To be honest I’m somewhat taken aback by this reaction. The request was for time to discuss an alternative PoP mechanism face-to-face. This is a topic which has come up in the context of other work (e.g., DPoP) at several recent IETF meetings, including the last one in Singapore. While I recognize that the working group has a lot on its plate and needs to allocate time judiciously, it seems clear to me that this is both timely and relevant.

Unless the chairs indicate that they require further justification for the time slot, I’m going to stop cluttering this thread with defenses of a draft that doesn’t exist yet.

Annabelle Richard Backman
AWS Identity

From: Rob Cordes <>
Date: Monday, January 20, 2020 at 1:38 PM
To: "Richard Backman, Annabelle" <>
Cc: Rifaat Shekh-Yusef <>om>, oauth <>
Subject: Re: [UNVERIFIED SENDER] [OAUTH-WG] OAuth Topics for Vancouver

Hi Annabelle,

Sure TLS is not th one size fits all but if you swap out Client Y signs / authenticates message A to recipient X  by:  Client  Y uses TLS for authentication of the source (itself), integrity of data / communications and  even confidentiality (not really needed in our HTTP signing use case)  where TLS is initiated and handled by the client Y  itself (native libs or proxy at the same host(s) then you have precisely that what HTTP Message signing should do. (authenticity,  integrity and as a bonus confidentiality).

That said, one can opt for HTTP signing if one wants to, except it is not secure for now and is at present for many developers a nuisance use  as it turns out. If you do not want  or cannot deal with TLS tunnels and yes indeed TLS connection re-use, by all means go ahead. I would advise my customers to try TLS first because it is proven and simple to implement and so easy (cheap ;-) ) to support. It is always worthwhile to at least try to get Infra on board to see if one can go the TLS route first and if that fails… well then HTTP signing or accept the risk.

The issues we have at ING with 3rd parties cause us to back down from using it in general but still for those API’s wanting to have better assurance than otherwise. We do not want to provide our own libs to external parties for obvious (legal mostly) reasons. We did not go the TLS route at first, that turned out a mistake ;-).

Let me conclude that I always am quite happy to see alternatives popping up and existing protocols being continuously enhanced. For this I thank you and others to continue developing protocol implementations such as HTTP message signing.



On 20 Jan 2020, at 21:50, Richard Backman, Annabelle <<>> wrote:

introduction to the HTTP Message Signatures draft<>