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

From: Rifaat Shekh-Yusef <[email-masked]>
Date: Fri, 6 Sep 2019 14:41:53 -0400

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

---

From: George Fletcher <[email-masked]>
Date: Fri, 20 Sep 2019 11:15:40 -0400

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:
> Please, review the document and provide feedback on any issues you see 
> with the document.
>
> ??Rifaat and Hannes
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Dick Hardt <[email-masked]>
Date: Fri, 20 Sep 2019 12:03:29 -0700

Brian / George: thanks for the detailed critique of the draft -- much
appreciated.

Given all the feedback, it is clear the draft needs more work before
submitting to the IESG.

Unfortunately, it will be a few weeks before I have time to review and
respond to your comments.

ᐧ