Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Nat Sakimura <sakimura@gmail.com> Wed, 24 February 2016 11:55 UTC

Return-Path: <sakimura@gmail.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 B2BE01A912A for <oauth@ietfa.amsl.com>; Wed, 24 Feb 2016 03:55:06 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
X-Spam-Status: No, score=-1.999 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, 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 YhJ5JrKUmNzH for <oauth@ietfa.amsl.com>; Wed, 24 Feb 2016 03:55:00 -0800 (PST)
Received: from mail-qg0-x22c.google.com (mail-qg0-x22c.google.com [IPv6:2607:f8b0:400d:c04::22c]) (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 B51691A9128 for <oauth@ietf.org>; Wed, 24 Feb 2016 03:54:59 -0800 (PST)
Received: by mail-qg0-x22c.google.com with SMTP id b67so11439763qgb.1 for <oauth@ietf.org>; Wed, 24 Feb 2016 03:54:59 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :content-type; bh=EtkqNABlZUlOP7zOw/xCqxuNxLjqbvRbWyQFOK3KXeI=; b=WAqCB9Yr/NQPCDIEDQaUs22dPcHkmO05rAfxPI32SR3ZwS1jVz6AqBjFxGCJUahJIj IcUs21efKsHiAxPmpXPwqQl551z2rK5u+lmogqZL30jK9Lvq0geG1FHvMUhCN0jeNUSc EnC4D/XApBtBPAmeUSbkxdMURQeFdD3nuP6bygtBsFdJjtSxkl27BGI29p2fFrl0yFXh 3MSya73RK/aJPLUZCF8j/F4inoma3hiczF8pHMx9ZW9hZc7cKEOAtnbKkweknyhG1DPj bEMdWnAM4jP5bOSMukBbPUD/iy2V8K9w+P0ksRJu7BeSjHVZmhPsvXQv84xJHnTjyyIq 2C/w==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:content-type; bh=EtkqNABlZUlOP7zOw/xCqxuNxLjqbvRbWyQFOK3KXeI=; b=SFNfirvuQE00VhHYbyojBADWzLOflYeQQ9SeSF/eKd+h+hN0xJu9qvu8yQGBQTjDAu +fRXcf56Z0hIBjxJpksAo3ziCLq8bMKYUku9q8ZFTeRdLav8MC729z/6AQcUjCUhaCtM MXeJR3wjinTOP5ZAEhCm1DXSA2BHbbi1or2aR/CGmoJiQDVx7laQhv9G9V2dIDp+eKrY KrJlBADsNctSu0S25t4R82rumHQbhoAShawcRgPpbvUXm+77aB537sn7ZDvbRjfX1Zfn SNQi50z2vdWpYHO8/NfXb7/+cVUG5hepp3QV06Xk0JFK1BPCZSCb3af1Tqse2cuDsPhg gPlw==
X-Gm-Message-State: AG10YOSnUEH9ah0OIzCc9z12D7r9wYGwNs4BBpUeNK+w4Oio6SyXPrSisPL4k2D9RCpVLIQ7bdVQBlXWjltdMw==
X-Received: by 10.140.96.84 with SMTP id j78mr46595533qge.93.1456314898861; Wed, 24 Feb 2016 03:54:58 -0800 (PST)
MIME-Version: 1.0
References: <E3BDAD5F-6DE2-4FB9-AEC0-4EE2D2BF8AC8@mit.edu> <CAEayHEMspPw3pu9+ZudkMp9pBPy2YYkiXfPvFpSwqZDVyixWxQ@mail.gmail.com>
In-Reply-To: <CAEayHEMspPw3pu9+ZudkMp9pBPy2YYkiXfPvFpSwqZDVyixWxQ@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Wed, 24 Feb 2016 11:54:49 +0000
Message-ID: <CABzCy2CpSB2Nrs-QoaEwpqtG4J8UNeAYNy1rion=mp5PQD2dmg@mail.gmail.com>
To: Thomas Broyer <t.broyer@gmail.com>, Justin Richer <jricher@mit.edu>, "<oauth@ietf.org>" <oauth@ietf.org>
Content-Type: multipart/alternative; boundary=001a113ab5443a5618052c82bcf5
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/qvqVlvldvAcjwoWHYgEaFe-JFpA>
Subject: Re: [OAUTH-WG] OAuth 2.0 Discovery Location
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: Wed, 24 Feb 2016 11:55:06 -0000

Hi Thomas,

inline:

2016年2月22日(月) 18:44 Thomas Broyer <t.broyer@gmail.com>om>:

> Couldn't the document only describe the metadata?
> I quite like the idea of draft-sakimura-oauth-meta if you really want to
> do discovery, and leave it open to implementers / to other specs to define
> a .well-known URL for "auto-configuration".
> The metadata described here would then either be used as-is, at any URL,
> returned as draft-sakimura-oauth-meta metadata at the RS; or as a basis for
> other metadata specs (like OpenID Connect).
>
With draft-sakimura-oauth-meta's "duri" and the "scope" attribute of
> WWW-Authenticate response header, you have everything you need to proceed
>

Yup. That's one of the requirements to be RESTful, is it not?

In OAuth's case, the resource and the authorization server are usually
tightly coupled. (Otherwise, you need another specs like UMA.)
So, the resource server should be able to tell either the location of the
authz endpoint. In some trusted environment, the resource may as well
return the location of the authz server configuration data. In these cases,
you do not have to decide on what .well-known uri as you say. This frees up
developers from configuration file location collisions etc. We should
strive not to pollute the uri space as much as possible.


> (well, except if there are several ASs each with different scopes; sounds
> like an edge-case to me though; maybe RFC6750 should instead be updated
> with such a parameter such that an RS could return several
> WWW-Authenticate: Bearer, each with its own "scope" and "duri" value?)
>

Yeah, I guess it is an edge case. I would rather like to see these authz
servers to develop a trust framework under which they can agree on a single
set of common scope parameter values.

Cheers,

Nat


>
> On Fri, Feb 19, 2016 at 10:59 PM Justin Richer <jricher@mit.edu> wrote:
>
>> The newly-trimmed OAuth Discovery document is helpful and moving in the
>> right direction. It does, however, still have too many vestiges of its
>> OpenID Connect origins. One issue in particular still really bothers me:
>> the use of “/.well-known/openid-configuration” in the discovery portion. Is
>> this an OAuth discovery document, or an OpenID Connect one? There is
>> absolutely no compelling reason to tie the URL to the OIDC discovery
>> mechanism.
>>
>> I propose that we use “/.well-known/oauth-authorization-server” as the
>> default discovery location, and state that the document MAY also be
>> reachable from “/.well-known/openid-configuration” if the server also
>> provides OpenID Connect on the same domain. Other applications SHOULD use
>> the same parameter names to describe OAuth endpoints and functions inside
>> their service-specific discovery document.
>>
>>  — Justin
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>