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

Rob Cordes <> Mon, 20 January 2020 21:37 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 4197A120232 for <>; Mon, 20 Jan 2020 13:37:22 -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 CYRGBctphOtk for <>; Mon, 20 Jan 2020 13:37:19 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::435]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 870A412011D for <>; Mon, 20 Jan 2020 13:37:19 -0800 (PST)
Received: by with SMTP id t2so1084462wrr.1 for <>; Mon, 20 Jan 2020 13:37:19 -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=tjBJ9WLq7z27DVXl6kzpv2Qsq5bSQSyixOFsv6m6gkQ=; b=OA5/2jKMNRsuH3Xp0aJHny8Fdn+9j+DK1MVwstoJwIFJjvBJHSwAKb0GiTb1LxR9gb tX/+JneIbxqfreY9IdD76/hCwpd0K3VHGDJk1TY7UwT79LcA1SdzR4C3U2AwtQ9iUnhm EaCAahwvXFj0Io9DXgx4K1PBOzYT1TTJk6pbix0Og0U5oCPxtqB1+jbZr97pKF23FAiC 0o4fROatw1KiWzuy12Gm5QdCMOMhg2MUGqymipzgKwx7FGkRKt+FDalySnXne4S2kfLW qQp5YtiY3pU7xvkz+TXUmi2M9DM1xly3+neDWma/hBpuCknYRMahCu9nMBbRsU85n6tg oeAg==
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=tjBJ9WLq7z27DVXl6kzpv2Qsq5bSQSyixOFsv6m6gkQ=; b=HmBuvxLV8ydwPkOCjnNyNAqJUGPCFIO6uWeS3hT1suEPygyy9bJ1ppcwdsyuZcqbne q+7pg+1JewMZBIQvzrsw9fkymMfYI4LPnuB87WR4Fc8wIxgCK0d3QaB6uFVAEHqwdMUc /ZGnH+KcZEu7DpBtCyXqiOdudab3ErhbrsHaZ0phwr9mfoby4LOwBQl6y+XgKHMNIjPQ v5xjUKva0Vr4vdC8x+HtnXznXkH1sMQ2S2uNE4sKcFtrO3P+7tr8SbJVtDtLQvlzI7mW OXLYuwAZgPg1w7/sY3BQ041LEuM07mg1dulHgDUujHtgya/pe0PIy4viLoAyJOFrVC50 UZHg==
X-Gm-Message-State: APjAAAWZQsbiS9bSZlH+r9MJwvFPFzNT5L/Ls/mkQ0PaIWvn4bWHylc3 gGRphI6Zt1hodrSDrPpxHR7MYo2UHwA=
X-Google-Smtp-Source: APXvYqwhoMAnp3ZU/Yf7OpvgUkkHRTptBOfrI0CbkE+wLgx0qJHkqCW+Hg5Mz35vaIxNR3aoWwaWtw==
X-Received: by 2002:a05:6000:cf:: with SMTP id q15mr1391377wrx.393.1579556237967; Mon, 20 Jan 2020 13:37:17 -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 w20sm803365wmk.34.2020. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 20 Jan 2020 13:37:17 -0800 (PST)
From: Rob Cordes <>
Message-Id: <>
Content-Type: multipart/alternative; boundary="Apple-Mail=_4BA55084-B8CD-4D79-B259-EB7FBCAE1D5F"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.\))
Date: Mon, 20 Jan 2020 22:37:16 +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] [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 21:37:22 -0000

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 <>