Re: [OAUTH-WG] OAuth Topics for Vancouver

Rob Cordes <> Mon, 20 January 2020 18:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 1BDB41200B7 for <>; Mon, 20 Jan 2020 10:18:19 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-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 dEBzRWty3g0D for <>; Mon, 20 Jan 2020 10:18:16 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 2B89C1201DC for <>; Mon, 20 Jan 2020 10:18:16 -0800 (PST)
Received: by with SMTP id w15so483619wru.4 for <>; Mon, 20 Jan 2020 10:18:16 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=vMNaIcZhFKtNxBssm/OTiW23qOeGzy1LvMbn3MYo2s8=; b=oYPQzqeu2SzQnyRJ8RNIbHSBYAtnne1JxkkKbYLYxo1kgvFxC4xg4qxaeX+dvawllY +7JPCxMHccI9LAgL82XG4x/eN2PQNfNfc1jKqKdFBejedvlToO+z075ZB7i534eKs4PY NJ1N6z3SIC3pAuMGYOuwCpx/96oFAAoJL/fc7//8UXWUwSh6cG1TiQrO3jvqGWZJx4fa PfJ7RmStA+ygd5+hiB60qI98n7GHsejYATjvJPL1lowBES1o8fnkXYWhzH0pc5LgDwfU JyvR8t0XajbQCfuGL28NEE20ViSczubU7yRGWTm0Pkof6VT95WnVBErUW7DhDmSf0PBh R/2g==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=vMNaIcZhFKtNxBssm/OTiW23qOeGzy1LvMbn3MYo2s8=; b=RvgSGFBNHl5brRuuMPsYaxvw4YuXpeDLZo5sdH5Wtu/vi2tb+y1AltpeOPFiQmPQsX Nlc85C/B5w+WBhIm11DFvnFxjoL4SsVCguKhDxHRIPXAhvTAdCIh1Tg3Na+1qygiXlCg p8JK6BwXdBUqUQfuWEr6PgVz8bVX6wWQMkI1tlq3meJyMwMaEWnvbx++zO84FywL9FRb 9hBKN8+5/m20GKbhXvbNqVkzO+BBEVvWW079Zq/v+MvROsg5xZ8lHr5DG/+Cjb/SUUUs e+kikrJSIETGsJyhcPjOJJv656IOgZa5DgJbgAB74A2vdDv/z0hSD/c7uDFCbKiFCPvi iQgw==
X-Gm-Message-State: APjAAAV6tqHqq1YlWQcbkPNcPV16icLNaJzu6+991hQ9PG9WNzsWBU/V T0bG74VlLZvtfjGZPi7W1NA=
X-Google-Smtp-Source: APXvYqzsLsP7jK6NftoNAlfQlsOBMB8YuDaDm2VAh9iM1nAUa1lWxgw74j/kBZY1+0lF6lvm+8py9g==
X-Received: by 2002:a05:6000:1047:: with SMTP id c7mr742062wrx.341.1579544294513; Mon, 20 Jan 2020 10:18:14 -0800 (PST)
Received: from ?IPv6:2a02:a443:c7cb:1:6daa:a695:f46c:5b08? ([2a02:a443:c7cb:1:6daa:a695:f46c:5b08]) by with ESMTPSA id w17sm48658445wrt.89.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jan 2020 10:18:13 -0800 (PST)
From: Rob Cordes <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_3ABD7983-416B-4B74-8886-B42BB44F128E"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Mon, 20 Jan 2020 19:18:12 +0100
In-Reply-To: <>
Cc: Rifaat Shekh-Yusef <>, oauth <>
To: "Richard Backman, Annabelle" <>
References: <> <>
X-Mailer: Apple Mail (2.3608.
Archived-At: <>
Subject: Re: [OAUTH-WG] 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 18:18:19 -0000


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
> All, 
> Please, let us know if you have any topics that you would like to present and discuss in Vancouver.
> Regards,
>  Rifaat & Hannes
> _______________________________________________
> OAuth mailing list