IETF Logo Mail Archive

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

Vittorio Bertocci <vittorio.bertocci@auth0.com> Tue, 24 March 2020 19:07 UTC

Return-Path: <vittorio.bertocci@auth0.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 7D4483A079E for <oauth@ietfa.amsl.com>; Tue, 24 Mar 2020 12:07:36 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.098
X-Spam-Level:
X-Spam-Status: No, score=-2.098 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, HTML_MESSAGE=0.001, 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 (2048-bit key) header.d=auth0.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 cXZRTKHjrf3N for <oauth@ietfa.amsl.com>; Tue, 24 Mar 2020 12:07:34 -0700 (PDT)
Received: from mail-qt1-x830.google.com (mail-qt1-x830.google.com [IPv6:2607:f8b0:4864:20::830]) (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 5F9BD3A1250 for <oauth@ietf.org>; Tue, 24 Mar 2020 12:07:34 -0700 (PDT)
Received: by mail-qt1-x830.google.com with SMTP id c14so3492781qtp.0 for <oauth@ietf.org>; Tue, 24 Mar 2020 12:07:34 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=auth0.com; s=google; h=from:to:cc:subject:thread-topic:thread-index:date:message-id :references:in-reply-to:accept-language:content-language :mime-version; bh=XRe7NjENDcYesu3rsxO5vzFBzoJADPGHnmrvXm9z1MY=; b=rIXv5TIUCbVaQuTPBI0Yg4ikaQkEOxRyeLAJ/Yb8GOFiXPxi4M2Y5oH6LZzbSN13z2 vo9bQYlQBpBmxvD3oj+GHp8I7L01OoU1OrQkHM28d/O7BCLDTCPv3lZ3iTnGWEPR8w/h Tpl9FOJU+9J/xlmLHUNbaR9cbPahW85nLQop5Fljc5sMfQQWdsQURYu8Ce4klYq96e2z sNf9vEL5f9o75sMn2QZFhjBZwPtwJWp8J39UN8TtZXA5kfywdm2bl19Rl6T9GTD6boPb /x5K9f9wxzfJmRbyyscU41v2U9hEfrITIqoSLqEuIAZx6GZxcGiOI/MadFcgTRUVRIBf nX5Q==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:thread-topic:thread-index :date:message-id:references:in-reply-to:accept-language :content-language:mime-version; bh=XRe7NjENDcYesu3rsxO5vzFBzoJADPGHnmrvXm9z1MY=; b=uYqlMP5Fqn1pP3L6h2cRfuZy4EAb+Gzfo31Nvo4B+/CuYFqsrfjHMi5wm5rt4PSXCN M703Dr0VOT/VgaX1u7kntm5IlCXlEwnRqHuwd2gWO6+3gidIp2AjCPgIwLUAPyDCFgQN guxGq2trsK/ZKKDptPOhaO80Oi7s6N2dcUYWRawEkZ5go3whL2vR9u09VjN+0CDFENbt tWWxl+ge4YjpUYpaju269vwRM7NrovOtBjtbaLAyZC9QsTxlOZ1oI7DiJnrtFor5Uuo0 3IG1rTUTCY2NoTG2dFyK+tImcfwZ94KrflcoYudF/17XHvoTTn7qQy8ZzCBvj1Bd62bx 1phg==
X-Gm-Message-State: ANhLgQ0BSBe5vvhm9S4qN79PMY7IRorRcH+FOv/M29/XqSZCgzxq/Mzq Bu9T0/Wjc1k7b7G7ORGgoG1MqepvrFIzzA==
X-Google-Smtp-Source: ADFU+vvq6HcBoiszalCZn1u/dyZB5VBR17aNjj93XejHq210CUw4gBVVW6gk/qKRmoMV8paFpaSCSQ==
X-Received: by 2002:aed:2625:: with SMTP id z34mr28659082qtc.276.1585076852948; Tue, 24 Mar 2020 12:07:32 -0700 (PDT)
Received: from BL0PR08MB5394.namprd08.prod.outlook.com ([2603:1036:302:851::5]) by smtp.gmail.com with ESMTPSA id e61sm11043956qtb.88.2020.03.24.12.07.32 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Tue, 24 Mar 2020 12:07:32 -0700 (PDT)
From: Vittorio Bertocci <vittorio.bertocci@auth0.com>
To: George Fletcher <gffletch=40aol.com@dmarc.ietf.org>, Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>, Takahiko Kawasaki <taka@authlete.com>
CC: oauth <oauth@ietf.org>
Thread-Topic: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"
Thread-Index: ATBEMUEzVgkZHyweZLG8Yidi1aurtiQ4MiRkd2pRMG5nQVl6WTU4M2Q0wbrb7Eg=
X-MS-Exchange-MessageSentRepresentingType: 1
Date: Tue, 24 Mar 2020 19:07:31 +0000
Message-ID: <BL0PR08MB5394CA3CB524E95EA87CD6B6AEF10@BL0PR08MB5394.namprd08.prod.outlook.com>
References: <AM0PR08MB37160B8A021052198699CD17FAF00@AM0PR08MB3716.eurprd08.prod.outlook.com> <01ec01d6017c$162eb2e0$428c18a0$@aueb.gr> <CAHdPCmMzRn8iYG025Vq0sQNzgZTOkQJuMJwttDgjMDLESpjptw@mail.gmail.com> <CAO_FVe5UXY4Jxd3LdG6zyXJ8B8nFKYevcHQTVJEAFSdW0ku9tg@mail.gmail.com> <52f18114-4f8e-da86-5735-4c4e8f8d2db5@aol.com>
In-Reply-To: <52f18114-4f8e-da86-5735-4c4e8f8d2db5@aol.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-Exchange-Organization-SCL: -1
X-MS-TNEF-Correlator:
X-MS-Exchange-Organization-RecordReviewCfmType: 0
Content-Type: multipart/alternative; boundary="_000_BL0PR08MB5394CA3CB524E95EA87CD6B6AEF10BL0PR08MB5394namp_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/rxTB3I6yaSdQMTgBGU9nmD1qz-g>
Subject: Re: [OAUTH-WG] 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, 24 Mar 2020 19:07:54 -0000

You are too fast 😊 I am still replying to your other comments! 😃
Yes, it is possible for resource servers to define sub-resource specific scopes, but it cannot be mandated- and it can be extremely problematic when your AS is multitenant. The resource identifier in those scenarios can be a LONG URI, and forcing people to do scope stuffing (eg : csutomresource:// 1f150b81-c98e-45ec-8252-ab47ef0645ff/read) is hard from the management, provisioning and even bandwidth use standpoints. I have experienced this firsthand when Azure AD moved from v1 style resource identification (where resource was a mandatory request param) to v2, where the resource was inferred from the scopes via scopes stuffing.

From: OAuth <oauth-bounces@ietf.org> on behalf of George Fletcher <gffletch=40aol.com@dmarc.ietf.org>
Date: Tuesday, March 24, 2020 at 11:48
To: Vittorio Bertocci <Vittorio=40auth0.com@dmarc.ietf.org>, Takahiko Kawasaki <taka@authlete.com>
Cc: oauth <oauth@ietf.org>
Subject: Re: [OAUTH-WG] WGLC on "JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens"

Focusing just on this comment...

This assumes the system uses a specific implementation of scopes values (e.g. 'read', 'write', 'delete'). It is very possible that in the context of a calendar services and an inbox service... the system defines scopes like 'cal-r', 'cal-w', 'mail-r', mail-w' in which there is no ambiguity.
On 3/24/20 2:14 PM, Vittorio Bertocci wrote:

  I don't think the rule referring to the "scope" parameter is worth being

defined. That "aud" is missing but "scope" is available is enough for

resource servers. In other words, if "aud" is determined based on the

"scope", why do we have to set "aud" redundantly?

Scope is actually not sufficient for many resource servers. Whenever an RS

is facading a collection of existing finer grained resources, scopes

representing permissions might be ambiguous - if my API facades both

calendar and inbox, what does the "read" scope refer to? Having an audience

resolves that ambiguity.

v2.23.0 | Report a Bug | By Email