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

Brian Campbell <bcampbell@pingidentity.com> Mon, 15 July 2019 12:21 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 C3BC81200F4 for <oauth@ietfa.amsl.com>; Mon, 15 Jul 2019 05:21:48 -0700 (PDT)
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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=unavailable 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 ykC80TksY0Fy for <oauth@ietfa.amsl.com>; Mon, 15 Jul 2019 05:21:47 -0700 (PDT)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 EA105120112 for <oauth@ietf.org>; Mon, 15 Jul 2019 05:21:44 -0700 (PDT)
Received: by mail-qt1-x830.google.com with SMTP id d17so15274289qtj.8 for <oauth@ietf.org>; Mon, 15 Jul 2019 05:21:44 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=pingidentity.com; s=gmail; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=vIpSNEZ4TByEoZfu4T016YSmYsSOjavfunBEzmkkGVc=; b=TtkPc7G4+4wM2d/OERX0ue8QqPoM4g0bgiBV/DNKXpnsbnRTTWmJYpUa/B1JJxCWjQ jfp8bH+zoUETjzkoXbnCbmlWE1pTTe+BrZfqgN5KVbal5Vwa+Hsc9UqqhsvkAD62LltZ Md/AwXnaHfOJXVEVkJBY1GHdyuheHd09RfEbo=
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=vIpSNEZ4TByEoZfu4T016YSmYsSOjavfunBEzmkkGVc=; b=pdqSewSG/S5abzw6yP+ctYQttq8FQV6n0GERczymQ9rCKazn+HWWWxphHL7bKWxGhs cWkr6KulVQIeqkKLCOQDwoeriXKDSjP+cEhS/rCg2XZKvvdjTLrghkAKsh2tRZJWXTO3 i7qxcKds4rnVN3GLc5Tj5PgFHyL1XnpAfMJMDJk+zhVf868aJVOefH8gKzosLQpncUO3 oD6aLmJxrgvErwoLgKioBZSP1kMBx+1Z2d3v3YZRn+PZoLXZAir9vpSiLQfzNLKsHZm1 K8haudB8hPVSgl0IfGtCxfmj75gZ4Qv96CwcnNJ2TV1iF1FI/KKw2oCHA4AhAWSUvaaL 4uzg==
X-Gm-Message-State: APjAAAVeYw//PoIm0Gs9bLs79N/si6/IMCqZKPOWvFgVPDXjiiNI5P6L RvAUZbS3v70jgyAxJ2heC2//RxG7Zx1FbrRaqVpeslV/2zp89oat604m2PuLpFi5cx+laUrel8X lZv1ev6XGtqv1Rg==
X-Google-Smtp-Source: APXvYqxwnPirBeya0VKugQ43eWKWD/5uge4AmP7eHxlOTprVEcLC2qx/qbgEt4YwruKJI/VLkfCSESwexa4JTDKv7Kw=
X-Received: by 2002:ac8:c0e:: with SMTP id k14mr17474564qti.72.1563193303956; Mon, 15 Jul 2019 05:21:43 -0700 (PDT)
MIME-Version: 1.0
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> <20190713011346.GN16418@mit.edu>
In-Reply-To: <20190713011346.GN16418@mit.edu>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 15 Jul 2019 06:21:17 -0600
Message-ID: <CA+k3eCR8XwCXxSfP4=eSFZspADptxqdO8gg0OYwCno_PpPgBZg@mail.gmail.com>
To: Benjamin Kaduk <kaduk@mit.edu>
Cc: The IESG <iesg@ietf.org>, oauth <oauth@ietf.org>, draft-ietf-oauth-token-exchange@ietf.org, oauth-chairs@ietf.org
Content-Type: multipart/alternative; boundary="0000000000009916de058db74de8"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/ykPCHRxrZGhnHpTVSEHe_UeGzIk>
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: Mon, 15 Jul 2019 12:21:49 -0000

I believe there's a fair amount of precedent for something like it but
typically it's indicating group membership or roll(s) of a user that's
uniquely identified by other claims in a JWT. And, as far as I know,
there's nothing standardized for it so it's done more ad hoc. Thus there's
not really precedent from a standards perspective and, as I think about it
more, it's probably not a terribly good idea to try and define new
semantics like that at the 11th hour. So I'm gonna go with the '1) leave it
as is' option. And you're right that there are things that could be done
without too much issue, should it ever prove to be an issue (which I kinda
don't think will happen anyway).



On Fri, Jul 12, 2019 at 7:13 PM Benjamin Kaduk <kaduk@mit.edu> wrote:

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

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