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

Vittorio Bertocci <> Wed, 24 July 2019 15:19 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id EEC4A1202BE for <>; Wed, 24 Jul 2019 08:19:04 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.998
X-Spam-Status: No, score=-1.998 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: (amavisd-new); dkim=pass (2048-bit key)
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id XGcUPpa19SOU for <>; Wed, 24 Jul 2019 08:19:00 -0700 (PDT)
Received: from ( [IPv6:2a00:1450:4864:20::129]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id BDE7C120371 for <>; Wed, 24 Jul 2019 08:18:58 -0700 (PDT)
Received: by with SMTP id r15so15242770lfm.11 for <>; Wed, 24 Jul 2019 08:18:58 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=Ljkdhx+uI6syLGXMMWROvzUedbboDqhsBBkcI4id/nU=; b=A6DzQfi20rlPpVX4rKK3PkIU3iHHOj4axYDUwPYuKcw+3IuJ2n6eQ8K8pETSmlQ5PG Qij5DNSdrAGDzU5etplqV4UBbVBuBeKGJ2uySM2ucRjDhfJaVv22RTgOSFoUhcYx9ca8 OYG99nEi+K9a0pTdicWHKI26nqKTzgCafCI2u/EXnTLddvCOCCKsoWwoxyexYCFRccdE dNGS1sy2+nJ6HQ5WJBKwpLAQobjkdxWnX54+V57JsX3Lspm1R0h/W8yjZmJOBknq6w6a Lp4RuWCYXg2jJBDEOgdkAHBiD8Aw6gbKW9vWesCE+/qlSU1nczqEZEEAkIcvE2hV9mVX OBHg==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=Ljkdhx+uI6syLGXMMWROvzUedbboDqhsBBkcI4id/nU=; b=AjFhki47Cj9nPFK2GZ9h3Born6z3FoGCyCTJQvwc7F7DeZX09TPYobB4iBaZ9SpGjX 1b4iA/kzCcwljOgQ0l+4qOzdbCygzDo7ErMa80DLr6ZXNsrpL0ZhejPz6Ieq5ncuMdwm NSASLb84gX6eUci50tvK91dt4jvnjmMVd/8u+VNiNFYAhk5LRNcyWrzL0NHVFKHbco20 aEBAKmQ87ocwwW71N1tIO2dGML2rOyBmny6nyvhFBw7mNwkx9PTSGK8HEpJzm5Ceijtp nicOrYFDUioujTTbXA167DZmckr6+31JDZhoLcHN6fAs1DSjpiIkqMP1ZCfm1eP8DVp6 br4Q==
X-Gm-Message-State: APjAAAVoy8+SA+i0vrSnaQZMx434yl1C4ATh1z7oXtppCAYnSlQWSukW 6Q4ej5BMkToqHBb+mOhb9P5zQJ0iNyRRIRcTN+p0lpYUapPdxQ==
X-Google-Smtp-Source: APXvYqz/tQrTEW0Lk2y2B/rY85FhfV8f1xKRTUwJlMKJHfzFaowT1knVNSs2NHxO7t+QPAfjJdQVYYKI1ao54gD65ss=
X-Received: by 2002:a19:80c4:: with SMTP id b187mr37128570lfd.122.1563981536740; Wed, 24 Jul 2019 08:18:56 -0700 (PDT)
MIME-Version: 1.0
References: <> <>
In-Reply-To: <>
From: Vittorio Bertocci <>
Date: Wed, 24 Jul 2019 08:18:46 -0700
Message-ID: <>
To: Petteri Stenius <>
Cc: "" <>
Content-Type: multipart/alternative; boundary="000000000000eedbb1058e6ed342"
Archived-At: <>
Subject: Re: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 24 Jul 2019 15:19:05 -0000

Hi Petteri,
thanks for your comments!
Re: indicator in resource indicator
One of the big goals of the profile is to promote interoperability, but
ultimately the choice of what style should be used to represent ATs falls
on each AS. In my experience most AS instances choose one style (opaque or
JWT) and stick with that rather than offering a choice, hence although I
see how adding an explicit reference to the desired style would make the
client feel empowered on the matter, in practice it would not make much of
a difference. The client can find out from the AS documentation what
particular choice that AS made.
A further consideration: the AT style is largely a matter between the AS
and the RS, given that it is the latter that needs to worry about how to
validate incoming ATs- hence the requestor (the client) should't probably
have much say about the matter. What if the API only knows how to validate
JWT ATs but the client selects opaque?

On introspection: let me think a bit more about it. One of the reasons for
which various AS instances issue AT as JWT is to avoid
implementing/exposing an introspection endpoint. The consideration about
revocation is valid IMO, but I am not sure if imposing use of introspection
would fly in practice.


On Wed, Jul 24, 2019 at 7:00 AM Petteri Stenius <>; wrote:

> Hi Vittorio,
> Thanks for working on this. I think this will be valuable. I have a couple
> of comments.
> About relationship of this draft with token exchange, introspection and
> revocation:
> Should there be a distinct Token Type Identifier defined for JWT Access
> Token, to enable exchange of reference type access token and value type
> access token? I'm thinking of a use case where I want authorization code
> flow to return an opaque reference token and I want my backend services to
> exchange this into a value token, to avoid further introspection on the
> backend side.
> Introspection (and userinfo) with JWT Access Token should work as
> expected. If a JWT Access Token is revoked then introspection response
> should become negative. Is it reasonable to add text that advises the
> resource server to invoke introspection if it wants to make sure the token
> has not been revoked?
> Thanks,
> Petteri
> -----Original Message-----
> From: OAuth <>; On Behalf Of
> Sent: sunnuntai 21. heinäkuuta 2019 15.55
> To:
> Cc:
> Subject: [OAUTH-WG] I-D Action: draft-ietf-oauth-access-token-jwt-01.txt
> 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-01.txt
>         Pages           : 15
>         Date            : 2019-07-20
> Abstract:
>    This specification defines a profile for issuing OAuth2 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:
> There are also htmlized versions available at:
> A diff from the previous version is available at:
> Please note that it may take a couple of minutes from the time of
> submission until the htmlized version and diff are available at
> Internet-Drafts are also available by anonymous FTP at:
> _______________________________________________
> OAuth mailing list