Re: [OAUTH-WG] OAuth Discovery

William Denniss <wdenniss@google.com> Thu, 26 November 2015 00:01 UTC

Return-Path: <wdenniss@google.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B103F1B32D4 for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 16:01:46 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.963
X-Spam-Level:
X-Spam-Status: No, score=-1.963 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, RP_MATCHES_RCVD=-0.585, SPF_PASS=-0.001] autolearn=ham
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 6x-euv2xH-n7 for <oauth@ietfa.amsl.com>; Wed, 25 Nov 2015 16:01:44 -0800 (PST)
Received: from mail-qg0-x230.google.com (mail-qg0-x230.google.com [IPv6:2607:f8b0:400d:c04::230]) (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 D07B31B32D5 for <oauth@ietf.org>; Wed, 25 Nov 2015 16:01:43 -0800 (PST)
Received: by qgcc31 with SMTP id c31so44018517qgc.3 for <oauth@ietf.org>; Wed, 25 Nov 2015 16:01:43 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=ZjgwWGKbAMm+p2vuJA3fen+/9IV0SHEUjFjm1XkZwMQ=; b=clV5fu8r73aZpV4fcRNsZC6rWT32FRPQADORC1nXQLoFhGv0oThMnELg2c/rvvaXP6 ZTE+XgvSlKpyXpf6cYywkhMyurMXvsgDZ9VUPsPsl3ediOieitIMkWqJ3DLVdvR7DdcA i5XYGQGvUrqiMM/Okq4OVjj+heISF5F33UkGU8sMepBMgIt0w+BoNo8cN3uM1Z7Hl/Ue be+FvfKDsR9Tt7exikmX2aQgI2I/Hsry+pAAHI+bVpJ/1NZ/j5lMjdRK0FdUnO8gNzTV sN2Uxo3lwHTa/eLhfoHicWoHxti7xK8QXY9Yy+HWUM68w9rJO1WOzeze2glU6Kg/exWo ERQA==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-type; bh=ZjgwWGKbAMm+p2vuJA3fen+/9IV0SHEUjFjm1XkZwMQ=; b=dNmIH64sw9owBV/7CncVKLMhxQVmVhoE3eZ3Wfue7Adr7PdttAEs4rawuxn9qQoFMl S0FlaS3rP66eM5ugCWqd8gP5yNttl7t6yI08SvoWpNQdPcH2Rjz6Uw8e4YwWy7A6aXKy 1q9zQ4r+GPOwGwp3bu5XJax+msjnNCGGs1vG0TLwo/upukD/iGR1jlkShwzaZcGleTSr 59Sahr5lXfdsyz3KFic3+t2ZqvMeWLrHKgMh1noYhGmapvk/mUSTOgycmEdP8YtDuyTB m0BdXokP5j8Rv2AURcqX0YAQtBN3TOFyMxGnB5Q2WO75xGr837iZGi4gOTJlb1Jl86Yx F45A==
X-Gm-Message-State: ALoCoQmDecOEIWj7j4sJ7O08NJJXybHVYOsp8ITTDqLPinrlrUKFMkbBMqkDH5xMeKW3j2u+ZX6Q
X-Received: by 10.141.6.69 with SMTP id i66mr45683606qhd.68.1448496102872; Wed, 25 Nov 2015 16:01:42 -0800 (PST)
MIME-Version: 1.0
Received: by 10.140.29.68 with HTTP; Wed, 25 Nov 2015 16:01:23 -0800 (PST)
In-Reply-To: <BY2PR03MB4420981B312D92924AD6BFFF5050@BY2PR03MB442.namprd03.prod.outlook.com>
References: <BY2PR03MB4420981B312D92924AD6BFFF5050@BY2PR03MB442.namprd03.prod.outlook.com>
From: William Denniss <wdenniss@google.com>
Date: Wed, 25 Nov 2015 16:01:23 -0800
Message-ID: <CAAP42hDvTqEFDREwMOwXqimNMi+7W=SMLZ2z+HJ_Cw75xVQz_Q@mail.gmail.com>
To: Mike Jones <Michael.Jones@microsoft.com>
Content-Type: multipart/alternative; boundary=001a113a7c1cabf29c05256647df
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/j9jXk2zpN_fAK_n_8sUkCM5DjyQ>
Cc: "oauth@ietf.org" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] OAuth Discovery
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: Thu, 26 Nov 2015 00:01:46 -0000

Looks good. A few review notes:

1.
Can we add a xref to the WebFinger spec (RFC7033) in section 2?

2.
Is the only way to discover the location of the discovery document via
WebFinger?

In Yokohama we also talked about the AS returning the discovery document
host (i.e. issuer) on the auth and token endpoints.  What are the reasons
for choosing WebFinger over that method?

3.
It looks like an IANA registry was not setup for OpenID Connect discovery
params (at least, not in that spec). Is the registry established in
http://tools.ietf.org/html/draft-jones-oauth-discovery-00#section-8.1.2
designed to be a shared registry for OIDC/OAuth discovery? And if so,
should we also register values defined in the OIDC discovery spec, e.g.
"subject_types_supported"

On Wed, Nov 25, 2015 at 3:37 PM, Mike Jones <Michael.Jones@microsoft.com>
wrote:

> I’m pleased to announce that Nat Sakimura, John Bradley, and I have
> created an OAuth 2.0 Discovery specification.  This fills a hole in the
> current OAuth specification set that is necessary to achieve
> interoperability.  Indeed, the Interoperability section of OAuth 2.0
> <https://tools.ietf.org/html/rfc6749#section-1.8>states:
>
> In addition, this specification leaves a few required components partially or fully undefined (e.g., client registration, authorization server capabilities, endpoint discovery).  Without these components, clients must be manually and specifically configured against a specific authorization server and resource server in order to interoperate.
>
>
>
> This framework was designed with the clear expectation that future work will define prescriptive profiles and extensions necessary to achieve full web-scale interoperability.
>
>
>
> This specification enables discovery of both endpoint locations and
> authorization server capabilities.
>
>
>
> This specification is based upon the already widely deployed OpenID
> Connect Discovery 1.0
> <http://openid.net/specs/openid-connect-discovery-1_0.html> specification
> and is compatible with it, by design.  The OAuth Discovery spec removes the
> portions of OpenID Connect Discovery that are OpenID specific and adds
> metadata values for Revocation and Introspection endpoints.  It also maps
> OpenID concepts, such as OpenID Provider, Relying Party, End-User, and
> Issuer to their OAuth underpinnings, respectively Authorization Server,
> Client, Resource Owner, and the newly introduced Configuration Information
> Location.  Some identifiers with names that appear to be OpenID specific
> were retained for compatibility purposes; despite the reuse of these
> identifiers that appear to be OpenID specific, their usage in this
> specification is actually referring to general OAuth 2.0 features that are
> not specific to OpenID Connect.
>
>
>
> The specification is available at:
>
> ·         http://tools.ietf.org/html/draft-jones-oauth-discovery-00
>
>
>
> An HTML-formatted version is also available at:
>
> ·         http://self-issued.info/docs/draft-jones-oauth-discovery-00.html
>
>
>
>                                                                 -- Mike
>
>
>
> P.S.  This note was also posted at http://self-issued.info/?p=1496 and as
> @selfissued <https://twitter.com/selfissued>.
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>
>