Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)

Benjamin Kaduk <kaduk@mit.edu> Sat, 13 July 2019 01:13 UTC

Return-Path: <kaduk@mit.edu>
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 E458312006A; Fri, 12 Jul 2019 18:13:54 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=ham 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 cJz7Lar1wWrg; Fri, 12 Jul 2019 18:13:53 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id DF666120041; Fri, 12 Jul 2019 18:13:52 -0700 (PDT)
Received: from mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id x6D1DlP4007164 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Fri, 12 Jul 2019 21:13:49 -0400
Date: Fri, 12 Jul 2019 20:13:46 -0500
From: Benjamin Kaduk <kaduk@mit.edu>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: The IESG <iesg@ietf.org>, oauth <oauth@ietf.org>, draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org
Message-ID: <20190713011346.GN16418@mit.edu>
References: <156238540273.21781.4146676340197499618.idtracker@ietfa.amsl.com> <CA+k3eCR4HfiOusEfFsE-T7-PguvJMZr7_K-nGgm3F9y0593E+Q@mail.gmail.com> <20190706184226.GA13047@kduck.mit.edu> <CA+k3eCS3zd9Qir5joMuP4-hn8L-8jAU=gy9StOraA7uH5ouMkw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+k3eCS3zd9Qir5joMuP4-hn8L-8jAU=gy9StOraA7uH5ouMkw@mail.gmail.com>
User-Agent: Mutt/1.10.1 (2018-07-13)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/7Up6JYEPiuVKA69AOMvOkQ-18Qs>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Yes on draft-ietf-oauth-token-exchange-17: (with COMMENT)
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: Sat, 13 Jul 2019 01:13:55 -0000

On Sun, Jul 07, 2019 at 09:32:15AM -0400, Brian Campbell wrote:
> On Sat, Jul 6, 2019 at 2:42 PM Benjamin Kaduk <kaduk@mit.edu> wrote:
> 
> >
> > > Not to my recollection. I'm honestly not even sure what an array would
> > mean
> > > for "may_act". Do you mean for "act"?
> >
> > Currently we can say that admin@example.com "may act" as user@example.com.
> > But IIUC we don't have a way to say that either admin1@example.com or
> > admin2@example.com may do so.  An array would let us indicate multiple
> > authorized parties.  I'm reluctant to actually make such a change at this
> > point, though, since this is already deployed some places, right?
> >
> 
> Okay, sorry, I'm a bit slow but I follow you now.
> 
> Indeed this has been deployed in a number of places already. I'd honestly
> don't know if anyone is making use of this particular claim but changing
> from an object to array of objects would be a breaking change. And a
> breaking change is something I'd really like to avoid unless there's a very
> compelling reason to do so.  And while your point here is taken, I don't
> think it rises to that level of compelling.
> 
> I see two options at this point:
> 1) leave it as is
> 2) adjust the language around  "may_act" such that it could also identify
> an eligible group - this would allow for it to indicate multiple authorized
> parties but just not by one by one name, which is maybe more desirable
> anyway
> 
> What do you think?

Either option is fine with me.  I don't remember how much precedent we have
in the OAuth ecosystem for groups that are  identified in  this manner, but
if it's a fairly common thing that seems to be slighly preferred.
(Even if we go with (1) and this does become an issue at some point, it
shouldn't be too hard to add a "may_also_act" or similar with the array
semantics.)

-Ben