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

[Dick Hardt <[e-mail]>]

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/rf
> c6749#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/rf
> c6749#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?



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

 /Dick