Re: [OAUTH-WG] oauth-access-token-jwt: comments and clarifications

Benjamin Kaduk <kaduk@mit.edu> Thu, 08 April 2021 19:14 UTC

Return-Path: <kaduk@mit.edu>
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 0F7013A17F7 for <oauth@ietfa.amsl.com>; Thu, 8 Apr 2021 12:14:21 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.498
X-Spam-Level:
X-Spam-Status: No, score=-1.498 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, KHOP_HELO_FCRDNS=0.399, SPF_HELO_NONE=0.001, SPF_NONE=0.001, URIBL_BLOCKED=0.001] autolearn=no 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 VmNlQYxgTp8Z for <oauth@ietfa.amsl.com>; Thu, 8 Apr 2021 12:14:19 -0700 (PDT)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) (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 740E93A17F6 for <oauth@ietf.org>; Thu, 8 Apr 2021 12:14:19 -0700 (PDT)
Received: from kduck.mit.edu ([24.16.140.251]) (authenticated bits=56) (User authenticated as kaduk@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 138JECFf000447 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 8 Apr 2021 15:14:16 -0400
Date: Thu, 8 Apr 2021 12:14:11 -0700
From: Benjamin Kaduk <kaduk@mit.edu>
To: Roberto Polli <robipolli@gmail.com>
Cc: oauth <oauth@ietf.org>
Message-ID: <20210408191411.GU79563@kduck.mit.edu>
References: <CAP9qbHURF22ehJfQ3=8v1X07wueAcBUFG4HUq6KYda8NA+3=nw@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <CAP9qbHURF22ehJfQ3=8v1X07wueAcBUFG4HUq6KYda8NA+3=nw@mail.gmail.com>
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/1b4IODkk3KRDUViS8EeNQMTXruY>
Subject: Re: [OAUTH-WG] oauth-access-token-jwt: comments and clarifications
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: Thu, 08 Apr 2021 19:14:21 -0000

Hi Roberto,

On Fri, Apr 02, 2021 at 11:55:27AM +0200, Roberto Polli wrote:
> Hi Vittorio et al,
> 
> some considerations on oauth access token jwt follows.
> You can see them here too
> https://docs.google.com/document/d/1XsvBzGvhcY0N6vJNgLx6G1dJ5trvgwYRJA9F_NCakbU/edit
> 
> An example with client_credential grant type would be nice too.
> 
> My 2¢,
> R.
> 
> § 1.2  Terminology
> 
> + The terms "Collision-Resistant",  is used according to Section 2 of
> {{JWT}}.
> 
> §2.1 Header
> 
> - mentioning "none" alg can be redundant. I'd reference all the JWT BCP
> instead.
> - I'd add an example header, eg
> 
> ~~~ example
> 
> {
> 
>   "typ": "at+jwt",
> 
>   "alg": "PS256"
> 
> }
> 
> ~~~
> 
> 
> § 2.2.1 Authentication Information Claims
> 
> Is it worth mentioning the "implicit flow"?
> 
> §2.2.2 Identity Claims
> 
> - use the "Collision-Resistant" definition in {{JWT}}
> 
> §2.2.3 Authorization Claims
> 
> - " ... scope parameter..."  should `scope` be quoted?
> -  "All the individual scope strings in the "scope" claim MUST have meaning
> for the resources indicated in the "aud" claim."
> ^ otherwise the error returned is ...? Should we reference §4 here?
> 
> §2.2.3.1 Claims for Authorization Outside of Delegation Scenarios
> - which are the delegated scenarios described in RFC7519? Do you refer to
> "When using an administratively delegated
>       namespace" ? It is not clear to a first-reader.
> 
> §3 Requesting a JWT Access Token
> - an example with `client_credential` grant type would be great.
> - iiuc `jti` is required, the example does not report it.

That's a very good catch; thank you!

-Ben

> §4 Validating JWT Access Tokens
> 
> - the step about forbidding "none" is limitative WRT JWT BCP 8725

> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth