Re: [OAUTH-WG] Token Introspection: Misc Review Comments

Justin Richer <jricher@mit.edu> Wed, 04 March 2015 21:31 UTC

Return-Path: <jricher@mit.edu>
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 8F64E1A1B98 for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2015 13:31:49 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.211
X-Spam-Level:
X-Spam-Status: No, score=-4.211 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, RCVD_IN_DNSWL_MED=-2.3, 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 zU-SNFlQLA6J for <oauth@ietfa.amsl.com>; Wed, 4 Mar 2015 13:31:47 -0800 (PST)
Received: from dmz-mailsec-scanner-7.mit.edu (dmz-mailsec-scanner-7.mit.edu [18.7.68.36]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id C6DEA1A1ABF for <oauth@ietf.org>; Wed, 4 Mar 2015 13:31:46 -0800 (PST)
X-AuditID: 12074424-f79356d000004839-50-54f779c13164
Received: from mailhub-auth-2.mit.edu ( [18.7.62.36]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by dmz-mailsec-scanner-7.mit.edu (Symantec Messaging Gateway) with SMTP id 38.2D.18489.1C977F45; Wed, 4 Mar 2015 16:31:45 -0500 (EST)
Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-2.mit.edu (8.13.8/8.9.2) with ESMTP id t24LViXO001431; Wed, 4 Mar 2015 16:31:44 -0500
Received: from artemisia.richer.local (static-96-237-195-53.bstnma.fios.verizon.net [96.237.195.53]) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id t24LVgZc009708 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Wed, 4 Mar 2015 16:31:44 -0500
Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2070.6\))
Content-Type: multipart/signed; boundary="Apple-Mail=_023B9FF0-266C-496D-9661-971C0B6B8EF2"; protocol="application/pgp-signature"; micalg=pgp-sha1
X-Pgp-Agent: GPGMail 2.5b5
From: Justin Richer <jricher@mit.edu>
In-Reply-To: <54F5942C.5010405@gmx.net>
Date: Wed, 4 Mar 2015 16:31:49 -0500
Message-Id: <D6F72848-3CD3-4607-BA57-95365B656AEA@mit.edu>
References: <54F5942C.5010405@gmx.net>
To: Hannes Tschofenig <hannes.tschofenig@gmx.net>
X-Mailer: Apple Mail (2.2070.6)
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFjrAKsWRmVeSWpSXmKPExsUixG6nonuw8nuIwcRDfBZLd95jtTj59hWb A5PH4k372TyWLPnJFMAUxWWTkpqTWZZapG+XwJWx7eRLloLZihUz7j9jamD8KdXFyMkhIWAi 0TDvFxuELSZx4d56IJuLQ0hgMZPEns5rzBDOBkaJqdPvsUA4D5gkDq9axQrSIizgKHGk7S9Y O6+AgcTcU1+YQIqYBSYxSrQe28UCMVdK4sHtNYwgNpuAqsT0NS1MIDangLrEgoa/7F2MHBws AioSK/utQExmoHD7SReIkVYSMw5MAKsWElCTuHq7B2ytiIChxPWZ01lByiUE5CV6NqVPYBSc heSIWciOAEkwC2hLLFv4mhnC1pTY370cKi4vsf3tHKi4pcTimTeg4rYSt/oWMEHYdhKPpi1i XcDIsYpRNiW3Sjc3MTOnODVZtzg5MS8vtUjXXC83s0QvNaV0EyM4clxUdjA2H1I6xCjAwajE w3sg9luIEGtiWXFl7iFGSQ4mJVFev4rvIUJ8SfkplRmJxRnxRaU5qcWHGFWAdj3asPoCoxRL Xn5eqpIIr50LUB1vSmJlVWpRPkyZNAeLkjjvph98IUIC6YklqdmpqQWpRTBZGQ4OJQleC5AF gkWp6akVaZk5JQhpJg7OQ4wSHDxAw7NAaniLCxJzizPTIfKnGBWlxHkNQRICIImM0jy4XljC e8UoDvSWMO8SkCoeYLKE634FNJgJaPAtxS8gg0sSEVJSDYzBh2/MbUyvv/L7YtR59f9xRXIK zKzWuepF0x9vl3kSdUfju/n0uz/yZ+zPZV1q2aXAp/ddyWzhpqS0JI9kax9FJ5WSnlvFjxON xSe3HtSfdeTAtT65WfNkrqup9FbWfl2fcfuu/ifpRdFfyw2YBFeqBYSzFEwVOHFjcaLYwvrv ri8+6m+ftVuJpTgj0VCLuag4EQBaB0X2UwMAAA==
Archived-At: <http://mailarchive.ietf.org/arch/msg/oauth/hk-TMt5gUnnTXfKuEtzl58D-Kf8>
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [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: Wed, 04 Mar 2015 21:31:49 -0000

> On Mar 3, 2015, at 5:59 AM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
> 
> 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.
> 


Thanks, this is more accurate.


> 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.
> 
> 

This has been common verbiage, but after Kathleen’s comments on Dyn-Reg we probably want to adopt that block of text instead anyway, which includes the TLS BCP reference.


> 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.
> 
> 

Good point, previous drafts didn’t reference the registry so this needs to be upgraded to normative.


> 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.

It’s always a tradeoff and we can give some guidance, but we’re not going to solve cache consistency here. Can you suggest text for how to strike this balance?


> 
> 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.

That seems like reasonable guidance, can you suggest text?

Thanks,
 — Justin


> 
> Ciao
> Hannes
> 
> 
> 
> 
> 
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth