Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-03.txt
Ryan Kelly <rfkelly@mozilla.com> Thu, 14 November 2019 07:31 UTC
Return-Path: <rkelly@mozilla.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 A33EE120859 for <oauth@ietfa.amsl.com>; Wed, 13 Nov 2019 23:31:27 -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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=mozilla.com
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 tLL9QVWYRUk5 for <oauth@ietfa.amsl.com>; Wed, 13 Nov 2019 23:31:24 -0800 (PST)
Received: from mail-vs1-xe31.google.com (mail-vs1-xe31.google.com [IPv6:2607:f8b0:4864:20::e31]) (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 15D6112011E for <oauth@ietf.org>; Wed, 13 Nov 2019 23:31:23 -0800 (PST)
Received: by mail-vs1-xe31.google.com with SMTP id j85so3207281vsd.11 for <oauth@ietf.org>; Wed, 13 Nov 2019 23:31:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=mozilla.com; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l41jEYYoMfF2TR4TEW0gBBb0UPUWP03+ViDon6tZ2uk=; b=QSC5pGAqZVJi02oo5PIPFvPVe+N/nr5GQbT1O+d1aTajnj2wawFitVqC2E86in+tsO +F+yC8VHr77t3CbqUc2JZiWECbChYu70RuV1fe/mRFEcx0ubwjwE0X47t8Y+qs3OEGpy k/MbS8f/xwaK7cYIhqsZfR3gfpTtsmhGazJq0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l41jEYYoMfF2TR4TEW0gBBb0UPUWP03+ViDon6tZ2uk=; b=s55R8q2M7pXYi6g04k/6+0ytTpIiKvXmTMi07thMv3jOuTsEgYHvkVF87tuuGlu1zR 2LzI26zxk2AmTEWrnFI406+1nMCaGczyBtSztJ00TlBNJg1McY82GEkQwYvYvbWSfduf U9wAV4tk2HbFbppuUcb6Qc2d5EFx7S5+MUxUvj8vfL+xMSX4dpJ+d3yAXxHucdUWiw+H JKBDtdhP0urkFpkJeTU/5rg+xqq1H8yBTthTy9Y063nmvauvommWTYdmWzdIgAgkdguy 3J6FL6BnHKnUZH+vybihhl0Zpw9H08+SOQs4hPZKFoNyHYUVsOsynRn83OZX4AMkrlVj xLcQ==
X-Gm-Message-State: APjAAAX9svduGUGOk6EkuaNBMbiLKSlcHckf5nLljeP646gnP2uEb86P yzDQmc6JL5ih1F1d+CXY0Z+HvkfvTimVWb46k/8df0VYQx4=
X-Google-Smtp-Source: APXvYqwLdjExp8BrQ/n/xYNjmjY0QRNKGNqaR2jCoxEa6PKkbyUWf2GBCjoKgVxdZtU7N5vlK8VqQy52p18cv0hY0Zc=
X-Received: by 2002:a67:e055:: with SMTP id n21mr214014vsl.93.1573716682912; Wed, 13 Nov 2019 23:31:22 -0800 (PST)
MIME-Version: 1.0
References: <157288578137.16651.11095431477669936196.idtracker@ietfa.amsl.com> <6FC2E5A2-5399-46A5-8DF1-988D6E1942DC@lodderstedt.net>
In-Reply-To: <6FC2E5A2-5399-46A5-8DF1-988D6E1942DC@lodderstedt.net>
From: Ryan Kelly <rfkelly@mozilla.com>
Date: Thu, 14 Nov 2019 18:31:11 +1100
Message-ID: <CAB3n-Ya+WMrNdtBMfciCOQipjHfounNo0MThJObGmS7_XfzJmA@mail.gmail.com>
To: Torsten Lodderstedt <torsten@lodderstedt.net>
Cc: oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000dcd104059749773e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/fLJq34nmwTWpmJY7CkoRjzU6N8o>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-03.txt
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: Thu, 14 Nov 2019 07:33:03 -0000
Hi, (I've been lurking on this list for a while but I don't think I've posted here before, so...hi! I'm Ryan and I work on Firefox Accounts and related systems at Mozilla). Thanks for working on this! It's an interesting and timely read for me as we're starting to bump up against some limitations of the `scope` parameter. I have some initial feedback below, and will hopefully be able to send through more as I dig in in more detail. Cheers, Ryan --- * Section 2.3: Relationship to "resource" parameter The potential interactions between "locations" and "resource" seem very complex and I'm not at all sure I understood them. Paragraph 2 says that "locations" should take precedence over "resource" when both appear in the authorization request, but doesn't explain what this means in concrete terms. Can a client make a subsequent token request that passes a value from "locations" in the "resource" parameter, even though it wasn't specified in the "resource" parameter of the authorization request? In Paragraph 3, how should the AS deal with authorization details objects that do not have a "locations" element? Should they be included regardless of "resource"? What if the "resource" parameter refers to a value that was present in "locations" but not in "resource" during the initial authorization request? The "matches as prefix of one of the URLs" part of Paragraph 3 seems a bit unclear as well, given that there is no requirement that the "locations" elements be well-formed URLs. Is this is simple string prefix match, or some sort of path matching based on the components of the URL? As a purely stylistic comment, I also found the example in this section a bit artificial - I struggled to think of *why* a client might request an authorization code with one set of authorization details, but then use the "resource" parameter to immediately reduce them when exchanging the code for a token. I wonder if using a refresh_token grant as part of the example could help make it clearer, similar to what's done in oauth-resource-indicators-08 Section 2.2. * Section 3: Using "authorization_details" Intuitively, I would expect to be able to use "authorization_details" in a token request using grant_type=refresh_token, in the same way that I can specify "scope". Section 3 doesn't seem to take a definitive stance on this - IIUC Section 3.1 doesn't apply because this is not an authorization request, and Section 3.3 seems to discourage it in favour of using the "resource" parameter. Do you intend for this parameter to be allowed in conjunction with a refresh token? On Tue, 5 Nov 2019 at 03:48, Torsten Lodderstedt <torsten@lodderstedt.net> wrote: > Hi all, > > a new (significantly enhanced) revision of draft-lodderstedt-oauth-rar was > just published. Here is the list of changes: > > • Reworked examples to illustrate privacy preserving use > of authorization_details > • Added text on audience restriction > • Added description of relationship between scope and authorization_details > • Added text on token request & response and authorization_details > • Added text on how authorization details are conveyed to RSs by JWTs or > token endpoint response > • Added description of relationship > between claims and authorization_details > • Added more example from different sectors > • Clarified string comparison to be byte-exact without collation > > Thanks a lot for all contributions and the review feedback so far. I will > present this draft in Singapore and would appreciate if the WG would > consider this draft for adoption. > > best regards, > Torsten. > > Begin forwarded message: > > *From: *internet-drafts@ietf.org > *Subject: **New Version Notification for > draft-lodderstedt-oauth-rar-03.txt* > *Date: *4. November 2019 at 17:43:01 CET > *To: *"Justin Richer" <ietf@justin.richer.org>, "Torsten Lodderstedt" < > torsten@lodderstedt.net>, "Brian Campbell" <bcampbell@pingidentity.com> > > > A new version of I-D, draft-lodderstedt-oauth-rar-03.txt > has been successfully submitted by Torsten Lodderstedt and posted to the > IETF repository. > > Name: draft-lodderstedt-oauth-rar > Revision: 03 > Title: OAuth 2.0 Rich Authorization Requests > Document date: 2019-11-03 > Group: Individual Submission > Pages: 30 > URL: > https://www.ietf.org/internet-drafts/draft-lodderstedt-oauth-rar-03.txt > Status: > https://datatracker.ietf.org/doc/draft-lodderstedt-oauth-rar/ > Htmlized: https://tools.ietf.org/html/draft-lodderstedt-oauth-rar-03 > Htmlized: > https://datatracker.ietf.org/doc/html/draft-lodderstedt-oauth-rar > Diff: > https://www.ietf.org/rfcdiff?url2=draft-lodderstedt-oauth-rar-03 > > Abstract: > This document specifies a new parameter "authorization_details" that > is used to carry fine grained authorization data in the OAuth > authorization request. > > > > > Please note that it may take a couple of minutes from the time of > submission > until the htmlized version and diff are available at tools.ietf.org. > > The IETF Secretariat > > > _______________________________________________ > OAuth mailing list > OAuth@ietf.org > https://www.ietf.org/mailman/listinfo/oauth >
- [OAUTH-WG] Fwd: New Version Notification for draf… Torsten Lodderstedt
- Re: [OAUTH-WG] Fwd: New Version Notification for … Ryan Kelly
- Re: [OAUTH-WG] New Version Notification for draft… Torsten Lodderstedt
- Re: [OAUTH-WG] New Version Notification for draft… Ryan Kelly
- Re: [OAUTH-WG] New Version Notification for draft… Brian Campbell