[OAUTH-WG] Token Introspection: Misc Review Comments

Hannes Tschofenig <hannes.tschofenig@gmx.net> Tue, 03 March 2015 11:00 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 A5CFF1A1A0B for <oauth@ietfa.amsl.com>; Tue, 3 Mar 2015 03:00:02 -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 371fLmvIQTIX for <oauth@ietfa.amsl.com>; Tue, 3 Mar 2015 03:00:00 -0800 (PST)
Received: from mout.gmx.net (mout.gmx.net [212.227.17.21]) (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 5CF721A00DC for <oauth@ietf.org>; Tue, 3 Mar 2015 03:00:00 -0800 (PST)
Received: from [192.168.131.140] ([80.92.121.102]) by mail.gmx.com (mrgmx102) with ESMTPSA (Nemesis) id 0MK3bN-1YRN6p0v8n-001NHb for <oauth@ietf.org>; Tue, 03 Mar 2015 11:59:58 +0100
Message-ID: <54F5942C.5010405@gmx.net>
Date: Tue, 03 Mar 2015 11:59:56 +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="VCuB916cdcxgAbqvKWeKSHmEePA0diwIf"
X-Provags-ID: V03:K0:FhIxiGGripfHzg3fZdgk1RSPKscYB7dt2BrPmrCxPQt8X+VpKA3 ka7Bk0pprDUlPfK+qE57Cvg0sRU9vsR6XYrw0GS5fXXDfzzGvSL/P224E0HoOz9mA0LbKpM JIRv6EVfl3sm7elZWo21lIAM0wNKRR9gY6oWFbBKgH5gR8xLsl39xIS3LBPYYMSwICggXQT 9ctzimRwMTfz0kKDotO2Q==
X-UI-Out-Filterresults: notjunk:1;
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/PBatbx6HTrllgu9Y8kTG4_h4AHE>
Subject: [OAUTH-WG] Token Introspection: Misc Review Comments
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 11:00:02 -0000

Hi Justin, Hi all,

here are some random review comments:

FROM:

"   Since
   OAuth 2.0 [RFC6749] defines no direct relationship between the
   authorization server and the protected resource, only that they must
   have an agreement on the tokens themselves, there have been many
   different approaches to bridging this gap.
"

TO:
"  Since OAuth 2.0 [RFC6749] does not define a protocol between the
   authorization server and the resource server to retrieve
   meta-data associated with the access token different approaches to
   bridge this gap have been developed.
"

Reason: OAuth 2.0 assumes a relationship between the authorization
server and the resource server since otherwise the resource
server wouldn't be able to trust the content of the access token.

FROM:

"
   The introspection endpoint MUST be protected by TLS of at least
   version 1.2 RFC 5246 [RFC5246] and MAY support additional transport-
   layer mechanisms meeting its security requirements.
"

TO:


"
   The introspection endpoint MUST be protected by TLS of at least
   version 1.2 RFC 5246 [RFC5246].
"

Reason: I have no idea what the "additional transport layer mechanisms are.


JWT is listed as an informative reference. I believe it needs to be
normative because you depend on the registry being re-used.

   [JWT]      Jones, M., Bradley, J., and N. Sakimura, "JSON Web Token
              (JWT)", draft-ietf-oauth-json-web-token (work in
              progress), July 2014.


You write:
>   The response MAY be cached by the protected resource.

It might be worthwhile to say that it may be cached not longer than the
lifetime of the token. It would also be good to mention that there is a
trade-off between caching and a real-time check in terms of revocation.

You write:

   Specific implementations MAY extend this structure with their own
   service-specific pieces of information as top-level members of this
   JSON object.

Here I would add that the inclusion of non-standardized tokens need to
be based on the agreement between the authorization server and the
resource server to avoid confusion and potentially elevation of
authorization priviliges.

Ciao
Hannes