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

From: Tangui Le Pense <[email-masked]>
Date: Mon, 20 Jul 2020 23:23:45 +0300

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, [email-masked] пишет:
> 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
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Tue, 21 Jul 2020 16:45:34 -0400

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=[email-masked]> 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:
> 
> 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
> 
>