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

Dick Hardt <dick.hardt@gmail.com> Tue, 16 January 2018 19:40 UTC

Return-Path: <dick.hardt@gmail.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 32393126DC2 for <oauth@ietfa.amsl.com>; Tue, 16 Jan 2018 11:40:05 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.999
X-Spam-Level:
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: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=gmail.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 cc-hsloWT6BW for <oauth@ietfa.amsl.com>; Tue, 16 Jan 2018 11:40:03 -0800 (PST)
Received: from mail-pf0-x22b.google.com (mail-pf0-x22b.google.com [IPv6:2607:f8b0:400e:c00::22b]) (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 0D13512D953 for <oauth@ietf.org>; Tue, 16 Jan 2018 11:40:03 -0800 (PST)
Received: by mail-pf0-x22b.google.com with SMTP id t12so10236764pfg.2 for <oauth@ietf.org>; Tue, 16 Jan 2018 11:40:03 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=b0xvm/COrQc/XHn13QCXytQZYpsBNHPewjRPJSaQkqc=; b=CPZ89zQa39hnBoU5e4jq2k20IP9s/yq1YUrt3+VEjFeOBwRf5pTM+eMn5WKgHL1AmB YDplo0gWKj2yGbUbN/RTtKwYLcH9rSM6/v2eRnaMkmzThcARtMf+APrcoO/R46MiU+S+ NqJfuCo9lu0h3va5oV3nuARkGzelGBAAPCQ935IV7lw7oCVZQFcAnYSqrpWVDljsS3Ql nr1UeOMybFNADMK210Q3PPCxbc7jVnXWA5lwka9FG3LhLiFS0VHh8EZ+wW77oHmpzTLv yAl17bSGarF0a5CuF/I1jn6D833lFV84uktlUM8pFaOcC44Htfk9xcdyxGK0+7pBiw/i Xikw==
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=b0xvm/COrQc/XHn13QCXytQZYpsBNHPewjRPJSaQkqc=; b=UYRbmpXwdQ5FSfY6+ZBEppehSMdNpApmY1pY/CVEF+mSANSItWfCgCCsiwwhm5WFkW /5K+GpjSz7rRl9S0UbKoozN64J/qNFbEr9l3l0KPv/wjvBrzJtaskXokL8L6CigA6zZV IOs5bcPz5D5EqeX1mxTxol3xYKVwFMekYO96b6DrOXEMgTt8wpNWbwh8t6t4hRpUb+Yy AcTjGD4zL37KbJJTCf/z9xuChSJBjlzEYb8ME3y+kqajohV75C8Ji4emWgMKM3R0MOlc NfO8f1Bn72FaatshrmdCgq7AHmq3Uf6wLvAQwu9O94wT48cV4XvK+tqEY6bWIVaPSy1N fcrw==
X-Gm-Message-State: AKGB3mLfr+QlzIrBUf9lX1DYgunuHTvIwFmrmjAPXkjekcBCAP6l47LJ aueM0Y4nxdMGu7iXdkE0UlIaESEyqrhZ1vWr0PY=
X-Google-Smtp-Source: ACJfBovqayQYeyXQgsKZBly81gQsq+Tnk1uHQWTXbuxv4GB+6+fvMqu6G7Z2nhTJLdZ20zRok7QupJ7Mbsz70BMvfjM=
X-Received: by 10.98.97.3 with SMTP id v3mr36071148pfb.124.1516131602350; Tue, 16 Jan 2018 11:40:02 -0800 (PST)
MIME-Version: 1.0
Received: by 10.100.143.133 with HTTP; Tue, 16 Jan 2018 11:39:41 -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: Dick Hardt <dick.hardt@gmail.com>
Date: Tue, 16 Jan 2018 11:39:41 -0800
Message-ID: <CAD9ie-sPYmzmFS1+_193=+gXdDCMeS2QKe17oLuLVOtea93teA@mail.gmail.com>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Hannes Tschofenig <hannes.tschofenig@gmx.net>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="94eb2c04733c9746710562e9e51e"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/kbgIRAnXzANigZ06M-BqaxNqSk0>
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 19:40:05 -0000

02 version uploaded, and now at

https://datatracker.ietf.org/doc/draft-hardt-oauth-mutual/

Hannes: Keeping the same filename while it is an ID as it breaks the
automated process for updating. Will s/mutual/reciprocal/ if adopted and
file name is changed to reflect adoption.



On Tue, Jan 16, 2018 at 11:25 AM, 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.*
>
>
>