Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-03.txt

Ryan Kelly <> Thu, 14 November 2019 07:31 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A33EE120859 for <>; Wed, 13 Nov 2019 23:31:27 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
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: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id tLL9QVWYRUk5 for <>; Wed, 13 Nov 2019 23:31:24 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::e31]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 15D6112011E for <>; Wed, 13 Nov 2019 23:31:23 -0800 (PST)
Received: by with SMTP id j85so3207281vsd.11 for <>; Wed, 13 Nov 2019 23:31:23 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; 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;; 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: <> <>
In-Reply-To: <>
From: Ryan Kelly <>
Date: Thu, 14 Nov 2019 18:31:11 +1100
Message-ID: <>
To: Torsten Lodderstedt <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="000000000000dcd104059749773e"
Archived-At: <>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-lodderstedt-oauth-rar-03.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 14 Nov 2019 07:33:03 -0000


(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.




* 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

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 <>

> 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: *
> *Subject: **New Version Notification for
> draft-lodderstedt-oauth-rar-03.txt*
> *Date: *4. November 2019 at 17:43:01 CET
> *To: *"Justin Richer" <>rg>, "Torsten Lodderstedt" <
>>gt;, "Brian Campbell" <>
> 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:
> Status:
> Htmlized:
> Htmlized:
> Diff:
> 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
> The IETF Secretariat
> _______________________________________________
> OAuth mailing list