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

Dick Hardt <> Tue, 16 January 2018 21:25 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 54CE112EB24 for <>; Tue, 16 Jan 2018 13:25:36 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Status: No, score=-1.999 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] 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 FJaqSzU4hwv0 for <>; Tue, 16 Jan 2018 13:25:34 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:400e:c00::22b]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id C61CC12E3AE for <>; Tue, 16 Jan 2018 13:25:34 -0800 (PST)
Received: by with SMTP id t5so4242551pfi.0 for <>; Tue, 16 Jan 2018 13:25:34 -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=1RCQI9wn7yB5d0e+SJCqTS5JsfLgwKIkA0z9qvmKpL4=; b=WwUBhTvgpe3K4Yv7jv+28geDlzvqhS8hpgnLnDSx4rlKZr59mCyfQX6u7YBJXAVZ7n dDVM52APbXsObztNLFiG3r1lrblEcBkTn6HStHwN+SWnhEF9WSQDHEGjVeI5PB2L026M ZRxk6Seu+BlHgamlFEarwqy8l8+HD53scoNpYAt8J3Yx74AmFVuqlx2P+C1QIThLORKn vBKoPGbRJeQPpvaVQjt6OSFen7QtQz7Has0wKl9by4YCrWgb4LEHNbWgHEY/aw1FAJeM Gy8Wf/WzWK82yxaCm2pAhlLLpyYf8o3ltoi2rWnWI7j0PulA05bG5DmZpjdoRRFa6CHf hO2w==
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=1RCQI9wn7yB5d0e+SJCqTS5JsfLgwKIkA0z9qvmKpL4=; b=cDSv0yVV+dh5hl6cY5jhrlon7K9raxbp05mQJIdETWzNr5Icx9wHm+rs76/DDfBRtJ wxifOF36ANtbRqb7QJdmZLoaimq8rGgYCIbvWTEEJVOpIBfy3PA7R1UTzuMk1huI1Ww0 HcYpiM3CRjnu8L/p37g1ETBZNUFkO293BIYaMFJRJA7u+XN6eDcmctaQaQnVOP/nO+Ls 0RSYN/Y5rc2iN+3mtYau5y6rzZJe6DfrVxtZ4MRgym+0R2bsFsWlJHGhukcUBWciv0V0 0zdlS/zim3cUCuzKmlMC+7+mWFljV6b9ODchaaIvTyp5n86qSHqzfhTnofhI8uqIaA7z LChQ==
X-Gm-Message-State: AKwxytc5jP8OrBnPpr1b4yvg4659LuX0qbjlIefSiP/2mKyc8tiUHuFG Pb96COz3N3HHOmphIHubFpspT4KfA4O0vTWLelo=
X-Google-Smtp-Source: ACJfBoswzP+GxE559bNGRV2rwihujXsf765CjDKHhA8ROAGcsR/dL8DMy30SPgPgLpTksyrlLLr7Hbn4d56CD0hEciI=
X-Received: by with SMTP id m10mr10385705pff.168.1516137934274; Tue, 16 Jan 2018 13:25:34 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 16 Jan 2018 13:25:13 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <>
From: Dick Hardt <>
Date: Tue, 16 Jan 2018 13:25:13 -0800
Message-ID: <>
To: Brian Campbell <>
Cc: Hannes Tschofenig <>, oauth <>
Content-Type: multipart/alternative; boundary="f4030437dbcc00c7a30562eb5f1c"
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: Tue, 16 Jan 2018 21:25:36 -0000

Comments inline ...

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

> *On client_id:*
> With the authorization_code code grant (sec
> 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
> 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

Is there a reason you would NOT want to pass the client_id?

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