[Jwt-reg-review] [IANA #1158948] Requested review for IANA registration in draft-ietf-ace-oauth-params (jwt - JSON Web Token Claim)

"Sabrina Tanamal via RT" <drafts-expert-review@iana.org> Wed, 19 February 2020 16:41 UTC

Return-Path: <iana-shared@icann.org>
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 7F658120143 for <jwt-reg-review@ietfa.amsl.com>; Wed, 19 Feb 2020 08:41:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.929
X-Spam-Level:
X-Spam-Status: No, score=-2.929 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.25, MISSING_HEADERS=1.021, 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 AOTPLOm8sKmM for <jwt-reg-review@ietfa.amsl.com>; Wed, 19 Feb 2020 08:41:14 -0800 (PST)
Received: from smtp01.icann.org (smtp01.icann.org [192.0.33.81]) (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 BE644120071 for <jwt-reg-review@ietf.org>; Wed, 19 Feb 2020 08:41:14 -0800 (PST)
Received: from request4.lax.icann.org (request1.lax.icann.org [10.32.11.221]) by smtp01.icann.org (Postfix) with ESMTP id A1851E091B; Wed, 19 Feb 2020 16:41:14 +0000 (UTC)
Received: by request4.lax.icann.org (Postfix, from userid 48) id A05E32045E; Wed, 19 Feb 2020 16:41:14 +0000 (UTC)
RT-Owner: sabrina.tanamal
From: "Sabrina Tanamal via RT" <drafts-expert-review@iana.org>
Reply-To: drafts-expert-review@iana.org
In-Reply-To: <rt-4.4.3-21645-1582066143-312.1158948-37-0@icann.org>
References: <RT-Ticket-1158948@icann.org> <RT-Ticket-1160802@icann.org> <9c32d171-9a4a-ba71-c989-92a177d9e989@gmx.de> <CA+k3eCSocYYpHQtWAfs=EnOTcOFbRSFH52FK=Ak5RiTZs4nOYA@mail.gmail.com> <77781da882414f4aae98ae2443691933@combitech.se> <CA+k3eCToZEQjkCGUawbWJSg51u24QOvmxBFvKS1Fk+KY4hwELA@mail.gmail.com> <20200124014548.GE90660@kduck.mit.edu> <rt-4.4.3-1037-1580344853-817.1160802-37-0@icann.org> <BY5PR00MB0676BEA2214D2DB7350BD468F5110@BY5PR00MB0676.namprd00.prod.outlook.com> <rt-4.4.3-21645-1582066143-312.1158948-37-0@icann.org>
Message-ID: <rt-4.4.3-22458-1582130474-1504.1158948-37-0@icann.org>
X-RT-Loop-Prevention: IANA
X-RT-Ticket: IANA #1158948
X-Managed-BY: RT 4.4.3 (http://www.bestpractical.com/rt/)
X-RT-Originator: sabrina.tanamal@icann.org
CC: michael.jones@microsoft.com, jwt-reg-review@ietf.org
Content-Type: text/plain; charset="utf-8"
X-RT-Original-Encoding: utf-8
Precedence: bulk
Date: Wed, 19 Feb 2020 16:41:14 +0000
MIME-Version: 1.0
Content-Transfer-Encoding: 8bit
Archived-At: <https://mailarchive.ietf.org/arch/msg/jwt-reg-review/w01MVaDtF1yDl90pXzWMIfm94GQ>
Subject: [Jwt-reg-review] [IANA #1158948] Requested review for IANA registration in draft-ietf-ace-oauth-params (jwt - JSON Web Token Claim)
X-BeenThere: jwt-reg-review@ietf.org
X-Mailman-Version: 2.1.29
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: Wed, 19 Feb 2020 16:41:18 -0000

Hi Mike, 

Thanks for checking. It looks like the JWT claim was removed in version -12. Sorry, we aren't notified of version changes. 

Thanks,
Sabrina

On Tue Feb 18 22:49:03 2020, Michael.Jones@microsoft.com wrote:
> This draft is not making any JWT Claims registration requests, so I'm
> not sure why this expert review request is being made.
> 
> -- Mike
> 
> -----Original Message-----
> From: Jwt-reg-review <jwt-reg-review-bounces@ietf.org> On Behalf Of
> Sabrina Tanamal via RT
> Sent: Wednesday, January 29, 2020 4:41 PM
> Cc: jwt-reg-review@ietf.org
> Subject: [EXTERNAL] [Jwt-reg-review] [IANA #1160802] Re: [Ace]
> Requested review for IANA registration in draft-ietf-ace-oauth-params
> 
> Dear John, Michael, and Chuck,
> 
> Have you had a chance to review the registration in draft-ietf-ace-
> oauth-params?
> 
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Ftools.ietf.org%2Fhtml%2Fdraft-
> ietf-ace-oauth-
> params&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C61ca6b3d9a5c4aab17e508d7a51d1411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637159416642322478&amp;sdata=KyQE29ZaEQ5%2FX7i6pjzkicORKhDtawDFVjMsNk63%2FuE%3D&amp;reserved=0
> 
> Thanks,
> 
> Sabrina Tanamal
> Senior IANA Services Specialist
> 
> > On Thu, Jan 23, 2020 at 02:31:20PM -0700, Brian Campbell wrote:
> > > Apologies, I forgot to reply-all at some earlier point and dropped
> > > the mailing lists and other cc's off the thread. Added back now.
> > >
> > > And also apologies because I think I need to recuse myself from the
> > > DE responsibility on the JWT registry request here. I've spent more
> > > time than I'd like to admit or really have to spare on it and am
> > > still struggling to understand.
> > >
> > > I appreciate you pointing out the authz-info endpoint in ACE but I
> > > still don't follow how "rs_cnf" in an access token would really
> > > work
> > > in practice.
> > > The client sends the token to the RS's authz-info endpoint on an
> > > insecure connection or one that has the server auth with
> > > potentially
> > > different key and the RS stores the access token for later use.
> > > Then
> > > on resource access the RS looks up the access token (with respect
> > > to
> > > the cnf key in it) based on the key the client used in establishing
> > > a new mutually authentication connection to the RS. For the RS to
> > > choose a key for server it will use during the handshake (and as
> > > far
> > > as I know the server key is the first in the authn process of the
> > > handshake) based on the "rs_cnf" in the access token, it needs to
> > > remember and associate that client and the access token with
> > > something else (IP address?) that will be available during the
> > > handshake. It doesn't fit together for me in a way that seems
> > > likely
> > > to work or be interoperable but, like I said, I'm really struggling
> > > to understand.
> > >
> > > On Thu, Jan 16, 2020 at 12:54 AM Seitz Ludwig
> > > <ludwig.seitz@combitech.se>
> > > wrote:
> > >
> > > > Hi Brian,
> > > >
> > > >
> > > >
> > > > Comments inline.
> > > >
> > > >
> > > >
> > > > /Ludwig
> > > >
> > > >
> > > >
> > > > *From:* Brian Campbell <bcampbell@pingidentity.com>
> > > > *Sent:* den 13 januari 2020 21:22
> > > > *To:* Seitz Ludwig <ludwig.seitz@combitech.se>
> > > >  *Subject:* Re: [Ace] Requested review for IANA registration in
> > > > draft-ietf-ace-oauth-params
> > > >
> > > >
> > > >
> > > > Thanks for the response and updates Ludwig,
> > > >
> > > >
> > > >
> > > > Please bear with me while I try to wrap my head around some
> > > > things.
> > > >
> > > >
> > > >
> > > > The JWT registration request for the "rs_cnf" claim points to Sec
> > > > 3.3
> > > > <https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2
> > > > Ftools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params-
> > > > &amp;data=02%
> > > > 7C01%7CMichael.Jones%40microsoft.com%7C61ca6b3d9a5c4aab17e508d7a51
> > > > d1411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637159416642322
> > > > 478&amp;sdata=eGiV%2BpjnegXqzjrDbRKEFd2PLJbt9jFh3cTLQQHJCX8%3D&amp
> > > > ;reserved=0
> > > > 08#section-3.3>
> > > >  saying it is "a hint [in the access token] to the RS about which
> > > >  key it should use to authenticate towards the client".  But
> > > >  doesn't the client have to go through the DTLS/TLS handshake
> > > > with
> > > >  the RS (which is presumably when it authenticates to the client)
> > > > before it presents the access token?
> > > >  I'm not seeing how this would work as seems the RS won't see the
> > > > hint until after it needs it.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > [LS] Not in the ACE flow. We use the access token to establish
> > > > keys at the RS both for the client and the RS. We have therefore
> > > > defined a new ACE-OAuth endpoint (authz-info) at the RS. The
> > > > client can POST access tokens to this endpoint without prior
> > > > authentication.
> > > >
> > > > At that point, the RS only validates the signature/MAC by the AS.
> > > >
> > > >
> > > >
> > > > Later at the time of access, the corresponding token is linked to
> > > > the access request via the pop-mechanism and the client/access
> > > > specific parts are validated (e.g. scope, subject).
> > > >
> > > >
> > > >
> > > > Hope that clarifies things a bit.
> > > >
> > > >
> > > >
> > > > On Sat, Jan 11, 2020 at 8:30 AM Seitz Ludwig
> > > > <ludwig.seitz@combitech.se>
> > > > wrote:
> > > >
> > > > Hello again Brian,
> > > >
> > > >
> > > >
> > > > Thank you for reviewing this! Indeed the handling of JWT/JSON
> > > > interactions was handled sloppily here. I will soon issue a draft
> > > > update that specifies that the JSON-based interactions should use
> > > > the syntax from RFC7800 while the CBOR-based ones should use
> > > > ID.ietf-ace-cwt-proof-of-possession.
> > > >
> > > >
> > > >
> > > > This correction goes for all the use of “cnf”, “req_cnf” and
> > > > “rs_cnf”.
> > > >
> > > >
> > > >
> > > > Regards,
> > > >
> > > >
> > > >
> > > > Ludwig
> > > >
> > > >
> > > >
> > > > *From:* Ace <ace-bounces@ietf.org> *On Behalf Of *Brian Campbell
> > > > *Sent:* den 10 januari 2020 22:12
> > > > *To:* Ludwig Seitz <ludwig_seitz@gmx.de>
> > > >  *Cc:* Roman Danyliw <rdd@cert.org>rg>; jwt-reg-review@ietf.org; Jim
> > > >  Schaad < ietf@augustcellars.com>gt;; The IESG <iesg@ietf.org>rg>;
> > > >  ace@ietf.org; drafts-lastcall@iana.org; Benjamin Kaduk
> > > > <kaduk@mit.edu>
> > > >  *Subject:* Re: [Ace] Requested review for IANA registration in
> > > > draft-ietf-ace-oauth-params
> > > >
> > > >
> > > >
> > > > That  "rs_cnf" claim registration request in 9.1 points to 3.3
> > > > which says it has 'the same syntax and semantics as defined in
> > > > for
> > > > the "rs_cnf"
> > > > parameter', which I think is in 4.1. And 4.1 says that the
> > > > "rs_cnf"
> > > > values
> > > > 'follow the syntax of the "cnf" claim from section 3.1 of
> > > > [I-D.ietf-ace-cwt-proof-of-possession].' Similar to other
> > > > comments
> > > > I've made today, I don't follow what that would mean for the
> > > > value
> > > > of the claim when it's a JWT. And that seems like something
> > > > that's
> > > > important to understand for the purpose of a JWT claims registry
> > > > request.
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Sat, Dec 21, 2019 at 4:11 AM Ludwig Seitz
> > > > <ludwig_seitz@gmx.de>
> > > > wrote:
> > > >
> > > > Hello JWT registry reviewers,
> > > >
> > > > the IESG-designated experts for the JWT claims registry have
> > > > asked
> > > > me to send a review request to you about the "rs_cnf" claim
> > > > registered
> > > > here:
> > > >
> > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > tools.ietf.org%2Fhtml%2Fdraft-ietf-ace-oauth-params-07%23section-
> > > > &
> > > > amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C61ca6b3d9a5c4aa
> > > > b17e508d7a51d1411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637
> > > > 159416642322478&amp;sdata=HUDQlv7KRIJiV2AAFcK9H1jXVcglVisiCFP8lYQ8
> > > > 4tc%3D&amp;reserved=0
> > > > 9.1
> > > >
> > > > Thank you in advance for you review comments.
> > > >
> > > > Regards,
> > > >
> > > > Ludwig
> > > >
> > > > _______________________________________________
> > > > Ace mailing list
> > > > Ace@ietf.org
> > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2F
> > > > www.ietf.org%2Fmailman%2Flistinfo%2Face&amp;data=02%7C01%7CMichael
> > > > .Jones%40microsoft.com%7C61ca6b3d9a5c4aab17e508d7a51d1411%7C72f988
> > > > bf86f141af91ab2d7cd011db47%7C1%7C0%7C637159416642322478&amp;sdata=
> > > > QoMEDPhQNPpLz8mv02OMYVOKKd3DfusKD%2Ftz%2B%2B11Q6I%3D&amp;reserved=
> > > > 0
> > > >
> > > >
> > > > *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.*
> > > >
> > > >
> > > > *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.*
> > > >
> > >
> > > --
> > > _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._
> 
> _______________________________________________
> Jwt-reg-review mailing list
> Jwt-reg-review@ietf.org
> https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.ietf.org%2Fmailman%2Flistinfo%2Fjwt-
> reg-
> review&amp;data=02%7C01%7CMichael.Jones%40microsoft.com%7C61ca6b3d9a5c4aab17e508d7a51d1411%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C637159416642322478&amp;sdata=pTjdeVzoUJftCq0fdasxSzEByik0PsrbHc9x8d9%2FfeM%3D&amp;reserved=0