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

Brian Campbell <bcampbell@pingidentity.com> Tue, 16 January 2018 21:11 UTC

Return-Path: <bcampbell@pingidentity.com>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 9808E12EB24 for <oauth@ietfa.amsl.com>; Tue, 16 Jan 2018 13:11:40 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.7
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=pingidentity.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id AIk-fWJpUiTj for <oauth@ietfa.amsl.com>; Tue, 16 Jan 2018 13:11:37 -0800 (PST)
Received: from mail-io0-x22c.google.com (mail-io0-x22c.google.com [IPv6:2607:f8b0:4001:c06::22c]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 4C3181272E1 for <oauth@ietf.org>; Tue, 16 Jan 2018 13:11:37 -0800 (PST)
Received: by mail-io0-x22c.google.com with SMTP id f34so13102792ioi.13 for <oauth@ietf.org>; Tue, 16 Jan 2018 13:11:37 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=r5nMfUm0LVL0Ahi7sMkEO4Ew0q3kMF8FsKXG0aEIxTY=; b=o911FHW9TJB1Nx9Sa+5rUCFb9ihtVgkTXUZ4eUOLjsGM3KfZx8dSy98BG286SJI1Q4 fKcWyxySEyDzUNZgSdIGakPp9zXCf02zOjloNUWUuIy56WOZNDuCN/xJ6mnyV/7pIQzL /nYavaCvH0TMOeT8PaLcP8dRDE3T/S9OUokH0=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=r5nMfUm0LVL0Ahi7sMkEO4Ew0q3kMF8FsKXG0aEIxTY=; b=EsLv1d3VbPUTz2LGv/zIUIUOzp4jidheGmTMxsfFCmXLPw1YVB03w+YcWVOjyTxqJd sEzZPzc0jZvpBixjiIi1keDh2+jGlCmGqmSlxtFY9T3fWP5/y+AENR036hxoDfl2bEfm i4OevriMzAFmq85PgY1lVhAHJHpMzpTysRweVRayLSfHXkRUQ6EBteRROC4MBI33SlaZ cGV97L71D/W1S/R6oErehcgZQSCeGQDOSuWpMyzVS8rtkl0UH8SEZlNLFNFrHJciC9en 9c23KuNqS6d5tmA+jvbtIf1q85nFtXs4qLQnYxkaaBM9bwfxpliLTdPzW/hicj08t+j0 cGPQ==
X-Gm-Message-State: AKwxytcD9T7Kh2uk5kioh2kT9dOk/B5ZqwbE0wxJ4m3rwYdloKtz1/rU Ou0g4+MC6YEd1kjCZjWRWFo5kJXVe/SfhNeRugsA0VA93NzSL+JCoo4c3A5rwlbxpnkhxMuPa9d RJGVhSOuJU+Tmrg==
X-Google-Smtp-Source: ACJfBovAxRGc5uRePAHlJRryVcy5YgpzfZlNQw10n8HV1EiGTiQ4BVyPcPY+k8WfwRoRSz1VHZZQP+aG7VEZrceAKss=
X-Received: by 10.107.111.5 with SMTP id k5mr13690995ioc.86.1516137095903; Tue, 16 Jan 2018 13:11:35 -0800 (PST)
MIME-Version: 1.0
Received: by 10.2.30.193 with HTTP; Tue, 16 Jan 2018 13:11:05 -0800 (PST)
In-Reply-To: <CAD9ie-s-K-BmH3NkZOj0kJ9E4kktoDZXwwhjmVApWobf9+3D+w@mail.gmail.com>
References: <CAD9ie-t3RduyvdB7_YMa8f-t9EWvKw8fHNdQfvhYbCpttiHjCg@mail.gmail.com> <fa362c26-8b1a-6f21-d4fa-8bd8fa9fba76@gmx.net> <CA+k3eCQsn=0M8pCv+6MhKQ0d8jgFpOXgLG+8DAscd9PE4XRmPw@mail.gmail.com> <CAD9ie-s-K-BmH3NkZOj0kJ9E4kktoDZXwwhjmVApWobf9+3D+w@mail.gmail.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Tue, 16 Jan 2018 14:11:05 -0700
Message-ID: <CA+k3eCQQe-cpywqkfoO6=dhr6vLxmu6Z=pJfGWcy7eOPVCy42g@mail.gmail.com>
To: Dick Hardt <dick.hardt@gmail.com>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="089e082ce79808cad30562eb2dc9"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/cn2gztQZw25GuTaDfj9grTFd8Zg>
Subject: Re: [OAUTH-WG] draft-hardt-oauth-mutual-01
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.22
Precedence: list
List-Id: OAUTH WG <oauth.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/oauth>, <mailto:oauth-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/oauth/>
List-Post: <mailto:oauth@ietf.org>
List-Help: <mailto:oauth-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/oauth>, <mailto:oauth-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 16 Jan 2018 21:11:41 -0000

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



*On the response:*
The extension grants section (see https://tools.ietf.org/html/
rfc6749#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.

On Tue, Jan 16, 2018 at 12:25 PM, Dick Hardt <dick.hardt@gmail.com> wrote:

> Brian
>
> *grant type*
> Thanks for the grant type pointers.
>
> *client_id*
> The reciprocal flow by its nature is part of a code_grant flow, and I
> expect that party A and party B can be reversed. Given that, it is unclear
> why client_id would not be required. Would you elaborate?
>
> *response*
> Agree a response should be defined. 200 if ok, 400 if invalid. Any reason
> for doing more?
>
> /Dick
>
>
> On Tue, Jan 16, 2018 at 9:27 AM, Brian Campbell <
> bcampbell@pingidentity.com> wrote:
>
>> A few thoughts on the new draft and/or reiterating comments from the call
>> earlier.
>>
>> "[DH: should this be a URI?]" - yes, the grant type should be a URI
>> because, for better or worse, that's how OAuth allows for new grants
>> https://tools.ietf.org/html/rfc6749#section-4.5 (the device flow and JWT
>> authorization grant are examples that can be followed
>> https://tools.ietf.org/html/draft-ietf-oauth-device-flow-07#section-3.4
>> https://tools.ietf.org/html/rfc7523#section-2.1).
>>
>> I don't believe client_id should be required in 2.2. Sending/requiring
>> client_id or not at the token endpoint depends on the form of client
>> authentication that's taking place. That's how it works with the grants in
>> RFC6749 and other extension grants. This draft should be consistent with
>> all that.
>>
>> I do think some discussion or description of what the response
>> will/should look like is needed. Things are kinda reversed in this flow
>> with party A 'pushing' the authorization code it generated up to party B's
>> authorization server. It's not clear (to me anyway) how party B's AS should
>> respond and if/how it would be consistent with a typical token endpoint
>> response. Maybe echo back the access token that was just sent in? But I
>> dunno.
>>
>> The example needs some attention (grant type value is old, the basic
>> authn header probably isn't legal, maybe more).
>>
>>
>> On Tue, Jan 16, 2018 at 7:46 AM, Hannes Tschofenig <
>> hannes.tschofenig@gmx.net> wrote:
>>
>>> Hi Dick,
>>>
>>> maybe you can re-submit the document with a new filename that matches
>>> the updated title.
>>>
>>> Ciao
>>> Hannes
>>>
>>>
>>> On 01/16/2018 03:39 PM, Dick Hardt wrote:
>>> > I have made changes based on feedback on the call this morning. Updated
>>> > version at:
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> OAuth@ietf.org
>>> https://www.ietf.org/mailman/listinfo/oauth
>>>
>>
>>
>> *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.*
>
>
>

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