Re: [OAUTH-WG] OAuth 2.0 Discovery Location

Nat Sakimura <sakimura@gmail.com> Wed, 24 February 2016 15:52 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 CBAB91A877F for <oauth@ietfa.amsl.com>; Wed, 24 Feb 2016 07:52:02 -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 Q7JgMoINS2E0 for <oauth@ietfa.amsl.com>; Wed, 24 Feb 2016 07:52:01 -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 167C21A1AB2 for <oauth@ietf.org>; Wed, 24 Feb 2016 07:52:01 -0800 (PST)
Received: by mail-qg0-x230.google.com with SMTP id b35so16856859qge.0 for <oauth@ietf.org>; Wed, 24 Feb 2016 07:52:01 -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=2gYPj1GVUyzDy5Cpf3jDMOADmopLwNLNSagbr97Pb/s=; b=d4zxl2aoslbADCy949jmB26A5wXXVy5pZSx0hQvh7SYImoAHPXJojC6WARpySQhuYE ahMTmUldE7KoFuXYjqR9uimChXKikJQuGbmb00veM1BlEzYAW/5PpXJzOtjIqU9Sd7e/ TlDWvAatwbvCyoveADmR52PzsmRdSz+Vn0biXuVx+XLLHyWChJpLelf5cTQWvJjzqDPm lbhCVlK0xHGJ6gFP3+6j/VPR+3uo8uXgHsZ9zmsySKhN+gNekVaARsjKQFGN+NShGbwj gXgvMPb4Myo9vgqa0zm5x36J25DCxFd3SicLZZmBf4NLTOHxgtHECFl5sJqbEzFvdgS0 MoKg==
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=2gYPj1GVUyzDy5Cpf3jDMOADmopLwNLNSagbr97Pb/s=; b=TXy0nNBXSRVAfCZy6UwyHUmaYfDLsnW6FE/x1QZXT8UFbNC3rNm7qxG7jft6/sQ0q5 f7oU3ZaM8MQixxAQdLjU1kB57t1zZvk2wF3EEV6nxsjlL/A9FECuApDrLGyA/75WUIsf jUNEmEFMc6UcDjOKVuy/IXuj+y0rm1FlOfL0RRD0pA7UsermNa+IKPMnGVwpGtJYNjvt oD5AFC+NtRMp8+CKWWUIEyo25pCCYd/L/keSDzcTcXeoMS8MzZrC3AMO65m/fzhpnS1e fGViI6S8s97qeRWK+Ghqwzxgi2KztuQMPSI/fg09zD2OAYBppXjU9iKa1nJIgTrv9kQf MIZA==
X-Gm-Message-State: AG10YORvy18uZGg0gBy39x7YF8O8ZCtIXWSAjmILx+q5H1VjN+ini+ENJH2xKKoeO/F1o1MRnMQNkdYi+xcn6w==
X-Received: by 10.140.221.16 with SMTP id r16mr22222430qhb.67.1456329119803; Wed, 24 Feb 2016 07:51:59 -0800 (PST)
MIME-Version: 1.0
References: <E3BDAD5F-6DE2-4FB9-AEC0-4EE2D2BF8AC8@mit.edu> <CAEayHEMspPw3pu9+ZudkMp9pBPy2YYkiXfPvFpSwqZDVyixWxQ@mail.gmail.com> <CABzCy2CpSB2Nrs-QoaEwpqtG4J8UNeAYNy1rion=mp5PQD2dmg@mail.gmail.com> <CAEayHEN460jz4BSoxKZ9t7JLc016oAeFkWkcxTD0Gte=Ed141w@mail.gmail.com>
In-Reply-To: <CAEayHEN460jz4BSoxKZ9t7JLc016oAeFkWkcxTD0Gte=Ed141w@mail.gmail.com>
From: Nat Sakimura <sakimura@gmail.com>
Date: Wed, 24 Feb 2016 15:51:49 +0000
Message-ID: <CABzCy2CSiNdiSZureSR8rxu4bRh+wcknZur5XcWqSQnXAurctw@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="001a11378416dcb0db052c860b50"
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/bjXuFi8tgEYcsY9dRcKOmgmvWho>
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 15:52:03 -0000

Right. As there can be multiple WWW-authenticate header, it is doable that
way. Maybe that's better in this respect, though it becomes a bit different
than other metadata. Alternatively, the scope can be added as a parameter
in the auri Web  Link header.
Good things about the Link Header is that you can just configure the web
server config to return them. There is no code needed.

2016年2月25日(木) 0:01 Thomas Broyer <t.broyer@gmail.com>:

> Hi Nat,
>
> On Wed, Feb 24, 2016 at 12:54 PM Nat Sakimura <sakimura@gmail.com> wrote:
>
>>
>> 2016年2月22日(月) 18:44 Thomas Broyer <t.broyer@gmail.com>:
>>
>
>>
>>> (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.
>>
>
> Well, except that adding the "duri" and "auri" metadata links to the
> "WWW-Authenticate: Bearer" response header(s) would easily solve those
> issues (without judging here whether they're edge-case or not), and I don't
> really see any other use-case for that metadata outside the unauthorized
> use of a resource (your draft admits it's the "typical use-case").
>