[OAUTH-WG] draft-ietf-oauth-reciprocal-04 WGLC feedback

[Brian Campbell <[e-mail]>]

I reviewed draft-ietf-oauth-reciprocal-04 and I do not believe that the
document is yet sufficiently mature to send to the IESG.  A (not
necessarily complete) set of comments and feedback follow.

Sections 1 & 2:
I realize this isn't particularly actionable but have to admit that I had a
hard time reading and really understanding the introduction in section 1
and flow in section 2. And that's coming from someone who came to this
document with some general familiarity with OAuth and a rough idea of what
the draft was aiming to accomplish.

Section 2.1:
  "When party B is providing an access token response per [RFC6749]
   4.1.4, 4.2.1, 4.3.3 or 4.4.3, party B MAY include an additional query
   component in the redirection URI to indicate the scope requested in
   the reciprocal grant:"

4.1.4, 4.3.3 and 4.4.3 of RFC6749 are access token responses to
Authorization Code Grant , Resource Owner Password Credentials Grant, and
Client Credentials Grant requests respectively (I did have to look those
up). Which are HTTP responses with JSON in the body. So an "additional
query  component in the redirection URI" doesn't make any sense in that
context. Perhaps it's supposed to be an additional JSON
member/parameter/element (whatever the right term is is with JSON)? But,
that said, does this Reciprocal thing even make sense in response to
Resource Owner Password Credentials Grant, and Client Credentials Grant
requests? But if they do, then what about Extension grants (i.e. SAML, JWT,
device, etc) in sec 4.5?

4.2.1 of RFC6749 is the Authorization Request of the Implicit Grant, which
seems out of place here.

"  If an authorization code grant access token response per [RFC6749]
   4.1.4, an example successful response (with extra line breaks for
   display purposes only):"

I don't think that's a complete sentence.

"   Content-Type: application/json;charset=UTF-8"

I don't believe charset is needed or used application/json.

"     "token_type":"example","

Really? I guess it's not wrong but using a 'real' value for token type
might be easier on readers.

"     "example_parameter":"example_value""

Seems out of place and unnecessary for an example in this draft.

"   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):

   HTTP/1.1 302 Found
   Location: http://example.com/cb#
       access_token=2YotnFZFEjr1zCsicMWpAA&
       state=xyz&
       token_type=example&
       expires_in=3600&
       reciprocal="example_scope" "

RFC6749's 4.2.2 is implicit and the example that follows is implicit but
the text there says authorization code. That text leading up to the example
also doesn't seem to form a complete sentence. A token type of example
seems odd and potentially confusing here too. I don't think "example_scope"
should be quoted in the example but if it really is supposed to be, then
the quotes need to be form-urlencoded (%22).

Should this reciprocal stuff even be defined for the implicit grant? Does
it really make sense? Does the WG want to keep building on implicit?

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

4.1.2 of RFC6749 is the Authorization Response of the Authorization Request
for the Authorization Code Grant flow. Earlier in the same section, I think
the reciprocal parameter is defined for access token responses to
Authorization Code Grant request. So does there need to be two different
ways to send the reciprocal parameter during the same flow? Or maybe I'm
misunderstanding? It's certainly possible as I'm having a hard time
following this section.

Section 2.2:
According to RFC6749, "The token endpoint is used by the client to obtain
an access token by presenting its authorization grant or refresh token."
And in RFC6749 there are defined constructs and semantics for success and
error responses from the token endpoint. However the grant type in section
2.2 of this draft is kind of the opposite of that where the reciprocal
authorization code is being pushed/sent to the token endpoint and nothing
is being obtained/returned in the response to that request. It's also means
the reciprocal authorization code is being delivered to the AS even though
it is intended for the client.

This is arguably an illegitimate use of the given extension points in OAuth
and shouldn't be done or allowed. Off hand, it would seem more appropriate
to have/define a new client endpoint  to receive these pushed reciprocal
authorization codes.  At best it's a major abuse of those extension points
and the document, if it persists in doing things this way (even though I
don't think it should), it needs to have some pretty good explanation for
how and why this one particular grant type completely diverges from what is
defined in RFC6749.

On a slightly more meta level - the client and AS of the respective parties
seem pretty deeply intertwined throughout this draft and I'm having trouble
envisioning how those pieces would actually exist and communicate in a real
deployment. Some more information or guidance or fleshing out around how
this would or could actually work in practice is needed, I think.

-- 
_CONFIDENTIALITY NOTICE: This email may contain confidential and privileged 
material for the sole use of the intended recipient(s). Any review, use, 
distribution or disclosure by others is strictly prohibited.  If you have 
received this communication in error, please notify the sender immediately 
by e-mail and delete the message and any file attachments from your 
computer. Thank you._