Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)

Brian Campbell <bcampbell@pingidentity.com> Mon, 29 July 2019 15:49 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 5E4FF12013D for <oauth@ietfa.amsl.com>; Mon, 29 Jul 2019 08:49:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.7
X-Spam-Level:
X-Spam-Status: No, score=0.7 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, GUARANTEED_100_PERCENT=2.699, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001] autolearn=no 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 ReS9iXZVZbpQ for <oauth@ietfa.amsl.com>; Mon, 29 Jul 2019 08:49:06 -0700 (PDT)
Received: from mail-io1-xd2a.google.com (mail-io1-xd2a.google.com [IPv6:2607:f8b0:4864:20::d2a]) (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 ADBBB1200CC for <oauth@ietf.org>; Mon, 29 Jul 2019 08:49:06 -0700 (PDT)
Received: by mail-io1-xd2a.google.com with SMTP id k8so121111514iot.1 for <oauth@ietf.org>; Mon, 29 Jul 2019 08:49:06 -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=exky5qScvLGcyd79yGS6XzLB9C/hk4DmHngGuSugqV0=; b=n58e47Avx77R/yacLeT7athwfe3plhH9qcUHTobY2eeqwiE1Sb3t+xcReyjAQctMR8 cKvCd0czXsyBo+kH4cMqc0kI5xeWL3sVrbxOFDwJGLWf6qgp/kLSrB2x5tSb08QPYd62 TX4oZcjSZ1EMDZQ4WqQDrgZV5MK1wtCBAdN4A=
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=exky5qScvLGcyd79yGS6XzLB9C/hk4DmHngGuSugqV0=; b=sEfX0GdOHt2oU70iIM5BRQgchoX3tr9yNdYXP42XW9jWsMnb9KGa13kXNWkR36QaPP 1cj1tPD/GDsTj3QA+dOgfxf44XPoKV8wSB+173HUVnSL7GuXkb/fi74iKXc31cnX+4Ww p5G8RtSoKldG6DJNKyzEJ4iPqdmZlpQsY1OJ1NnMZ+WyMrpboHcK4JW9lstjUTIGSWTh giwxuT9+2dSd/Bcdf4VJ0M0CTlvqf3ZwtK59x/bhvVRUvwr/e8jJAAZYA4qLIUiJ91XP UuVJKxspqtYYYu60EVnrBeQ9m3YF8m3s68v9wNIiiUXjg7MPE4/VI5zLX6T03+zfyg8F +6zQ==
X-Gm-Message-State: APjAAAXd9UJRcYZ6By5yjWBTWZ+aODb7Un9Ay902F+8jKPIMVKrSzOU1 2VXTyhQg8laIFE1fUVE12HMPKzVBhhVqoa2UpI9wBxWU/kSYUqoDw64XUQzyQf09fc7KF8YEQPQ XgKdHCORQTfT6qw==
X-Google-Smtp-Source: APXvYqx78Xick8h2j4FWXtxbntbNmbLivu/QNY+DXrNsxuiOMcvfw9TpiLxPKeKF5SWCs5PKoos6rsgseMHG+fMzIjk=
X-Received: by 2002:a6b:fd10:: with SMTP id c16mr96970978ioi.217.1564415345789; Mon, 29 Jul 2019 08:49:05 -0700 (PDT)
MIME-Version: 1.0
References: <156218034597.14836.482712385966674562.idtracker@ietfa.amsl.com> <CABzCy2AvNBGAUrfHNY+LoEZACt5F9q1zx1P81zqj8hNo3FjgTQ@mail.gmail.com> <CA+k3eCS0JBh=fRDTnBKNHw2yncLKZCd+MN8sojhkJw23yFvbwg@mail.gmail.com> <TYAPR01MB4413256F202E0FCA83735F36F9C20@TYAPR01MB4413.jpnprd01.prod.outlook.com>
In-Reply-To: <TYAPR01MB4413256F202E0FCA83735F36F9C20@TYAPR01MB4413.jpnprd01.prod.outlook.com>
From: Brian Campbell <bcampbell@pingidentity.com>
Date: Mon, 29 Jul 2019 09:48:39 -0600
Message-ID: <CA+k3eCSGS4pA6xZjqgguD3=QbxA6anfu6LrYTWooTHc66JN4Ng@mail.gmail.com>
To: n-sakimura <n-sakimura@nri.co.jp>
Cc: Nat Sakimura <sakimura@gmail.com>, Benjamin Kaduk <kaduk@mit.edu>, "draft-ietf-oauth-jwsreq@ietf.org" <draft-ietf-oauth-jwsreq@ietf.org>, "oauth-chairs@ietf.org" <oauth-chairs@ietf.org>, The IESG <iesg@ietf.org>, oauth <oauth@ietf.org>
Content-Type: multipart/alternative; boundary="000000000000f7be75058ed3d4b6"
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/kfNqsBGO0p3UFoi27uA7zTKxDIs>
Subject: Re: [OAUTH-WG] Benjamin Kaduk's Discuss on draft-ietf-oauth-jwsreq-19: (with DISCUSS and 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, 29 Jul 2019 15:49:09 -0000

To be accurate, I'm one of the DEs on the JWT Claims registry
https://www.iana.org/assignments/jwt/jwt.xhtml while Hannes is the DE on
the OAuth Parameters registry
https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#parameters
FWIW.

To completely lock it all down and absolutely avoid collisions in all cases
(all cases that bother to consult the registries anyway), I suppose the two
registries would need to be reconciled and then kept perfectly in sync
going forward. Or even merged into a single super registry. But, to me
anyway, that seems like a huge PITA that's overkill and doesn't account for
the context of use with respect to likelihood of actual collisions.

JAR is a  specific application of JWT that is being used to convey an OAuth
authz request. The collisions that need to be avoided are in that narrow
context. JAR explicitly uses a few core JWT claims (aud, iss) so those need
to be accounted for by registering them as OAuth authorization request
parameters (with some explanation as such).  And one could reasonably
imagine some of the other core claims which are about the token itself
being used as well (exp, iat, nbf, jti, cnf, etc). So those should probably
be accounted for as well.

But most/all of the other JWT claims that have been registered, the SIP
CSeq numeric header field parameter value for example, are highly unlikely
to ever be used in the context of an OAuth authorization request. So won't
be a collision issue in the narrow context of a JWT secured authorization
request.  I think it's unlikely enough to be an issue that I think it's
sufficient to only register the core meta JWT claim names into the OAuth
parameters registry for the authorization request usage location.

True, that's not 100% guaranteed to guard against all collisions. But I
think it's pragmatic trade off that guards against all likly real world
collisions.

And if we are really worried about avoiding it 100% guaranteed all the
time, then JAR should wrap the authorization request parameters in a JSON
object so they have their own effectively distinct namespace. But I realize
that's a major change at this stage. Which leads me back to looking for a
simple(ish) and pragmatic approach to avoiding actual likely collisions.






On Sun, Jul 28, 2019 at 4:18 PM n-sakimura <n-sakimura@nri.co.jp> wrote:

> Brian,
>
> You are the expert on the particular IANA registries so I probably are
> missing something.
>
> I was thinking that registering JWT claims to OAuth registry is sufficient
> till seeing Ben’s comment, and I was tracking that it is being done by Mike
> as part of the errata process for OIDC Core. However, after reading Ben’s
> comment that mentioning the OAuth extensions, and I checked that quite a
> few claims are now being registered to JWT Claims Registry from outside the
> OAuth community, I started to feel that it may not be sufficient. But I
> must be missing something as you point out that is still sufficient.
>
> Could you please explain how the collision between the future OAuth
> extension and JWT claims can be avoided by registering main JWT claims to
> the OAuth Parameter registry?
> If that is the case, I am all for it as then we do not get back to IANA
> process.
>
> Best,
>
> Nat
>
> Nat Sakimura | 崎村夏彦
> Nomura Research Institute
>
>
> このメールには、本来の宛先の方のみに限定された機密情報が含まれている場合がございます。お心あたりのない場合は、送信者にご連絡のうえ、このメールを削除してくださいますようお願い申し上げます。
>
> PLEASE READ:This e-mail is confidential and intended for the named
> recipient only. If you are not an intended recipient, please notify the
> sender and delete this e-mail.
>
> ------------------------------
> *差出人:* Brian Campbell <bcampbell@pingidentity.com>
> *送信日時:* Saturday, July 27, 2019 5:47:15 AM
> *宛先:* Nat Sakimura <sakimura@gmail.com>
> *CC:* Benjamin Kaduk <kaduk@mit.edu>du>; draft-ietf-oauth-jwsreq@ietf.org <
> draft-ietf-oauth-jwsreq@ietf.org>gt;; oauth-chairs@ietf.org <
> oauth-chairs@ietf.org>gt;; The IESG <iesg@ietf.org>rg>; oauth <oauth@ietf.org>
> *件名:* Re: [OAUTH-WG] Benjamin Kaduk's Discuss on
> draft-ietf-oauth-jwsreq-19: (with DISCUSS and COMMENT)
>
> Nat, you suggest that the "simplest solution probably is to register the
> authorization request parameters to the JWT Claims registry." However, as
> I've attempted to articulate several times this week (
> https://mailarchive.ietf.org/arch/msg/oauth/0EenxmThjII52SAr9atpBStRtcs
> and
> muliple comments on https://bitbucket.org/openid/connect/issues/1019) and
> even back in 2017 (
> https://mailarchive.ietf.org/arch/msg/oauth/_E14Trqu962cReu3t6FquPEyigY),
> I
> believe the pragmatic solution to this is to register some of the main JWT
> claims into the OAuth parameters registry (not the other way around, as
> you're suggesting which wouldn't even have caught the one name collision
> we've actually had where a draft, more than one actually, wanted to call an
> authorization request parameter "aud", which would conflicted with the JWT
> claim of the same name and cause big problems when used together with JAR).
> I suppose the iron clad way to "fix" this would be to merge the two
> registries and keep them in sync forever. But that seems awfully heavy
> handed and unnecessary. JAR is a specific application of JWT being used to
> convey an OAuth authz request. JAR explicitly uses a few core JWT claims
> (aud, iss) and one could reasonably imagine other core ones being used as
> well (exp, iat, nbf, jti, etc). An authorization request parameter being
> introduced that uses one of those names is far and away the most likely
> point of collision (and has already happened, as noted previously). A new
> JWT claim being introduced that collides with an existing authorization
> request parameter name AND would be used in the context of JAR is far far
> less likely to happen. So unlikely, in fact, that I don't think it's
> necessary or even useful to pollute the JWT claims registry with the names
> of all the authorization request parameters. I happen to be one of the DEs
> on the JWT claims registry so, in theory, I have some idea what I'm talking
> about here. In theory. And I do have to be upfront at this point and say
> that I will push back on a request for registration of a bunch of
> authorization request parameters into the JWT claims registry without
> without more compelling reason.
>
>

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