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
___
OAuth mailing list
OAuth@ietf.org
https://www.ietf.org/mailman/listinfo/oauth
