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

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

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4C9DA120232 for <>; Mon, 20 Jan 2020 12:50:55 -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 YTpUzk1RLzuR for <>; Mon, 20 Jan 2020 12:50:49 -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 78A1112001A for <>; Mon, 20 Jan 2020 12:50:49 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;;; q=dns/txt; s=amazon201209; t=1579553450; x=1611089450; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=TY6atr19xi1+H17JbWkXi1KykC3ymyp7Y7e+V08RL8I=; b=QwHm5BnsSUOSpi5sh6rpSJso0kzon2HN9VxT4uUzb75ENADRspRCEYFF BZTY3J9MDUF5cpMpFvOAKVktyxp2Egj1j9mpg05/0K5YbuZQ1VR0m/FS/ csgx+31ox71A49BGd48u4aZr7j450n5Vm4D8NGB2et2CnudIUToKiz3rX g=;
IronPort-SDR: 1Q+cJqBtGd5iNqIpQYBB8hQ6C8Wcd3RT38RbjTA3LkZX8YBlk2h4t7C3l9v0i9Y3w0FbM0bv0t Fk8evDKoIZIg==
X-IronPort-AV: E=Sophos; i="5.70,343,1574121600"; d="scan'208,217"; a="19858227"
Received: from (HELO ([]) by with ESMTP; 20 Jan 2020 20:50:39 +0000
Received: from ( []) by (Postfix) with ESMTPS id B6A96A19F1; Mon, 20 Jan 2020 20:50:35 +0000 (UTC)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Jan 2020 20:50:35 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.1367.3; Mon, 20 Jan 2020 20:50:34 +0000
Received: from ([]) by ([]) with mapi id 15.00.1367.000; Mon, 20 Jan 2020 20:50:34 +0000
From: "Richard Backman, Annabelle" <>
To: Rob Cordes <>
CC: Rifaat Shekh-Yusef <>, oauth <>
Thread-Topic: [UNVERIFIED SENDER] Re: [OAUTH-WG] OAuth Topics for Vancouver
Thread-Index: AQHVz6cmxk4jjxQ5zkeyuBJCXveYtafzSgYAgACSngD//6R2AA==
Date: Mon, 20 Jan 2020 20:50:34 +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_3950598EF3F148218C18DC9008C65DFDamazoncom_"
MIME-Version: 1.0
Archived-At: <>
Subject: Re: [OAUTH-WG] [UNVERIFIED SENDER] Re: 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 20:50:56 -0000

As editor of the message signatures draft being considered for adoption within the HTTP WG I can confirm it has significant flaws. 😃 As noted in that draft, the current text is intended to serve as a baselining of sorts to get work that has been floating around in the community into the working group, and it is expected that the working group will make significant breaking changes to it. I encourage anyone who wants to participate in those discussions (as well as the general “call for adoption” discussion to do so, on the HTTP WG mailing list. 😃

I believe it would be to both working groups’ benefit to have an OAuth PoP draft based on HTTP message signatures under discussion early. It would provide the HTTP WG with a test case for the layered approach that the HTTP message signatures draft takes towards this problem, and would allow the OAuth WG to ensure that our use cases are supported. Also, given the interest in DPoP, I think it will be helpful for the OAuth WG to see what message signature-based PoP might look like. It may be easier to target DPoP at a narrower set of use cases if people see a broader solution is coming.

The introduction to the HTTP Message Signatures draft<> describes why TLS is not a universal solution to this problem.

Annabelle Richard Backman
AWS Identity

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


Sorry for me answering in this direct manner instead of via the OAUTH mailing list or so.

I would like to point a practical issue out wrt the HTTP signature spec. I have got practical experience with the spec through my work for ING in our PSD2 (European electronic banking scheme) platform. We have implemented this spec (cavage-10) in our platform as well. We experience lots of issues with 3rd party developers who have issues getting their code right. It is the canalisation that is troubling the adoption in practice. People are continuously making mistakes with setting up the payload for signatures / body digest.
This can only be solved by making available ready made libraries. That might be done through vendors and their solutions and one would encounter  probably less interoperability issues.

However until then still troubles is what people have with this spec. Apart form that,  the spec is very much draft and as I understood from one of the draft members and still not security tested ands so perhaps still not secure.

Before one can adopt another spec into, in this case OAuth 2.0 it would be wise to tackle this first. While HTTP signing does help in better authenticating and safeguarding messages/token requests, this will make key management even more important.

The risk that HTTP signing in OAUTH might mitigate, could very well be far easier solved by TLS 1.2 or 1.3. That is even better because the implementations are security tested (TLS 1.2 or depending on the supplier/implementer in the process of (TLS 1.3) due to their importance and can be implemented in a turn key manner.

These are I believe important attention points that one might think over before extending the OAUTH 2.0 spec even further with perhaps too little gain?

Best regards,

Rob Cordes
Feature Engineer  / InfoSec specialist @ ING bank

On 20 Jan 2020, at 18:33, Richard Backman, Annabelle <<>> wrote:

I would like to discuss HTTP Message Signatures<> as a proof-of-possession mechanism for OAuth. A draft will be available (either as an update to draft-ietf-oauth-signed-http-request or as a new individual submission).

Annabelle Richard Backman
AWS Identity

From: OAuth <<>> on behalf of Rifaat Shekh-Yusef <<>>
Date: Monday, January 20, 2020 at 7:34 AM
To: oauth <<>>
Subject: [OAUTH-WG] OAuth Topics for Vancouver


Please, let us know if you have any topics that you would like to present and discuss in Vancouver.

 Rifaat & Hannes

OAuth mailing list<>