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

Dick Hardt <> Wed, 17 January 2018 02:05 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 0C47312EC20 for <>; Tue, 16 Jan 2018 18:05:32 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id xbeTmZDLk6oL for <>; Tue, 16 Jan 2018 18:05:29 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22d]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 9200B12EBBF for <>; Tue, 16 Jan 2018 18:05:29 -0800 (PST)
Received: by with SMTP id j3so10698796pfh.8 for <>; Tue, 16 Jan 2018 18:05:29 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=H3KlzOqi2czC7sBbUfiGpaN9/tdheWSGf6FLfmD18KY=; b=XbD48DZLLb14a8CDLyrHTDL7Pve6fjioJ02saj5oddMTUSgknw+WjRi+IwlDR8Jmcv b3nPV247dcw+m6FN5hzOeA+n3OPaaOLijJeHAh5mTdD5qYZpKatQcrTgMrFjTGTmtQIc ogw0iJWgDmCBQ+qCAQHJC2/Se6t1VPQMFABzl03CyzYLX29dEIkB0QaJy1jyTtBMIHCW 8FqYpYKxmDsApsM6Z34Eh8UAbHRI7r/XhnFnkbCdOzdG2jTxKxCW9xwjlAsZhpMUcDU+ Et2IUcQcB1IIG2Szfn2He+ZDF79froL7j/rBsXRJvPCB1Ve8tjpbBMiH3bc52DNZGIIK YMdQ==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=H3KlzOqi2czC7sBbUfiGpaN9/tdheWSGf6FLfmD18KY=; b=heC/u8XOHScmLXTidOlAhIUigc5kvLcIlMbu5DM+iNn0SwEcrGa5+Y08TWzCOJlOxz A7iG9lKlIt0EYiKMRtyvbLa3GladkN8FjHHy/EjYwLl8UaLMxFjQMGfqN/RaLGCLdrOy vOUgfGjDlQ6hQE+GM6u+WT3c8MEZ3o9EeaSWPV0NOKEGO11fKN5WMClpY+qJ67fMu1d/ DG7v7obSXjNa39R6O+UZ60fvVGMv1Jonzc1Picyi9g0V+QTx4zCFfInE0pkaLCTuP8xD gY2DlWh2dkZ8g25Mo5JOzSThgvbyiND9F2m6XJY7nwOpF9sdik/InTi6Vjfnw8P32oJE llVg==
X-Gm-Message-State: AKGB3mIJ/FXJqO8GMLH/lctRlA29HOQHQsCp5yn02Iuw/+4SKC6H7uDV /hEiNURifDEBGxRuZrYo6GLapcZxJfxDoIwf5iE=
X-Google-Smtp-Source: ACJfBoslomd8bNqO8i6AXUayv8zSth6NUe9+cm70Lipomgy/jkhRqCBFqPvS8hYtgQMGR2ZoAuvmU0Kw9V6x+lleNs0=
X-Received: by with SMTP id r83mr32740969pgr.141.1516154729012; Tue, 16 Jan 2018 18:05:29 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 16 Jan 2018 18:05:08 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <> <>
From: Dick Hardt <>
Date: Tue, 16 Jan 2018 18:05:08 -0800
Message-ID: <>
To: Brian Campbell <>
Cc: Hannes Tschofenig <>, oauth <>
Content-Type: multipart/alternative; boundary="001a114595b20c25540562ef48db"
Archived-At: <>
Subject: Re: [OAUTH-WG] draft-hardt-oauth-mutual-01
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 17 Jan 2018 02:05:32 -0000

and inline again ... :)

On Tue, Jan 16, 2018 at 1:50 PM, Brian Campbell <>

> Inline also...
> On Tue, Jan 16, 2018 at 2:25 PM, Dick Hardt <> wrote:
>> Comments inline ...
>> On Tue, Jan 16, 2018 at 1:11 PM, Brian Campbell <
>>> wrote:
>>> *On client_id:*
>>> With the authorization_code code grant (sec
>>>, 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
>>> 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.

It was a good question, and worth exploring. I think there are clear
advantages from a security point of view.

>>> *On the response:*
>>> The extension grants section (see
>>> 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 <>.  If the request failed client
>>>    authentication or is invalid, the authorization server returns an
>>>    error response as described in 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,
>> 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.

good suggestion to call out how reciprocal is different from other flows.
Will note that for the next draft. Thanks!