[OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 03 March 2015 10:56 UTC

Return-Path: <hannes.tschofenig@gmx.net>
X-Original-To: oauth@ietfa.amsl.com
Delivered-To: oauth@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 60B331A0149 for <oauth@ietfa.amsl.com>; Tue, 3 Mar 2015 02:56:30 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.91
X-Spam-Level:
X-Spam-Status: No, score=-1.91 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, T_RP_MATCHES_RCVD=-0.01] autolearn=ham
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 ESwIVsLeEmxe for <oauth@ietfa.amsl.com>; Tue, 3 Mar 2015 02:56:28 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.15.15]) (using TLSv1.2 with cipher DHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 572A21A00DC for <oauth@ietf.org>; Tue, 3 Mar 2015 02:56:28 -0800 (PST)
Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx001) with ESMTPSA (Nemesis) id 0M2t0Q-1XbKto1m0E-00shCH for <oauth@ietf.org>; Tue, 03 Mar 2015 11:56:26 +0100
Message-ID: <54F59359.5020601@gmx.net>
Date: Tue, 03 Mar 2015 11:56:25 +0100
From: Hannes Tschofenig <hannes.tschofenig@gmx.net>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.4.0
MIME-Version: 1.0
To: "oauth@ietf.org" <oauth@ietf.org>
OpenPGP: id=4D776BC9
Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="w8E7bBFp8fTGvxL9pdP4iKmRR0QMqQcn9"
X-Provags-ID: V03:K0:Flz+9t2uz2bZ11DiyUCIqxdqCnqPbWCdA9hDyhvPMNtP7BDskEf XmN+F+mToGypPOKxmifUe57CngGMWRrKCkQ6mnrdZXW1vYR6Na0HiaAATN8bZXFEYGBPHjG +iwrROi+m1jz4nQNqJWVi8EfbCHEd2pKTrLIHtLZcNWZgezzw6BAs5o6kXdiPGpuA+HXVbH uBYqE0CmW45oMiP89DnXQ==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/peHuqEF-fAMeWygCsqXIqhbNG34>
Subject: [OAUTH-WG] Alignment of JWT Claims and Token Introspection "Claims"
X-BeenThere: oauth@ietf.org
X-Mailman-Version: 2.1.15
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: <http://www.ietf.org/mail-archive/web/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, 03 Mar 2015 10:56:30 -0000

Hi Justin, Hi all,

in OAuth we provide two ways for a resource server to make an
authorization decision.

1) The resource server receives a self-contained token that contains all
the necessary information to make a local authorization decision. With
the JWT we have created such a standardized information and data model.

2) With an access request from a client the resource server asks the
authorization server for "help". The authorization server provides
information that help make the authorization decision. This is the token
introspection approach.

I believe the two approaches need to be aligned with regard to the
information and the data model. Since both documents already use JSON as
a way to encode information (=data model) and almost have an identical
information model (the data that is being passed around).

What needs to be done?

 * Use the term 'claims' in both documents.
 * Use the same registry (i.e., the registry established with the JWT).
 * Register the newly defined claims from the token introspection
document in the claims registry.

Then, I have a few comments on the new claims that are proposed:

Here is the definition of the 'active' claim:

   active
      REQUIRED.  Boolean indicator of whether or not the presented token
      is currently active.  The authorization server determines whether
      and when a given token is in an active state.

This claim is not well-defined. You need to explain what "active" means.
It could, for example, mean that the token is not yet expired. Then,
there is of course the question why you are not returning the 'exp'
claim together with the 'nbf' claim.

client_id: What is the resource server going to do with the client_id?
What authorization decision could it make?

I have a couple of reactions when I read the 'user_id' claim:
  - I believe the inclusion of a user id field in the response could
lead to further confusion regarding OAuth access token usage for
authentication.

  - Since you define it as a human readable identifier I am wondering
whether you want to say something about the usage. Here it seems that it
might be used for displaying something on a webpage rather than making
an authorization decision but I might well be wrong.

  - I am missing a discussion about the privacy implications of it.
While there is a privacy consideration section I am wondering what
controls the release of this sensitive information from the
authorization server to the resource server. While in some cases the two
parties might belong to the same organization but in other cases that
may not necessarily be true.

  - In terms of the information exchanged about the user I am curious
about the usefulness of including other information as well, such as the
info that is included in an id token (see
http://openid.net/specs/openid-connect-core-1_0.html#IDToken). If this
has nothing to do with the ID token concept and the information carried
within it then I would add that remark.

Ciao
Hannes