[OAUTH-WG] Status summary of document in AD Evaluation status

Roman Danyliw <rdd@cert.org> Tue, 19 January 2021 14:10 UTC

Return-Path: <rdd@cert.org>
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 312AE3A151C for <oauth@ietfa.amsl.com>; Tue, 19 Jan 2021 06:10:48 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.099
X-Spam-Level:
X-Spam-Status: No, score=-2.099 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (1024-bit key) header.d=cert.org
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 HBcoeToRNtGh for <oauth@ietfa.amsl.com>; Tue, 19 Jan 2021 06:10:45 -0800 (PST)
Received: from taper.sei.cmu.edu (taper.sei.cmu.edu [147.72.252.16]) (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 5106E3A151B for <oauth@ietf.org>; Tue, 19 Jan 2021 06:10:45 -0800 (PST)
Received: from delp.sei.cmu.edu (delp.sei.cmu.edu [10.64.21.31]) by taper.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 10JEAhoV008742 for <oauth@ietf.org>; Tue, 19 Jan 2021 09:10:44 -0500
DKIM-Filter: OpenDKIM Filter v2.11.0 taper.sei.cmu.edu 10JEAhoV008742
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=cert.org; s=yc2bmwvrj62m; t=1611065444; bh=jJhrEVRm/VXJizEtPoXO4Jl6j9B9UhnEh5vNyX6yTkk=; h=From:To:Subject:Date:From; b=sW7JQocGQG8Ce9s45Yqd3PcmuFPlLKHoOnLf38LNsvHbT0whJPzCjfgPjNujMyFfw jA+rNrqBCMPT9THUy9TQ4ekerYKA0TwuVxeDXzHOS3IP41TPW+A1YO6aRkMlmxtQOl qJ0Cb8zwajmDZp6d7GKPCctLjPzqE172lFv6SkwY=
Received: from MORRIS.ad.sei.cmu.edu (morris.ad.sei.cmu.edu [147.72.252.46]) by delp.sei.cmu.edu (8.14.7/8.14.7) with ESMTP id 10JEAdnL035581 for <oauth@ietf.org>; Tue, 19 Jan 2021 09:10:39 -0500
Received: from MORRIS.ad.sei.cmu.edu (147.72.252.46) by MORRIS.ad.sei.cmu.edu (147.72.252.46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.2106.2; Tue, 19 Jan 2021 09:10:39 -0500
Received: from MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb]) by MORRIS.ad.sei.cmu.edu ([fe80::555b:9498:552e:d1bb%13]) with mapi id 15.01.2106.002; Tue, 19 Jan 2021 09:10:39 -0500
From: Roman Danyliw <rdd@cert.org>
To: "oauth@ietf.org" <oauth@ietf.org>
Thread-Topic: Status summary of document in AD Evaluation status
Thread-Index: AdbubEWrYMo70AXPSgiZWGEVZkUzVA==
Date: Tue, 19 Jan 2021 14:10:37 +0000
Message-ID: <e348eecb3b3b41cda26fca5b21603dbf@cert.org>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.64.203.24]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/oEFC4rwdmcEtxu5tH48RYd_U5SI>
Subject: [OAUTH-WG] Status summary of document in AD Evaluation status
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: Tue, 19 Jan 2021 14:10:48 -0000

Hi!

Below is a summary explanation of where all of the documents that are with me (as AD) stand.  I hope this better explains the status in the datatracker.  

==[ draft-ietf-oauth-access-token-jwt
Status: AD Evaluation::Revised I-D Needed
(aka, after WG LC but before IETF LC pending edits the AD has requested)

Pending edits from AD review confirmed at https://mailarchive.ietf.org/arch/msg/oauth/t57XP7RICTpoI3FbOyrY0gpsNnE/.  After these are merged, this document can proceed to IESG Review.

==[ draft-ietf-oauth-jwsreq
Status: Status: Waiting for AD Go-Ahead:Revised I-D Needed
(aka, after the second WG and IETF LC, but IETF LC Directorate reviews require action)

All AD review and individual IETF LC feedback was addressed.

A few outstanding updates remain from the IETF LC SECDIR review -- https://mailarchive.ietf.org/arch/msg/secdir/5CrZTLR8v6cm8wZVkfY_Yywckcw/.

After these changes are made, this document can return for IESG Review.

==[ draft-ietf-oauth-jwt-introspection-response
Status: Waiting for AD Go-Ahead:Revised I-D Needed
(aka, after the second WG and IETF LC, but IESG DISCUSS position from first IESG requires actions)

-10 addressed:

* the 2nd AD review  -- https://mailarchive.ietf.org/arch/msg/oauth/6VPGZxXt12WRgXe4IXsWN7UA054/
* and the negotiated text from the thread in the 2nd IETF LC -- https://mailarchive.ietf.org/arch/msg/last-call/ZdceEhKUiBSmrBfKm2Nqa2jYs4Q/

Outstanding are closure on two DISCUSS points from the -08 IESG ballot (https://datatracker.ietf.org/doc/draft-ietf-oauth-jwt-introspection-response/ballot/) 

* Ben Kaduk said: It looks like we need to register 'active' as a JWT claim?

'active' appears to be registered in https://www.iana.org/assignments/oauth-parameters/oauth-parameters.xhtml#token-introspection-response, but I believe Ben's point is that it is NOT registered in https://www.iana.org/assignments/jwt/jwt.xhtml#claims

* Ben Kaduk also said: 

I don't think the new semantics for "jti" in the introspection response are compatible with the RFC 7519 definition.  Specifically, we say that "jti" will be tied to the input access token, but 7519 says that "jti"
has to change when the contents of the JWT change ("MUST be assigned in a manner that ensures that there is a negligible probability that the same value will be accidentally assigned to a different data object"), and we admit at least the possibility of "active" and "iat" changing.

Checking Section 5 of the -10, it contains:

         If the access token is invalid, expired, revoked, or is not
           intended for the calling resource server (audience), the
           authorization server MUST set the value of the "active"
           member in the "token_introspection" claim to "false" and
           other members MUST NOT be included.  Otherwise, the "active"
           member is set to "true".

I believe this is the source of Ben's concern.

Other necessary actions:

* Updated Shepherd write-up to capture the 2nd IETF LC feedback

Regards,
Roman