Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata

William Denniss <> Tue, 21 February 2017 00:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 9CA4812955C for <>; Mon, 20 Feb 2017 16:59:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 BlgCXPkCSQrT for <>; Mon, 20 Feb 2017 16:59:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400d:c0d::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id CD797120725 for <>; Mon, 20 Feb 2017 16:59:28 -0800 (PST)
Received: by with SMTP id k15so100048120qtg.3 for <>; Mon, 20 Feb 2017 16:59:28 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=TTXYTxuBE9rEtl8/gjjCzFwt5USE09EbVHsQlGLN9uk=; b=CHaXH1jIKSCeib/Sv0SVJErTCMjkdsDha1TstwAHKnRx7MnlhH+3NA+7qbgheMT8Sw jcEcYyuknuYFigE2me9JSu25fqvYhcj0SOZQompZ7VaEG2P9ijOku/TpgdBbEVo0L96K DrENsFu6r7A0ldhhYSYkM48byMJSOstm8xYfn/vju4u4ogydiYMBGcuIW60fSyXg3XGP cL6OB2QLapnqzH8sP5e3MguTpnPONexzib5EtUQh4pTY4fFC0TDibGRmfqvSBRCHeyjA TCD+3AZ3d3FQj2vJ9Q2Kci2qffFR0lVg/unScmSx26mg7vNlCWybsmi7GBH4eVuEPSlY /odw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=TTXYTxuBE9rEtl8/gjjCzFwt5USE09EbVHsQlGLN9uk=; b=PYRSvgjshrQwDkyFjvg0AtA/fz3wrwYSc1/4zXjPtRPYmxnfcX1NALUjODkzdDlKkl pnh5rz7ueeXpVF5EDcGpcLTV5bUUvDe0z3c6kKSuMNMxmEV8DXpAEoG2E6pIehpLXwCp 1CgG2T+dYoZGrnaF5Q7PZBIKBVVhkLmaSLBVEIi6YWVceB33mKfhxF/Lx2oUyGjQF8hS Rf2eYbBJ0INf+VEiL6yUZfyLvUJiwl1fHUK5edDRT8TRjWoAop5/1ZrH1KetJaJO2Uz9 1+h2jQzyftE/YwzfGgKBGlP7cpZNTITFVkez4QLV65mLMAr+lW7gtGzUMjQMSZ16zCci JUDQ==
X-Gm-Message-State: AMke39mwwzCXKU1GyMHRzaU0Ag8Pjz1/3/h72X2RP+yS9BokNDJLMg2LAesUDDR0hy4he+qlruTfc8OMjVBEFEMo
X-Received: by with SMTP id s21mr23664558qtc.80.1487638767783; Mon, 20 Feb 2017 16:59:27 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Feb 2017 16:59:07 -0800 (PST)
In-Reply-To: <>
References: <>
From: William Denniss <>
Date: Mon, 20 Feb 2017 16:59:07 -0800
Message-ID: <>
To: Hannes Tschofenig <>
Content-Type: multipart/alternative; boundary="001a113bfc704f34d80548ffe4bb"
Archived-At: <>
Cc: "" <>
Subject: Re: [OAUTH-WG] Working Group Last Call on OAuth 2.0 Authorization Server Metadata
X-Mailman-Version: 2.1.17
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Tue, 21 Feb 2017 00:59:30 -0000

I have reviewed version 05. Two minor comments regarding Section 2.1:

1. Should we clarify that alg:none isn't supported for the signed_metadata
JWT (since it would be contradictory)?

2. Re: "metadata values conveyed in the signed metadata MUST take
precedence over those conveyed using plain JSON elements."  Does this imply
that *all* values in the plain JSON elements should be ignored when the
signed_metadata is being used (not just ones present in the JWT)? If not,
should it?

Overall, I strongly support the publishing of this document as an RFC for
the following reasons:

Having "machine readable" configuration metadata published by authorization
servers is a useful concept. The Google authorization server (like many
others) publishes metadata compliant with this specification, and the
AppAuth series of client libraries are capable of consuming it.

Without this standardized machine-readable metadata, developers must read
documentation to extract the relevant information, and configure clients
manually. This is cumbersome, error prone, and may get out of date.

This specification can also help prevent one category of "mix up" attack in
systems which allow self-registration of OAuth endpoints for connected
services. Rather than the developer supplying both the authorization and
token endpoints themselves (which may enable them to specify a malicious
token endpoint), such a system can use the token endpoint specified in the
authorization server's metadata, thus preventing this category of attack
(and simplifying the registration process to boot).

On Mon, Feb 20, 2017 at 1:45 AM, Hannes Tschofenig <> wrote:

> Hi all,
> it was roughly a year ago when we issued a working group last call on
> draft-ietf-oauth-discovery, see
> Lots
> of feedback resulted in a significant restructuring of the document.
> The authors of the draft now believe it is ready for a second WGLC and
> hence we would like to start a 2-week review period.
> Please provide your review comments no later than March 6th.
> Here is the link to the document again:
> Ciao
> Hannes & Derek
> _______________________________________________
> OAuth mailing list