Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Mike Jones <Michael.Jones@microsoft.com> Tue, 21 April 2020 18:08 UTC

Return-Path: <Michael.Jones@microsoft.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 05CAB3A0924 for <oauth@ietfa.amsl.com>; Tue, 21 Apr 2020 11:08:37 -0700 (PDT)
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, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_BLOCKED=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=microsoft.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 i1MmK8h5Q5fU for <oauth@ietfa.amsl.com>; Tue, 21 Apr 2020 11:08:34 -0700 (PDT)
Received: from NAM06-DM3-obe.outbound.protection.outlook.com (mail-eopbgr640135.outbound.protection.outlook.com [40.107.64.135]) (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 06C153A08EC for <oauth@ietf.org>; Tue, 21 Apr 2020 11:07:41 -0700 (PDT)
ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Dj+puUEsW9PwEQNyETDRQZneu7DfXOWuW1827nr9wQhvN8eLDQOEPv4CBmPn8Ej4kED1mV8k45UYOlhmS+LizJthfSrs5UUAWf5iQFAyUtgFexhOGzwQZ3hzEh5BcQXAb2IuJr35rqPkRwpe60eBYigkmYTY9FeIe6KuRxyL9QLlsimcLLueMYq+sHmaJoPtyGcBokPTBgHhIP3uCImn5LXYlHPEK9SyPAF2Fk1HkKu8Hcgi4wp4vhmHDr4QlJhVDdyk/aaP5BrSAz8KJhTiQ6JNs4G+EiInnBilIBPYp0czRu3EJtMjPOPNTIQ9Jnad6xFzMHxIG1wVV1083oYZ8Q==
ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h68Kcm3ZiA7eVclDcH9A0/8UZYNpUKd1CeM3HfZFM+s=; b=HC+Pj8X/N1M9WrFCTBO53yT4Dz5+UTb1a/XgeKNVWBJ567vVIG8dr9x2gL0zDYD7Mgde6gywemLX1I95dQ5P/a8srGOxV/BOxHI6eDs179aqXv73fcKDuaJhKyQMeK98EMLxB4FJj4Q6c0sz/lCnsvoCcj7g8GwU4lCuuw4QJAFpx4DHAzb0OV1hFnOhcBd2Om5qcm4VhByKLPLiP1pSqUIfVRwRBUufa4yxthGzHfYObXgb+MkJxIyXHkbKZjg/PHVR13FDmAKT025Bgayzk6jim+M1gsqgeIlyx7U3qcGjdDsRIBD62YHri+TkVOPvnd9Li6qyOYodLgYb7x6b+g==
ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=microsoft.com; dmarc=pass action=none header.from=microsoft.com; dkim=pass header.d=microsoft.com; arc=none
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=selector2; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=h68Kcm3ZiA7eVclDcH9A0/8UZYNpUKd1CeM3HfZFM+s=; b=Cjtp1kivG7SCguSTizyoaHhFZWtp0OrO2nP6FtCb62jU5MZnDw5ufz8RP/uYoxp9VMYsFyfsWsueQ5WATut8uE8z67FDM6CoSX+DYLLiLuh30W66FMeCx2T/BAR8n3UzNXlJ47CdwYE5TgQBoNOJGKzMBtp+N3jpjGczE6Nz44M=
Received: from CH2PR00MB0678.namprd00.prod.outlook.com (2603:10b6:610:a9::23) by CH2PR00MB0680.namprd00.prod.outlook.com (2603:10b6:610:7b::7) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.2971.0; Tue, 21 Apr 2020 18:07:37 +0000
Received: from CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::f40e:3a03:cb3:3276]) by CH2PR00MB0678.namprd00.prod.outlook.com ([fe80::f40e:3a03:cb3:3276%6]) with mapi id 15.20.2973.000; Tue, 21 Apr 2020 18:07:37 +0000
From: Mike Jones <Michael.Jones@microsoft.com>
To: oauth <oauth@ietf.org>, Vittorio Bertocci <Vittorio@auth0.com>
Thread-Topic: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: AdYYB6pDYW6Oyu7JT7+X3TjjJM1Xcg==
Date: Tue, 21 Apr 2020 18:07:37 +0000
Message-ID: <CH2PR00MB0678F20EF90E9FDBD8C3A705F5D50@CH2PR00MB0678.namprd00.prod.outlook.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
msip_labels: MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ActionId=9f0c9e8c-d062-4091-9da2-0000c627d177; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_ContentBits=0; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Enabled=true; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Method=Standard; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_Name=Internal; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SetDate=2020-04-21T18:05:28Z; MSIP_Label_f42aa342-8706-4288-bd11-ebb85995028c_SiteId=72f988bf-86f1-41af-91ab-2d7cd011db47;
authentication-results: spf=none (sender IP is ) smtp.mailfrom=Michael.Jones@microsoft.com;
x-originating-ip: [50.47.87.252]
x-ms-publictraffictype: Email
x-ms-office365-filtering-ht: Tenant
x-ms-office365-filtering-correlation-id: 25d974f9-f862-4d5d-49f3-08d7e61edffe
x-ms-traffictypediagnostic: CH2PR00MB0680:
x-microsoft-antispam-prvs: <CH2PR00MB068071C16FABC8F88E411A49F5D50@CH2PR00MB0680.namprd00.prod.outlook.com>
x-ms-oob-tlc-oobclassifiers: OLM:9508;
x-forefront-prvs: 038002787A
received-spf: None (protection.outlook.com: microsoft.com does not designate permitted sender hosts)
x-ms-exchange-senderadcheck: 1
x-microsoft-antispam: BCL:0;
x-microsoft-antispam-message-info: lHg/eF168HwHCqdyZpqbc4wClq66bk/SCWw5g+/Y0TxCSAhoeQ7szK8wi8oDcYrtBgpQYw0LzZJ+RbLMG09oclvYfj2gUvgDGYBKjejvL52C1Li9D2Zmyijs6+HKKrhmERV/chZqsmBv5RZ4fqGAQJ5zgQ6fHEqfyqayEoVqwktR5UKE+7S2G0CrMPPF7gmO/N7BykaBvCtk6mNtZ5G+D+aPUB2UeoiJUf5AfFGRC5gj8MzzXFC41H5aS5sd7BPqmY+mU73CiogQCRdJi7yAgjDtl6B8Bzb9cLXqx+b2+locQ3vnTpZfHrfNjEy03JqE+gP5nNIGInDBJMkxvXbGUpEQOklvzZ3MZTCRT/kuumJYRd0liBf+DBtwkE2QVXanvEco+JsEVT2BhyxE31dhwT75VB3F9tjUHM4Siu5sc8oDATmP0PUnP5XVnEZwPyleJngqAsRRko7Ev5O0T/oMylj7XjHAreinUGqXJW8Qql1fV8z7/V5LCr8DZqJ8RtktlZJD+LtPRqIUbvnAV9hMEA==
x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR00MB0678.namprd00.prod.outlook.com; PTR:; CAT:NONE; SFTY:; SFS:(4636009)(39860400002)(346002)(396003)(136003)(376002)(366004)(186003)(66556008)(110136005)(316002)(52536014)(9686003)(4326008)(64756008)(66446008)(86362001)(2906002)(966005)(478600001)(66476007)(10290500003)(66946007)(76116006)(8676002)(71200400001)(53546011)(82950400001)(82960400001)(8936002)(33656002)(55016002)(6506007)(7696005)(5660300002)(26005)(8990500004); DIR:OUT; SFP:1102;
x-ms-exchange-antispam-messagedata: H5je4HCPS8u6xi5Pv8iBhv5W11t/PEsuzAV4m4YF2dOQtWp2F9MifhOjlYEsZwf9PNmvVhabHb0vyWyPNL17xLY0ikACbciWqmPdxbuwILvSmcFqU8F+yiuEv0SEHKraH9m/rsfZP3FvSwwkUh6rOjgf6b89Y6OcAOfW0o82CH3Ib1mPJAhu1bZ0IqKk9q7h4Uc8uppS8BUQBGze4GTHZ56+0df/6SIRZruqlpcQsqFdDkKWbuFdoo20gEIGXJ1ANAdLyxPoY3O4dkUJFrreZWIC3cBfVFFvetcNiPGJKlloDY4K4dncYadcu7S+IrQ8kvwFN72QZ3YfET7MhER449XdYrhtACptxJfV/T933MkLxcDZZpCSuvRK8Tu9bx+JCblPJvihshuMxCCK6/TowlLjsW6WUiO+0bkh32HNLBc4M/4u1+GGSjk15xOeUVKd5EaaLAy7ee6ex7CdJFLj50HH/TqSkImYpbMa+Sdsv0I9hzl3ScMf5x0GgbPEpLJsVtkqceLSa5ruJB3nU0i1CQKztAwAORZ5/LvRsMbroVlh8Pp2H3JfMMuW0G97lvFCIiBbBA8dsk9VmjiHRSTXX5tYt7wtcpNuddHmpojxd8NTBMX9wjc2Na+99X8sIBmA5byKO60/Jw96YiN2vV9l7BbapjK86FD7YSuGRw71C92RYJOEwGSb68t5MVVglPkJ6wx0b7WsGf4X9aRZSEK1m7Lqe/mLVyrt+oog/3yVCZsICAKPP8OaFcn10wQSGXmFjgJdtGAeYryxpkIgsM2xn6cIqphyXgyNsxHngAu2M18=
x-ms-exchange-transport-forked: True
Content-Type: multipart/alternative; boundary="_000_CH2PR00MB0678F20EF90E9FDBD8C3A705F5D50CH2PR00MB0678namp_"
MIME-Version: 1.0
X-OriginatorOrg: microsoft.com
X-MS-Exchange-CrossTenant-AuthAs: Internal
X-MS-Exchange-CrossTenant-AuthSource: CH2PR00MB0678.namprd00.prod.outlook.com
X-MS-Exchange-CrossTenant-Network-Message-Id: 25d974f9-f862-4d5d-49f3-08d7e61edffe
X-MS-Exchange-CrossTenant-originalarrivaltime: 21 Apr 2020 18:07:37.6451 (UTC)
X-MS-Exchange-CrossTenant-fromentityheader: Hosted
X-MS-Exchange-CrossTenant-id: 72f988bf-86f1-41af-91ab-2d7cd011db47
X-MS-Exchange-CrossTenant-mailboxtype: HOSTED
X-MS-Exchange-CrossTenant-userprincipalname: yb7PPSlWqJonuC90yTD1sDBUzn2dfCzeArgOSIn9abxr9GRcY7dDe3w4Nk9RNUf4DZCvXzkOl3X+voGrmq9kqw==
X-MS-Exchange-Transport-CrossTenantHeadersStamped: CH2PR00MB0680
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/5ecOS6N-VSPJR5KoBBoiHk2CJtg>
Subject: Re: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
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, 21 Apr 2020 18:08:37 -0000

This feedback is from a Microsoft engineer on the Azure Active Directory identity team:


  *   1
     *   Missing space at “Tokens(JWT)”
  *   2.1
     *   Use of “MUST” saying one form must be used, followed by “SHOULD” saying a different format should be used is a bit confusing. I get the point, but I had to read it several times.
     *   Missing space at “Therefore,the”
  *   2.2.1
     *   References the definitions of “acr”, “amr” and “auth_time” from OpenID Connect. In OpenID Connect, these explicitly refer to the end-user’s authentication. Does this mean these claims should only be used when the subject is a user? If so, then it might be good to clarify. If not (and these also apply for client credentials, for example), then a reference to OpenID Connect may not be ideal.
  *   2.2.2
     *   Use of “resource owner” suggests the resource owner is the subject of the token. This is not always true. In client credentials it’s not, and even in scenarios with a user, is it necessarily the resource owner who is authenticated/authorized? (Or could it be a different user who has been separate authorized for the requested access by the resource owner?)
  *   2.2.3.1
     *   Link to section 4.1.2 of SCIM Core is actually linking to section 4.1.2 of this doc.
     *   States “groups”, “roles” and “entitlements” in SCIM don’t have a vocabulary defined, but as far as I can tell, “groups” does have a syntax defined in SCIM.
  *   3
     *   Missing newline in the example, before “&state”
  *   4
     *   States the configuration metadata is used to: “advertise to resource servers [and] what iss claim value to expect via the issuer metadata value”. This seems circular, since the configuration metadata is itself obtained by appending a suffix to a known (and trusted) issuer value, right?
     *   “AS” I used without having been introduced as abbreviation of “authorization server”.
     *   States that any JWT token with “typ” value other than “at+jwt” must be rejected.
        *   The value “application/at+jwt” should also be accepted.
        *   As written, this might be interpreted to mean there is no possibility of a future JWT token profile to be specified for use as a Bearer token (e.g. one with media type “application/example+jwt”). I believe the intent is to say that if the “typ” value is not “at+jwt”, it should rejected for this profile. (But maybe that’s already understood?)
     *   Third bullet suggests the issuer identifier is obtained through discovery. Discovery defines the location of the metadata to be derived from the issuer identifier. This circular reference is confusing.
     *   Use of singular suggests there is only one possible “aud” value that a resource server would accept.
     *   States the signing key must be obtained from the authorization server. Is this requirement necessary? (E.g. I believe Azure AD supports a resource server owner providing a custom signing key, in which case the RS is not retrieving the signing key from the AS.)
     *   I expected some reference to JWT validation steps from RFC 7519
  *   5
     *   “as this would allow malicious clients to select the sub of a high privilege resource owner”: the subject of the access token is not necessarily the resource owner (e.g. client credentials).
     *   “To preventing cross-JWT confusion”: might be good to reference section 2.8 of RFC 8725 to clarify what “cross-JWT confusion” is
     *   “each scope string included in the resulting JWT access token, if any, can be unambiguously correlated to a specific resource among the ones listed in the aud claim” specifies an unambiguous mapping, but section 2.1.1 of RFC8693<https://tools.ietf.org/html/rfc8693#section-2.1.1> suggests a Catesian product of resources and scopes is possible, meaning that one scope value could (legitimately) map to multiple audience values. It’s unclear if the intent here is to avoid the ambiguity for specifying that it must not be ambiguous, or if there’s a slight conflict between the specs.
     *   Extra ‘n’ at “OpennID Connect’
  *   7.1.1
     *   Typo at “JTW”
     *   Missing ‘A’ at “N/”
  *   7.2
     *   Missing space at ‘”roles”,”groups”’
  *   Reference:
     *   No link to OpenID.Core
  *   All over:
     *   Missing double quotes around claim and parameter names (e.g. 2.2, 2.2.3), which is inconsistent with other OAuth 2.0 specs, I think.


From: OAuth <oauth-bounces@ietf.org> On Behalf Of Rifaat Shekh-Yusef
Sent: Wednesday, April 15, 2020 11:59 AM
To: oauth <oauth@ietf.org>
Subject: [OAUTH-WG] Second WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Hi all,

This is a second working group last call for "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens".

Here is the document:
https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-06

Please send your comments to the OAuth mailing list by April 29, 2020.

Regards,
 Rifaat & Hannes