Re: [OAUTH-WG] Meeting Minutes

David Waite <david@alkaline-solutions.com> Tue, 17 December 2019 08:28 UTC

Return-Path: <david@alkaline-solutions.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 D35241200DE for <oauth@ietfa.amsl.com>; Tue, 17 Dec 2019 00:28:25 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.106
X-Spam-Level:
X-Spam-Status: No, score=-1.106 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RDNS_NONE=0.793, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=no autolearn_force=no
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 3C64rRljgl9Y for <oauth@ietfa.amsl.com>; Tue, 17 Dec 2019 00:28:23 -0800 (PST)
Received: from alkaline-solutions.com (unknown [173.255.196.46]) by ietfa.amsl.com (Postfix) with ESMTP id 7535C120025 for <oauth@ietf.org>; Tue, 17 Dec 2019 00:28:23 -0800 (PST)
Received: from [IPv6:2601:282:202:b210:b092:f754:6264:326] (unknown [IPv6:2601:282:202:b210:b092:f754:6264:326]) by alkaline-solutions.com (Postfix) with ESMTPSA id E543C3155C; Tue, 17 Dec 2019 08:29:25 +0000 (UTC)
From: David Waite <david@alkaline-solutions.com>
Message-Id: <528F7BBC-54DC-4EEF-8AE9-4074C0CB071F@alkaline-solutions.com>
Content-Type: multipart/alternative; boundary="Apple-Mail=_0ACEA500-C77F-451B-999E-0C83FD2DFEE9"
Mime-Version: 1.0 (Mac OS X Mail 13.0 \(3608.40.2.2.4\))
Date: Tue, 17 Dec 2019 01:28:21 -0700
In-Reply-To: <CA+k3eCSLmj6M=qeDJPTEDBpD5T5rC55wqGiTeuB7u8KzMsJZ-g@mail.gmail.com>
Cc: Hannes Tschofenig <Hannes.Tschofenig@arm.com>, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org>
To: "oauth@ietf.org" <oauth@ietf.org>
References: <VI1PR08MB53603D167B53065E04A6C621FA420@VI1PR08MB5360.eurprd08.prod.outlook.com> <CA+k3eCSLmj6M=qeDJPTEDBpD5T5rC55wqGiTeuB7u8KzMsJZ-g@mail.gmail.com>
X-Mailer: Apple Mail (2.3608.40.2.2.4)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/_OqNpZyn6ZFYVva5EYmIqL_ZSio>
Subject: Re: [OAUTH-WG] Meeting Minutes
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.29
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, 17 Dec 2019 08:28:26 -0000

+1 to adopting PAR.

For RAR I have a number of questions myself with the approach and with some of the ramifications. I’m most concerned with the coupling of business-specific presentation, process validation and workflow within the AS, but also with the mixing of single transactional approval into accesses token that is normally meant for longer-lived, coarser client authorizations.

To stick with the primary payment example - there are payment cases which model well for single resource authorization, such as a PayPal-style transaction where the client is also the recipient of funds. For other types of transactions, I would worry this may become primarily an AS-executed action rather than a client authorization.

Before the device flow and before CIBA, I’d probably try and make a case for not adopting it. The decoupling of the client from any user-agent that could ask for user authorization outside of OAuth has made an increase in scope (of scopes) a higher need - the current communication pipe between the client and user-agent is only defined in the scope of the actual OAuth grant processes.

-DW


> On Dec 16, 2019, at 9:26 AM, Brian Campbell <bcampbell=40pingidentity.com@dmarc.ietf.org> wrote:
> 
> With respect to the Pushed Authorization Requests (PAR) draft the minutes do capture an individual comment that it's a "no brainer to adopt this work" but as I recall there was also a hum to gauge the room's interest in adoption, which was largely in favor of such. Of course, one hum in Singapore isn't the final word but, following from that, I was hoping/expecting to see a call for adoption go out to the mailing list? 
> 
> On Tue, Dec 3, 2019 at 1:26 AM Hannes Tschofenig <Hannes.Tschofenig@arm.com <mailto:Hannes.Tschofenig@arm.com>> wrote:
> Here are the meeting minutes from the Singapore IETF meeting:
> 
> https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03 <https://datatracker.ietf.org/meeting/106/materials/minutes-106-oauth-03>
>  
> 
> Tony was our scribe. Thanks!
> 
>  
> 
>  
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org <mailto:OAuth@ietf.org>
> https://www.ietf.org/mailman/listinfo/oauth <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._______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth