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

Ryan Kelly <> Mon, 25 November 2019 03:18 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 6A69C1201EF for <>; Sun, 24 Nov 2019 19:18:12 -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 Itkn4d1rGPkr for <>; Sun, 24 Nov 2019 19:18:09 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4864:20::a2f]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 157461201DE for <>; Sun, 24 Nov 2019 19:18:08 -0800 (PST)
Received: by with SMTP id j84so3080236vkj.6 for <>; Sun, 24 Nov 2019 19:18:08 -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=eoCy9QaHj35kARpMajJXE2K6XtJPcahhN5h6CA0A5tw=; b=fXmPybRxBIWGmH3ywX4qlfiAqlOv8rrNEr0y5fmdiMwZi27CC3NNfsxYUkO4KI1tAJ EqID5bYvKpoZO3ceosavIhJDiDVPjbTInioipqJ/z7We7Q97A/vmjlVlYTYVr889AP0L f3dpiacLvsQw2WNkXrZSsOu0ba02770U0DP+Y=
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=eoCy9QaHj35kARpMajJXE2K6XtJPcahhN5h6CA0A5tw=; b=rWKJEGa/dXlaVFIxHmYMYq9NKZfos+8Ln9cpqf/4afksewovwNcut2LcUjxDWv80Ga NAXnHLj42PWBuEz2RcDGm7UlO+GbseOcmlGCXTDlliJ4ZqxXqtNcAOmVqIDlO6TcWQrC Z+sq4wnt0BMrLj8GqRqy4gG77e8eMOLvqNC0UCuct8cRETctU2Q/QzjMuK+8EYl7vmAB J8KUzN6lgft1h7E+xCegyFk1sgy5Qrkp+JwKbnOv3KthAxCufMfopVWo4njWqa51+zYj 6f10Rh8sqxC/vebkALbkWfa5ZdkPMRczrpe2gR1bJrxvkK/dhQMpHW5FTFLcK1YqQQVk GMdA==
X-Gm-Message-State: APjAAAVIGtYr6TbSxE9oOOuidqNEErjq4lxnahG53idriN76ThxzKayC 2uvTbuO9jVEaKO5tKqg7RBx6NpOrlluNQA6jhRz8MMBbwj8=
X-Google-Smtp-Source: APXvYqwXQ9jZs5fPSgXsvSPJZ+FcHGDttFXjaHRT9/jKMs4Gvy0TKbQke1+ClmJCkOato4vWkRftBYlMWBFNaQbetjo=
X-Received: by 2002:a1f:3258:: with SMTP id y85mr16485255vky.7.1574651887893; Sun, 24 Nov 2019 19:18:07 -0800 (PST)
MIME-Version: 1.0
References: <> <> <> <>
In-Reply-To: <>
From: Ryan Kelly <>
Date: Mon, 25 Nov 2019 14:17:56 +1100
Message-ID: <>
To: Torsten Lodderstedt <>
Cc: oauth <>
Content-Type: multipart/alternative; boundary="0000000000006c618c059823367f"
Archived-At: <>
Subject: Re: [OAUTH-WG] 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: Mon, 25 Nov 2019 03:18:13 -0000

On Fri, 15 Nov 2019 at 04:41, Torsten Lodderstedt <>

> > On 14. Nov 2019, at 08:31, Ryan Kelly <> wrote:
> >
> > 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”?
> That’s a very good question. I see to options:
> - those elements are assigned to any access token
> - those elements are assigned to an access token in case there was no
> “resource” parameter included in the token request.
> I’m leaning towards the latter approach.
> > What if the "resource" parameter refers to a value that was present in
> "locations" but not in "resource" during the initial authorization request?
> See above - since locations take precedence, those locations shall match.

Gotcha, thanks. I think this is the part I wasn't clear on regarding the
meaning of "take precedence" at the authorization endpoint, and I wonder if
it can be made more explicit in the earlier section.

> > 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?
> simple string match

Does the AS need to take any particular care about resource names that
might accidentally be prefixes of each other, such as "" and ""?  That seems
really contrived, but perhaps I'm just not creative enough to think of a
more realistic example.

> > * 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?
> What would be the use case for passing an authorization details parameter
> to the token request with a refresh token? The client shouldn’t be able to
> change the authorization details of the underlying grant, so using the
> “resource” parameter to select another subset of the granted authorization
> details should be sufficient.

I was thinking of situations where there might be "high risk" and "low
risk" actions authorized for a single resource server, and the client may
want to make an access token that is scoped down to just the low-risk ones,
to minimize the impact of a potential compromise of that token. But perhaps
that's better dealt with by the work on sender-constrained tokens to reduce
the risk of the token being compromised in the first place.