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

Torsten Lodderstedt <> Thu, 14 November 2019 17:41 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id F25C5120A85 for <>; Thu, 14 Nov 2019 09:41:20 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2
X-Spam-Status: No, score=-2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, 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 (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id 6c5Qj1F8MG-s for <>; Thu, 14 Nov 2019 09:41:17 -0800 (PST)
Received: from ( [IPv6:2a00:1450:4864:20::42d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 34B15120932 for <>; Thu, 14 Nov 2019 09:41:16 -0800 (PST)
Received: by with SMTP id b18so5980310wrj.8 for <>; Thu, 14 Nov 2019 09:41:15 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=from:message-id:mime-version:subject:date:in-reply-to:cc:to :references; bh=s0vgGovA7R7Q7JDsV21PNodWtifiwyseEBNSSbAnCDg=; b=B0Zkt2b8QFLEKfyDnnGKtazSuCVfDZOVC0/SeGRswlL2gKYIZCduID5Hp7e0O/NEun hXrRCAw9EGaQgx7j/+O5dDcLfYSciutBBdfCxoywVSTDazR0KfNz24/Ee01xMrVpEPnr wVnjwtrs01i7fhz6bVDZKuSKQUqpdm2flJF79L5qT3iLHOH2rQxioiay6GW5ZbX//Sdx oHy2eRKA01+0vlijYqUldoRMUufRRkro3V4LsawFn3IxN0MyV3N5yAwY/ULzpLJLBADC tfzzVNx3oVs9sxfZzFIP4hfxm1Vb3VECZ6Y+k++c7Mzyqa1bMia4rzpUw/kx1jW3KHRD pdXw==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:from:message-id:mime-version:subject:date :in-reply-to:cc:to:references; bh=s0vgGovA7R7Q7JDsV21PNodWtifiwyseEBNSSbAnCDg=; b=eREYCdESRVTHkJ5ln/8bfc5gCqxagdt9ic+u6iBbyzZXdjCXtI5IQiSzSj125ljCoE DnjWGDhXHy9jkmuvG07QdxMyueaQgiR3ahLeOTBcRcf5P0+TbfV9XHBTdjxr0eDWV2s5 oBtn8BdTzW/u36Xn0NsKrMmcEtChV8dl5yV5CI2xLaZMImD/iD1vr5xMsQQrLNisihZ+ mKFB2JszepO0BkJ7ZMneCuYMyrzJOZiQr7Skta7WAIvphIZoPK0RbcdlJ3zFFJix5YPq bqPKMWFH8w1jF1rq1aEVRLtXbS7c7z1yU3cdLzg8AUmMMWWE5NBiIWi3kZ71EIcAHrLr P+Ug==
X-Gm-Message-State: APjAAAWJVZLm3I1d/R90aRO8zcA9WaS/7FcigoSNc/WVcAfgB3Gg0Umq p+vidHSp8oGOZp80PzK/o+yr09wGypcE1g==
X-Google-Smtp-Source: APXvYqxSiMrR+jfwIGrqqbrgD/ri+y6jxl44oFFOyGTeHS6N+oYNYw3vOEmWxx5e9+IlxlTXF9+UvA==
X-Received: by 2002:a5d:4a50:: with SMTP id v16mr8952358wrs.85.1573753274231; Thu, 14 Nov 2019 09:41:14 -0800 (PST)
Received: from [] ( []) by with ESMTPSA id i71sm9424231wri.68.2019. (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 14 Nov 2019 09:41:13 -0800 (PST)
From: Torsten Lodderstedt <>
Message-Id: <>
Content-Type: multipart/signed; boundary="Apple-Mail=_23D0E45B-4662-4267-A204-4B24925B26B4"; protocol="application/pkcs7-signature"; micalg=sha-256
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3601.0.10\))
Date: Thu, 14 Nov 2019 18:41:12 +0100
In-Reply-To: <>
Cc: oauth <>
To: Ryan Kelly <>
References: <> <> <>
X-Mailer: Apple Mail (2.3601.0.10)
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: Thu, 14 Nov 2019 17:41:21 -0000

Hi Ryan,

> On 14. Nov 2019, at 08:31, Ryan Kelly <> wrote:
> 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 a lot for posting your feedback! 

> Thanks for working on this!  It's an interesting and timely read for me

Good to hear we are just in time :-)

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

please do

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

I see. This is related to the section 2.1. of draft-ietf-oauth-resource-indicators, where the use of the “resource” parameter in the authorization request is described as 

"When the "resource" parameter is used in an authorization request to
   the authorization endpoint, it indicates the identity of the
   protected resource(s) to which access is being requested.”

The “locations" elements of the authorisation details objects do the same but on a more detailed level. That’s why this information shall take precedence. Given there could be authorisation details objects that do not contain a locations element, it nevertheless could be useful to use “resource” in parallel.

However, one could also argue that client using locations should do you consequently and not use the “resource” parameter in the authorization request.

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

yes. At the token endpoint, the “resource” parameter is the only way to describe what resource server the client want to use the token at.

draft-lodderstedt-oauth-rar does not use an alternative parameter at the token endpoint, it in some ways utilises the existing “resource” parameter. Or put the other way around, it makes the semantics of the “resource” parameter more explicit. 

Where draft-ietf-oauth-resource-indicators states

   the extent possible, when issuing access tokens, the authorization
   server should downscope the scope value associated with an access
   token to the value the respective resource is able to process and
   needs to know.” 

draft-lodderstedt-oauth-rar makes that more explicit/transparent by requiring 

"The AS will select all authorization
   details object where the "resource" string matches as prefix of one
   of the URLs provided in the respective "locations" element."

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

> 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

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

I think asking for an access token for a single resource server is just consequent, since it ensures all access tokens are tightly audience restricted. But you are making a good point, a further example utilising the refresh token to obtain another access token for the other resource server will certainly make things clearer.

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

best regards,

> On Tue, 5 Nov 2019 at 03:48, Torsten Lodderstedt <> 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:
>> 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" <>et>, "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