Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-07.txt

Justin Richer <jricher@mit.edu> Tue, 21 July 2020 20:45 UTC

Return-Path: <jricher@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 B724D3A0A83; Tue, 21 Jul 2020 13:45:38 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.919
X-Spam-Level:
X-Spam-Status: No, score=-1.919 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_MSPIKE_H4=-0.01, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=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 V3TyMvL60ErU; Tue, 21 Jul 2020 13:45:36 -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 8575B3A0A6A; Tue, 21 Jul 2020 13:45:36 -0700 (PDT)
Received: from [192.168.1.3] (static-71-174-62-56.bstnma.fios.verizon.net [71.174.62.56]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.14.7/8.12.4) with ESMTP id 06LKjYVP022831 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Tue, 21 Jul 2020 16:45:35 -0400
Content-Type: text/plain; charset="utf-8"
Mime-Version: 1.0 (Mac OS X Mail 13.4 \(3608.80.23.2.2\))
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <03b759e7-ddff-8904-09c5-0d420270233f@mail.ru>
Date: Tue, 21 Jul 2020 16:45:34 -0400
Cc: oauth@ietf.org
Content-Transfer-Encoding: quoted-printable
Message-Id: <F6F451EA-A683-4957-90C5-C041F8AD83AB@mit.edu>
References: <158801203979.26415.5550810597232016504@ietfa.amsl.com> <03b759e7-ddff-8904-09c5-0d420270233f@mail.ru>
To: Tangui Le Pense <tangui.lepense=40mail.ru@dmarc.ietf.org>
X-Mailer: Apple Mail (2.3608.80.23.2.2)
Archived-At: <https://mailarchive.ietf.org/arch/msg/oauth/T0NZklRdwI9IJ16OMlLOmkx7u0Y>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-07.txt
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 Jul 2020 20:45:45 -0000

An RS is not considered an OAuth 2 client, though there’s enough overlap in the structure that I know several implementations that store RS records in the same table as the client records with a special flag set on them to differentiate.

The RS <-> AS communication channel has never really gotten a formal definition in OAuth 2. The closest we’ve come is Token Introspection, which is RFC7662, and even there we didn’t define a set of authentication and discovery mechanisms. Instead, we piggybacked off of the token endpoint. This has proven to be problematic in practice and has lead to an explosion of the kind of additional metadata fields like you list below.

 — Justin

> On Jul 20, 2020, at 4:23 PM, Tangui Le Pense <tangui.lepense=40mail.ru@dmarc.ietf.org> wrote:
> 
> Hello,
> 
> A few late remarks and questions about this version of the draft. Sorry if it was already answered, but I haven't found answers in the previous emails.
> 
> Section 2.1: in case the JWT is signed then encrypted, which jwt should include the "typ" parameter with the "at+jwt" value? The outer encrypted JWT (JWE), the inner signed JWT (JWS) or both?
> 
> Section 3: the example is missing the "iat" and "jti" fields that are mandatory per section 2.2:
> 
>   {"typ":"at+JWT","alg":"RS256","kid":"RjEwOwOA"}
>   {
>     "iss": "https://authorization-server.example.com/",
>     "sub": " 5ba552d67",
>     "aud":   "https://rs.example.com/",
>     "exp": 1544645174,
>     "client_id": "s6BhdRkqt3_",
>     "scope": "openid profile reademail"
>   }
> 
> Section 4 "Validating JWT Access Tokens":
> 
>   o  If the JWT access token is encrypted, decrypt it using the keys
>      and algorithms that the resource server specified during
>      registration.  If encryption was negotiated with the authorization
>      server at registration time and the incoming JWT access token is
>      not encrypted, the resource server SHOULD reject it.
> 
> The registration details are not documented. As an RS seems to be a special case of an OAuth2 client (without any grant type granted, except, possibily, "client_credentials") I was expecting registration of dynamic client registration metadata similar to those for ID tokens (something like "access_token_signed_response_alg", "access_token_encrypted_response_alg" and "access_token_encrypted_response_enc"), and same for discovery metadata.
> 
> Is the rationale for the absence of the registration of these fields that RSes are not considered as OAuth2 clients?
> 
> Also, in the same section, nothing is said about the validation of "iat" and "jti".
> 
> Regards,
> 
> -- 
> 
> Tangui
> 
> 
> 27.04.2020 21:27, internet-drafts@ietf.org пишет:
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Web Authorization Protocol WG of the IETF.
>> 
>>         Title           : JSON Web Token (JWT) Profile for OAuth 2.0 Access Tokens
>>         Author          : Vittorio Bertocci
>> 	Filename        : draft-ietf-oauth-access-token-jwt-07.txt
>> 	Pages           : 19
>> 	Date            : 2020-04-27
>> 
>> Abstract:
>>    This specification defines a profile for issuing OAuth 2.0 access
>>    tokens in JSON web token (JWT) format.  Authorization servers and
>>    resource servers from different vendors can leverage this profile to
>>    issue and consume access tokens in interoperable manner.
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-oauth-access-token-jwt/
>> 
>> There are also htmlized versions available at:
>> https://tools.ietf.org/html/draft-ietf-oauth-access-token-jwt-07
>> https://datatracker.ietf.org/doc/html/draft-ietf-oauth-access-token-jwt-07
>> 
>> A diff from the previous version is available at:
>> https://www.ietf.org/rfcdiff?url2=draft-ietf-oauth-access-token-jwt-07
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth