[OAUTH-WG] Client assertions to endpoints other than the token endpoint

Dave Tonge <dave.tonge@momentumft.co.uk> Tue, 28 May 2019 15:29 UTC

Return-Path: <dave.tonge@moneyhub.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A387F12013A for <oauth@ietfa.amsl.com>; Tue, 28 May 2019 08:29:08 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.986
X-Spam-Level:
X-Spam-Status: No, score=-1.986 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.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, T_SPF_PERMERROR=0.01, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=momentumft.co.uk
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id XdAPhX0zsRHp for <oauth@ietfa.amsl.com>; Tue, 28 May 2019 08:29:06 -0700 (PDT)
Received: from mail-ot1-x335.google.com (mail-ot1-x335.google.com [IPv6:2607:f8b0:4864:20::335]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id BEE49120115 for <oauth@ietf.org>; Tue, 28 May 2019 08:29:06 -0700 (PDT)
Received: by mail-ot1-x335.google.com with SMTP id g18so18113134otj.11 for <oauth@ietf.org>; Tue, 28 May 2019 08:29:06 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=momentumft.co.uk; s=google; h=mime-version:from:date:message-id:subject:to; bh=PJCyuP7bCVjsBRy2FCugSrpda4vBr6PJ9px1+3XzB1Q=; b=MlhszMpSDOB21UB+uirsv98A596+GE+L55CvnxByWuQV0rFYIQ/T7HpM0/Z9oZNTHf wXDJKr9uOuGEPfZq0J13aNyt0Nq9ELRGcjJCaV7az6yAUsoXMRi/YPWjtNN1jQzCVGh1 c86F5G7p84o0JOVAl4jnS1qXnNBvZiArZc+h4=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=PJCyuP7bCVjsBRy2FCugSrpda4vBr6PJ9px1+3XzB1Q=; b=t4IzVzj71bC0ysQ6si892W1HdwJ/coRysugqU15rIvTuT2/VSmW9dYRe9D9GCth57J 1d9eIKC/nyuckvhW41GjFJG/PvVply1Sqr16zYSYGcRq8S1hZEn0GBFzBaoGr2N9Ng3v iCzKjqZ5EKibM1LIMvoPKEHPepTPxwIVYel4wMaFXVdvQqOJ9lrGOe5YmBbDCJnZ/BYE T01PnfwTxA8KnmwP0SIrurHYTCjDFAo13iy6exz9NprwuFiCov0evh4Gh6qYmEkldY3w W/YkcavkrvDd5mwtXLGoEHxhNA4bgce9Ygvn5hbFP0Pg2oe03sN9wJA3eQ5u3PFktxv0 1aOA==
X-Gm-Message-State: APjAAAUd1llPfCx7sIdj7CTvZ/dqr2PGvwcMnYs+C2RPB+EKQbrz2DB5 GQ7yLzqtiRrTMirHqu4zOWhSa5xLuXoCByAR51jWEfNbQu1IOg==
X-Google-Smtp-Source: APXvYqwS8Luf1WLK0hd2zNKlBOOuHtzR1p2GVd+atenx/mkFfEhgEOgSQtIiPn3QgMIEzpHOCGuwFFouC89SnSi2OcQ=
X-Received: by 2002:a9d:7a53:: with SMTP id z19mr31711343otm.260.1559057345483; Tue, 28 May 2019 08:29:05 -0700 (PDT)
MIME-Version: 1.0
From: Dave Tonge <dave.tonge@momentumft.co.uk>
Date: Tue, 28 May 2019 17:28:54 +0200
Message-ID: <CAP-T6TRfq1Bo5L3MoNKKTLQ+M9aTSb-z0-j=y0GaXabEW+s6Lg@mail.gmail.com>
To: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="0000000000004346e80589f453fe"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/Z2QXaIPXvP8BIA0by6ktFSoyKK8>
Subject: [OAUTH-WG] Client assertions to endpoints other than the token endpoint
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 28 May 2019 15:29:09 -0000

Dear OAuth WG

We have an issue that we are discussing in the OIDF MODRNA work group
relating to the Client Initiated Back Authentication spec (which is an
OAuth 2 extension). As the issue affects the wider OAuth ecosystem we
wanted to post it here and gain feedback from the OAuth Working Group.

Full details of the issue are here:
https://bitbucket.org/openid/mobile/issues/155/aud-to-use-in-client_assertion-passed-to
(including
a helpful context setting by Brian), but the summary is:

*What audience value should a Client use when using a client assertion
(RFC7521) to authenticate at an endpoint other than the token endpoint?*

The three options we have are:
1. the token endpoint (as RFC7521 says)
2. the endpoint the assertion is being sent to (e.g. revocation,
backchannel)
3. the issuer

We are leaning towards requiring the Authorization Server to accept any of
the above values, but recommending that the Client use the issuer value.

The reasons for this are:
1. All of the above values are arguably valid, so in the interest of
interoperability the AS should accept them all.
2. We see no clear security benefit to requiring the audience to be the
value of the endpoint the assertion is being sent to, and therefore think
that the issuer value is the one we should recommend that clients use.

We would be grateful for your feedback on this issue and believe it would
be in the best interest of the ecosystem for there to be a consistent
approach to this across OAuth 2 extensions and profiles.

Thanks

Dave Tonge