Re: [Jwt-reg-review] JWT claim registration review request : draft-ietf-stir-passport-shaken

Benjamin Kaduk <kaduk@mit.edu> Mon, 05 November 2018 12:28 UTC

Return-Path: <kaduk@mit.edu>
X-Original-To: jwt-reg-review@ietfa.amsl.com
Delivered-To: jwt-reg-review@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 8C271128CFD for <jwt-reg-review@ietfa.amsl.com>; Mon, 5 Nov 2018 04:28:18 -0800 (PST)
X-Quarantine-ID: <W7VJLyc6E_LA>
X-Virus-Scanned: amavisd-new at amsl.com
X-Amavis-Alert: BAD HEADER SECTION, Non-encoded 8-bit data (char 9C hex): Received: ...s kaduk@ATHENA.MIT.EDU)\n\t\234by outgoing.mit[...]
X-Spam-Flag: NO
X-Spam-Score: -4.198
X-Spam-Level:
X-Spam-Status: No, score=-4.198 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_PASS=-0.001, UNPARSEABLE_RELAY=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 W7VJLyc6E_LA for <jwt-reg-review@ietfa.amsl.com>; Mon, 5 Nov 2018 04:28:17 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (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 A00C8127133 for <jwt-reg-review@ietf.org>; Mon, 5 Nov 2018 04:28:16 -0800 (PST)
X-AuditID: 12074424-5dbff70000002555-b5-5be0375dd90b
Received: from mailhub-auth-1.mit.edu ( [18.9.21.35]) (using TLS with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 92.1B.09557.E5730EB5; Mon, 5 Nov 2018 07:28:14 -0500 (EST)
Received: from outgoing.mit.edu (OUTGOING-AUTH-1.MIT.EDU [18.9.28.11]) by mailhub-auth-1.mit.edu (8.14.7/8.9.2) with ESMTP id wA5CSBlD031615; Mon, 5 Nov 2018 07:28:12 -0500
Received: from kduck.kaduk.org (24-107-191-124.dhcp.stls.mo.charter.com [24.107.191.124]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) �by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id wA5CS61L021763 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Mon, 5 Nov 2018 07:28:09 -0500
Date: Mon, 05 Nov 2018 06:28:06 -0600
From: Benjamin Kaduk <kaduk@mit.edu>
To: Brian Campbell <bcampbell@pingidentity.com>
Cc: Robert Sparks <rjsparks@nostrum.com>, jwt-reg-review@ietf.org, chris-ietf@chriswendt.net, mary.ietf.barnes@gmail.com, Russ Housley <housley@vigilsec.com>
Message-ID: <20181105122806.GD54966@kduck.kaduk.org>
References: <20181101170618.GC45914@kduck.kaduk.org> <CA+k3eCSgLihY==1mQ-sKJdtuKSuVN0PjNisgvhrt1PiUZQ-5FA@mail.gmail.com> <20181101232914.GN45914@kduck.kaduk.org> <CA+k3eCQBmy6F2PMO8wQ4Eq5a_W2ZPASxAPWOw1H-w4XK2ppLOg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Disposition: inline
In-Reply-To: <CA+k3eCQBmy6F2PMO8wQ4Eq5a_W2ZPASxAPWOw1H-w4XK2ppLOg@mail.gmail.com>
User-Agent: Mutt/1.9.1 (2017-09-22)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFprKKsWRmVeSWpSXmKPExsUixCmqrBtn/iDaYM1ZXYvV/28yWkz/tJvZ 4tWLm+wW5143MFl83r+f2eLanEY2BzaPCX1rWD12zrrL7rFkyU8mj1k7n7B43D16kcVj1Z0v rAFsUVw2Kak5mWWpRfp2CVwZi99NZy+YyVvxe80/tgbGS1xdjJwcEgImElf3NzJ1MXJxCAms YZK4PfEeC4SzgVFi/rXLUJk7TBL7LlxhB2lhEVCR2PikjQ3EZgOyG7ovM4PYIgL6ErefzmEH aWAWWM8o0Xz5NFiDsEC6xLvjd5hAbF6gfd+m7maEmPqWUeLZxC9sEAlBiZMzn7CA2MwCWhI3 /r0EauAAsqUllv/jAAlzCgRKHOu7BzZTVEBZYm/fIfYJjAKzkHTPQtI9C6F7ASPzKkbZlNwq 3dzEzJzi1GTd4uTEvLzUIl1zvdzMEr3UlNJNjKDQZ3dR2cHY3eN9iFGAg1GJh7cg5H60EGti WXFl7iFGSQ4mJVHeo6YPooX4kvJTKjMSizPii0pzUosPMUpwMCuJ8CqxAeV4UxIrq1KL8mFS 0hwsSuK8E1sWRwsJpCeWpGanphakFsFkZTg4lCR4fc2AGgWLUtNTK9Iyc0oQ0kwcnCDDeYCG e4DU8BYXJOYWZ6ZD5E8xKkqJ8+4DuUgAJJFRmgfXC0pNEtn7a14xigO9Isy7DqSdB5jW4Lpf AQ1mAhp8TxZscEkiQkqqgXHnH2vN7Mi4yyvVNILW/RORfm8rONM79Lipv2/bnc9qnvoLpwut jp7+6f4CLc2LiU+mbH9ez1/f+WfxpLlnbRY0CW0MTz7+ScD7i7sGd8aHF108nzMi1Zm8D14J Oj3hcftksykqR6X/vp7kkPW+cMHNc/9PbuNY7BPFpFb6atuiA68ylH/xaPxVYinOSDTUYi4q TgQAujR9xSgDAAA=
Archived-At: <https://mailarchive.ietf.org/arch/msg/jwt-reg-review/_mgyXKPC_55DH9zcej6XpkWejX8>
Subject: Re: [Jwt-reg-review] JWT claim registration review request : draft-ietf-stir-passport-shaken
X-BeenThere: jwt-reg-review@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: "Expert review of proposed IANA registrations for JSON Web Token \(JWT\) claims." <jwt-reg-review.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/jwt-reg-review>, <mailto:jwt-reg-review-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/jwt-reg-review/>
List-Post: <mailto:jwt-reg-review@ietf.org>
List-Help: <mailto:jwt-reg-review-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/jwt-reg-review>, <mailto:jwt-reg-review-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 05 Nov 2018 12:28:19 -0000

On Mon, Nov 05, 2018 at 02:35:27PM +0700, Brian Campbell wrote:
> [Noticed the recipients of the original message
> https://mailarchive.ietf.org/arch/msg/jwt-reg-review/mkGyvI2ZO20EFCPmObIlhl5UuNE
> had fallen off the distribution so added them back]
> 
> There are two OAuth sessions in Bangkok, however, the agenda already looks
> rather full. The idea of somehow allowing for registered claim reuse in
> disjoint settings sounds interesting. But even as a so called Designated
> Expert I don't think I'm expert enough or smart enough to gauge whether or
> not a context of use is truly disjoint and will continue to be disjoint
> into the future.
> 
> Indeed I've read (and reread) RFC7519's guidance but don't find it
> particularly helpful in guiding any decision making in this kind of
> situation. I also think it'd be appropriate to have a culture where the
> experts are comfortable pushing back on requests. And I have done that on
> occasion previously for requests that just didn't make sense at all. But in
> this case it's not clear that there really should be push back given
> general historical precedent and the situation of having somewhat generic
> names for specific usage being 'not that bad'.

Agreed, it is really "not that bad".

> I do think it would be useful if RFC7519 had some guidance or suggestions
> to would-be registrants about choosing claim names. But I don't know that
> from a practical perspective anything can be done in that regard at this
> point.

The only thing I can think of would be to publish a new document that adds
a Note to the registry including (a link to, or) guidance on choosing claim
names.

-Ben