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

Brian Campbell <> Tue, 16 January 2018 21:50 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 8EC7412EB4B for <>; Tue, 16 Jan 2018 13:50:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Status: No, score=-2.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_PASS=-0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (1024-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id qp-7ywfkaTOl for <>; Tue, 16 Jan 2018 13:50:46 -0800 (PST)
Received: from ( [IPv6:2607:f8b0:4001:c06::234]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 009AB12EB35 for <>; Tue, 16 Jan 2018 13:50:45 -0800 (PST)
Received: by with SMTP id n7so2013620iob.0 for <>; Tue, 16 Jan 2018 13:50:45 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=4zE0h3vwR9Kz1WHddnXYeKbGUUUzpT+6d4qkbA8hnsU=; b=O0vpcAW5cye06upJerEvY626eD3fGmDE2y73UufArfo24y3b5qYYoywBLpW6cZL6bG 73EpfuHhFubl9hirB4TPci+GNQamURZvkjcx15vjvmuLKR1G3btBYcS3IRIF0xGw3DW1 ielO7VCl6uCTPmCCiEMN9KJkuitCHVFOaaJKE=
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=4zE0h3vwR9Kz1WHddnXYeKbGUUUzpT+6d4qkbA8hnsU=; b=Y0b9/xxPSRMUMYDet7JSlCvN9tp0Rq/YrV9tGFYtrAEP8Sl1O13BJGLhMck+o4/8Ei zcEN9erArIRbs1c1o+RQ6BWHoLRoS97U3om6Cz4sjb9prudsNCBmiib2p89OmCun8Sbp /sMubUsy1eRU6nsHsTgQwj04MXek6DsZBpJwedegFuhIq3Mey1kgTbE6/3hGi2njidl9 py1OxyNEfiJBdoJwKaellMuvojkGL/WipFifXDWiIUR4ueLoC8oDGb0cUwfcvedSedNX DudA3+Aw/PFju5pXRvyQgRvcqnFB2XxfYp1pln/SNm5s2Jek/m2MPpFl3xOv80zGKGCA wHKw==
X-Gm-Message-State: AKwxyteXUbuuPub5IvzNMnm0NyPK2zRx2zDMX8VauZb/QWDoqiToGIj7 dXdo2r+JRmQjXV0/I7MoyZgZxaXtaWGfXPCGaZFP/91QK21DOcZu26GeUSlw3rTaFGdtsSbskus hO6Z42On2iLsrMQ==
X-Google-Smtp-Source: ACJfBou9vYFezilmyTZH+lpCSPjiB6Au9CjThfGiVSH7SuVNQPp3mQV2WMEjRIa1ioSpL5yMbuBM4CZb196UqImYJ2c=
X-Received: by with SMTP id l188mr17502328iof.301.1516139445125; Tue, 16 Jan 2018 13:50:45 -0800 (PST)
MIME-Version: 1.0
Received: by with HTTP; Tue, 16 Jan 2018 13:50:14 -0800 (PST)
In-Reply-To: <>
References: <> <> <> <> <> <>
From: Brian Campbell <>
Date: Tue, 16 Jan 2018 14:50:14 -0700
Message-ID: <>
To: Dick Hardt <>
Cc: Hannes Tschofenig <>, oauth <>
Content-Type: multipart/alternative; boundary="94eb2c05d48c0eabbb0562ebb954"
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:50:49 -0000

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.

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

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