Re: [OAUTH-WG] WGLC on draft-ietf-oauth-reciprocal-04

George Fletcher <gffletch@aol.com> Fri, 20 September 2019 15:15 UTC

Return-Path: <gffletch@aol.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 7C514120844 for <oauth@ietfa.amsl.com>; Fri, 20 Sep 2019 08:15:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.997
X-Spam-Level:
X-Spam-Status: No, score=-1.997 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, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=aol.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 MBriSb_kuAj9 for <oauth@ietfa.amsl.com>; Fri, 20 Sep 2019 08:15:49 -0700 (PDT)
Received: from sonic304-9.consmr.mail.bf2.yahoo.com (sonic304-9.consmr.mail.bf2.yahoo.com [74.6.128.32]) (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 A342112083D for <oauth@ietf.org>; Fri, 20 Sep 2019 08:15:45 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1568992544; bh=JoiT8YtNSH/XLf2HOHJCb7GgtkjYxfkP5PLzyh+huIk=; h=Subject:To:References:From:Date:In-Reply-To:From:Subject; b=A4ZxmxsglKxjnf08cM2HdGVzK3bIRQu60T9Zm46Qg+k0BiMW00ZGeyVaMuXxaIKtfwVQKvfIbKCl3i2p8vOUjSVMQkadxE7ZD5rysIGzSxRVqkRKpFoLM8CiM42mIJef3OoZAWgcAN/MssYBQOYKu+FVjh/9NNF/WEdckPfmqLNEMHpjx15EVt4g8oW4LD/XKhvygNs3fgAwuh0HGumRQ3481rxeLfUCFovALo009Xo7OBKWrKPcASnR0fYeFtKZBzkbKIsOQ3r+G6Bh8O/r8Knto/xM41QRmhmjTIVpigO0q/GAzo5JgMzq6QPSr6a+39hZVSlS8OQMVWf3KbHlOg==
X-YMail-OSG: twYuw24VM1mhkJbmwAgwe.DTfoNvSHru8bioL4p378B5sguyM5Cqz9ONEQuwh1s iP6N6rYIomMmUoo1qrgXppzsP0_cER_09.JA7oJNNPbO236yR.V3FbBC3sO5W2a4B9WKFXoad85D homxNDHvJ30.2ph0.wNey.8jbBpZJNwWFjNnAdZfJpjoTHzVE19bw7P.frohLgLIobTMptfNuOpi zy8DxSvJAdSS0SW36NWBGux4NIGls9u87sWuP1EYl1Uf5K4qqDMTWGzn8Qi7NJrtnYlBJqFESs.J oJyVU_aG9fn5qNd3hAQmNduFbpK1C11wW5ayhOLGF8StkPF4KRaO79f6smfvDcfW1vFhm2Y0ipBi zYYOy0mSvefbZZTxmW0q_6OxqooO_uvIfvEsgwaNuvr5UH718JHYa8vI2zftPXWvbkhWpV8mBQey 1U30XRYDHwgeJpM8LMfTDJsZg0AyHnI_VhGK_SuvJNe_sumHEIwmZ8vZMxsSusR6N3QK3jgpIEZK VO7rX8MAjCcNSpD8Ws8PRs5nWsuQ2RJPEb3WKqHvy0d3VIRqSEFCii0Nwz7Tg_sI4IlqkedvCrGY 9OSL4H9Cs7_vHP4R7IR_HlwHJYP6RPdDeFkhGAwFhhfQIEteZFJHqyUZdBn3kD1Bm4dJbY4nonD3 b3ISQjjo62Y9KkE_TDXMPyzc0MZ1NhOG1zqrSx__tor4am1_U_53B6lYaZRgUAOQYXDPw4OQKjzD 8rEZDAUEUMx3OK56ThlcJHT1iZjuLELK3IYIkqxEPIlwRhpuAbCyqkidzNeyoEMqV.Al3b_wdek6 clOCiHNJpILJJ8aGD5e0VtNzTJhOoexplfXvNKSD8T.WDUF1pZfHBUh0NOAWQ3fw7Y.Dgebbz3mZ hgXSJlKpNt0V_OspmM4fKmnDmwIIfFdPYQbwMGDgD7cf2UIIN6D9k6x_MAbEFQdWdIhj19d2PECX Khr9xNxJNYsFtOplJ7n3BxazReytJuwwTfj7fxedfxKAeXMy0J4Akvo.SzadY3ivjd_Ny_OEnkv. tdRPoBg86JUZsdz_xWi4Hybe.mcXBQUMfT_nsOlRfnn0TAi5b1xgdNNf2EFQIUSCABK8Qaz_N.Se 8vpOgnSFPUObKkuI1VpnZETV2Q7ESSJ8e84UJL6NBTxvpwFDYrgnZZntaBLMwr_IHVnNDwfT7aDN L6GpkYSQSaH.DrtK4MHHK9cqFiJCe28a0xvqNiq9wfsu6stpaNxegFc9CrBphV3ZnJSrQVVqC25Q IUswpLLmi3HPeC4fj.XSi9jhDYHZKEhgMiqyd1btu1rGCYASpAHeDY72tMFhNbCw9ZA--
Received: from sonic.gate.mail.ne1.yahoo.com by sonic304.consmr.mail.bf2.yahoo.com with HTTP; Fri, 20 Sep 2019 15:15:44 +0000
Received: by smtp432.mail.bf1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 4e9bc8842aecb49f9962ce1571b4fa59; Fri, 20 Sep 2019 15:15:41 +0000 (UTC)
To: Rifaat Shekh-Yusef <rifaat.ietf@gmail.com>, oauth <oauth@ietf.org>
References: <CAGL6ep+0Pit+=LUBUBazCQFoUWMLv1Q1CsdeJzj9KVpNDux0hw@mail.gmail.com>
From: George Fletcher <gffletch@aol.com>
Organization: AOL LLC
Message-ID: <b6d007ec-09b4-4a90-b38a-12f3a69d31a9@aol.com>
Date: Fri, 20 Sep 2019 11:15:40 -0400
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.9.0
MIME-Version: 1.0
In-Reply-To: <CAGL6ep+0Pit+=LUBUBazCQFoUWMLv1Q1CsdeJzj9KVpNDux0hw@mail.gmail.com>
Content-Type: multipart/alternative; boundary="------------7C74860EAD37F8CDF825521B"
Content-Language: en-US
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/bzzk_oOC5q40rzGVjZcKwixV9fo>
Subject: Re: [OAUTH-WG] WGLC on draft-ietf-oauth-reciprocal-04
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: Fri, 20 Sep 2019 15:15:54 -0000

Reciprocal OAuth - draft 04 Feedback

2.1 Reciprocal Scope Request
-- The spec assumes the reader has an strong understanding of RFC 6749 
and just references sections. More prose should be added to get the 
reader a better understanding of what is happening and then reference 
the normative text in RFC 6749.
-- How does Party B know that it should return the "reciprocal" claim in 
the access token response? More non-normative text should be added to 
describe how the flow is even established (or maybe that how "reciprocal 
oauth" is in play is out of scope for the specification)

"party B MAY include an additional query
 ???? component in the redirection URI to indicate the scope requested in
 ???? the reciprocal grant:"
 ???? -- This isn't an "additional query component" but rather an 
additional claim in the access token response.

"reciprocal OPTIONAL"
 ???? -- I'd re-phrase the description for "reciprocal OPTIONAL" to be 
"The set of scopes Party B requires the resource owner to authorize for 
Party A to access Party B's resource"

"???? If an authorization code grant access token response per [RFC6749]
 ???? 4.2.2, an example successful response (with extra line breaks for
 ???? display purposes only):"
 ???? -- An example successful reciprocal oauth access token response for 
the authorization_code grant flow per [RFC6749] 4.2.2 (extra line breaks 
for display purposes only)
 ???? -- 4.2.2 is the Implicit flow and yet the text references the 
authorization_code flow

"???? When party B is providing an authorization response per [RFC6749]
 ???? 4.1.2, party B MAY include an additional query component in the
 ???? redirection URI to indicate the scope requested in the reciprocal
 ???? grant."
 ???? -- I would explicitly call out that this is for the "implicit" flow. 
Given that in many cases the implicit flow is NOT recommended as a best 
practice, I would recommend text to describe in what circumstances it is 
safe to use the implicit flow with reciprocal OAuth.
 ???? -- RFC 6749 4.1.1 is the authorization_code flow so I'm confused as 
to what the additional "query" component is. In fact 4.1.2 is the 
callback URL with the code and state parameters. Is the spec suggesting 
that the reciprocal claim be added as a query parameter to that flow 
rather than the access token response?

2.2 Reciprocal Authorization flow
 ???? -- This section only references the authorization code flow. Does 
that mean that reciprocal OAuth only works with the authorization code 
flow and not with implicit? The first part of the flow can use implicit 
but not the second since it is all back channel? Some text addressing 
this would be helpful.

2.2.2 Reciprocal Authorization code
 ???? -- What is the expectation if the resource owner does not approve 
all the scopes requested by Party B? Does this follow the OAuth2 model 
that Party B obtains the list of scopes granted from the access token 
response after presenting the code provided by Party A?

"token endpoint authenticating"
 ???? -- are all forms of client authentication allowed? or just those 
specified in RFC6749?

"access_token REQUIRED"
 ???? -- formatting is incorrect

"???? Party B MUST respond with either an HTTP 200 (OK) response if the
 ???? request is valid, or an HTTP 400 "Bad Request" if it is not."
 ???? -- what form do the errors take? Should all applicable errors of RFC 
6749 section 5.2 be allowed?
 ???? -- I'm assuming the error response should be JSON compliant with 
section 5.2

3 Authorization Update flow
-- How scopes are managed and communicated in both the update and 
section 2.2.2 is unclear and should be specified

No Security Considerations section
-- this definitely needs to be added


On 9/6/19 2:41 PM, Rifaat Shekh-Yusef wrote:
> All,
>
> We are starting a WGLC on the Reciprocal OAuth document:
> https://datatracker.ietf.org/doc/draft-ietf-oauth-reciprocal/
>
> Please, review the document and provide feedback on any issues you see 
> with the document.
>
> The WGLC will end 20-September-2019.
>
> Regards,
> ??Rifaat and Hannes
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth