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