Re: [OAUTH-WG] draft-hardt-oauth-mutual-01

[Brian Campbell <[e-mail]>]

Inline also...

On Tue, Jan 16, 2018 at 2:25 PM, Dick Hardt <[e-mail]> wrote:

> Comments inline ...
>
> On Tue, Jan 16, 2018 at 1:11 PM, Brian Campbell <
> [e-mail]> wrote:
>
>>
>> *On client_id:*
>> With the authorization_code code grant (sec
>> https://tools.ietf.org/html/rfc6749#section-4.1.3), the client_id is
>> "REQUIRED, if the client is not authenticating with the authorization
>> server as described in Section 3.2.1."  And Section 3.2.1 (see
>> https://tools.ietf.org/html/rfc6749#section-3.2.1) kinda describes why
>> it is required for unauthenticated clients:
>>
>>    "A client MAY use the "client_id" request parameter to identify itself
>>    when sending requests to the token endpoint.  In the
>>    "authorization_code" "grant_type" request to the token endpoint, an
>>    unauthenticated client MUST send its "client_id" to prevent itself
>>    from inadvertently accepting a code intended for a client with a
>>    different "client_id".  This protects the client from substitution of
>>    the authentication code.  (It provides no additional security for the
>>    protected resource.)"
>>
>> So it's there to let the AS detect code substitution and protect public
>> clients from it. I don't think that the same situation applies to the code
>> that's created and pushed with this reciprocal flow.
>>
>
> The client_id is linked to the access token for reciprocal, and to the
> client secret. The client_id let's the AS know which secret it should be
> comparing, and to verify the access token really does belong to the
> client_id.
>
> Is there a reason you would NOT want to pass the client_id?
>
>
I was aiming for consistency with of the other token endpoint calls that
don't require the parameter when the client id can be found out from
whatever method the client is authenticating with. That's all. But I guess
it really doesn't hurt either so requiring it is fine too. Sorry for
dragging that all into a rabbit hole.



>
>
>>
>>
>>
>> *On the response:*
>> The extension grants section (see https://tools.ietf.org/html/rf
>> c6749#section-4.5) of OAuth says,
>>
>>    "If the access token request is valid and authorized, the
>>    authorization server issues an access token and optional refresh
>>    token as described in Section 5.1 <https://tools.ietf.org/html/rfc6749#section-5.1>.  If the request failed client
>>    authentication or is invalid, the authorization server returns an
>>    error response as described in Section 5.2 <https://tools.ietf.org/html/rfc6749#section-5.2>."
>>
>> So I'd sorta expect the reciprocal code grant to try and comply with
>> those responses. Mostly for consistency and, while it doesn't exactly fit,
>> for what is already there like error codes.  Or give more detail about why
>> it's doing something different and how different looks (like the response
>> body). But maybe that's overly pedantic and just 200/400 are enough. I
>> dunno.
>>
>
> But it is not an access token request, and I think having it look like an
> access token request will be confusing to developers. It is the opposite of
> an access token request. This really is a back channel version of the
> Authorization Response https://tools.ietf.org/html/rfc6749#section-4.1.2,
> which of course has no response codes.
>

Perhaps a little more explanation along those lines would be useful. I
agree with the sentiment. I was just trying to stay within the lines of the
OAuth extension framework. But, yeah, this flow is different.



>
>  /Dick
>
>

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