Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

Phil Hunt <phil.hunt@oracle.com> Wed, 30 July 2014 01:17 UTC

Return-Path: <phil.hunt@oracle.com>
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 C651A1B2A35 for <oauth@ietfa.amsl.com>; Tue, 29 Jul 2014 18:17:59 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.2
X-Spam-Level:
X-Spam-Status: No, score=-4.2 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, MIME_QP_LONG_LINE=0.001, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] 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 gIQrdLyaPOnF for <oauth@ietfa.amsl.com>; Tue, 29 Jul 2014 18:17:56 -0700 (PDT)
Received: from userp1040.oracle.com (userp1040.oracle.com [156.151.31.81]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 871771B2A31 for <oauth@ietf.org>; Tue, 29 Jul 2014 18:17:56 -0700 (PDT)
Received: from acsinet22.oracle.com (acsinet22.oracle.com [141.146.126.238]) by userp1040.oracle.com (Sentrion-MTA-4.3.2/Sentrion-MTA-4.3.2) with ESMTP id s6U1Hrig031875 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Jul 2014 01:17:54 GMT
Received: from aserz7021.oracle.com (aserz7021.oracle.com [141.146.126.230]) by acsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6U1Hqjl016516 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 30 Jul 2014 01:17:53 GMT
Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserz7021.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id s6U1HqP2005674; Wed, 30 Jul 2014 01:17:52 GMT
Received: from [192.168.1.125] (/24.86.29.34) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Tue, 29 Jul 2014 18:17:52 -0700
References: <53D6895F.4050104@gmx.net> <CAEayHEM+pqDqv1qx=Z-qhNuYM-s2cV0z=sQb_FAJaGwcLpq_rQ@mail.gmail.com> <20A36D56-D581-4EDE-9DEA-D3F9C48AD20B@oracle.com> <53D81F2C.2060700@aol.com> <4E1F6AAD24975D4BA5B16804296739439ADF77B2@TK5EX14MBXC293.redmond.corp.microsoft.com> <CAEayHEPdHyfLGzdb=Go=0L1+K4WEju+9zddekR2YQz=cqtZzeA@mail.gmail.com> <4E1F6AAD24975D4BA5B16804296739439ADF7A6F@TK5EX14MBXC293.redmond.corp.microsoft.com> <CAEayHEPBwvDhwymRoRrdC51LiUBHita0-Cwxtvtf1LRqT2dokg@mail.gmail.com> <5C8461F3-CD04-4F5E-9BDF-6E91336D5F50@oracle.com> <53D8455B.1030303@mit.edu>
Mime-Version: 1.0 (1.0)
In-Reply-To: <53D8455B.1030303@mit.edu>
Content-Type: multipart/alternative; boundary=Apple-Mail-4299ED13-5ED3-4A95-B09A-32DD67B45094
Content-Transfer-Encoding: 7bit
Message-Id: <A729ABFB-9395-4E07-823E-E0D894D77769@oracle.com>
X-Mailer: iPhone Mail (11D257)
From: Phil Hunt <phil.hunt@oracle.com>
Date: Tue, 29 Jul 2014 18:17:49 -0700
To: Justin Richer <jricher@mit.edu>
X-Source-IP: acsinet22.oracle.com [141.146.126.238]
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/beSjNSfUlBVTWS1Yq1DFZDftsAQ
Cc: "<oauth@ietf.org>" <oauth@ietf.org>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
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, 30 Jul 2014 01:17:59 -0000

Mike's proposal may be sufficient for Thomas' case given a small token lifetime. 

The federated cases may have other issues....

How does the RS know who issued the opaque token and what introspection point is authoritative? 

I am not saying your spec is not the right answer. I am just not prepared to limit functionality yet by adopting the draft until we have sufficient requirements understood. 

Let the rest of us catch up please. 

Phil

> On Jul 29, 2014, at 18:07, Justin Richer <jricher@mit.edu> wrote:
> 
> So you want a service where the RS can call an HTTP endpoint to see if the token is alive or not? That sounds like an awesome idea! Very useful for a variety of use cases that people have already mentioned on that list. Maybe that service should respond in JSON with, say, { "active": true } if it's still valid. That's a great start, and that should obviously be MTI.
> 
> But while we're there, we probably want to know what else the token is for, since this service will probably know that, so let's add in the "scope" and "client_id" and whatever other meta-information we have about the token. If this endpoint doesn't have that information? Well then, I guess it can't return it. So we need to make sure to be flexible about that while we define a common core set of semantics. Flexibility like that is very powerful and could be used in a variety of protocols and deployments across domains and vendors.
> 
> You know, this idea is sounding better and better. In fact, I'll do you one better. I think this is such a fantastic idea that I wrote it all down in RFC format:
> 
> http://tools.ietf.org/html/draft-richer-oauth-introspection-06
> 
> Glad to have you on board, Phil.
> 
>  -- Justin
> 
>> On 7/29/2014 9:02 PM, Phil Hunt wrote:
>> I think one alternative to an introspection service is a revocation status service. 
>> 
>> But it is often not needed if token lifetimes are small (minutes / session life) compared to the refresh token which might last much longer. 
>> 
>> Again having info on the case helps explain the requirements of your case and we can tell what the best pattern is. 
>> 
>> Phil
>> 
>> On Jul 29, 2014, at 17:55, Thomas Broyer <t.broyer@gmail.com> wrote:
>> 
>>> Try it where? When you're the RS trying to determine whether you should accept the token or reject it?
>>> 
>>> Le 30 juil. 2014 02:49, "Mike Jones" <Michael.Jones@microsoft.com> a écrit :
>>>> Yes, but that’s the simplest thing to determine – try the token and see whether it works or not.
>>>> 
>>>>  
>>>> 
>>>> From: Thomas Broyer [mailto:t.broyer@gmail.com] 
>>>> Sent: Tuesday, July 29, 2014 5:43 PM
>>>> To: Mike Jones
>>>> Cc: <oauth@ietf.org>; George Fletcher; Phil Hunt
>>>> Subject: RE: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
>>>> 
>>>>  
>>>> 
>>>> Decoding a token with a specific format wouldn't tell you whether the token is still live: it could have been revoked before its expiration.
>>>> 
>>>> Le 30 juil. 2014 02:16, "Mike Jones" <Michael.Jones@microsoft.com> a écrit :
>>>> 
>>>> Did you consider standardizing the access token format within that deployment so all the parties that needed to could understand it, rather requiring an extra round trip to an introspection endpoint so as to be able to understand things about it?
>>>> 
>>>>  
>>>> 
>>>> I realize that might or might not be practical in some cases, but I haven’t heard that alternative discussed, so I thought I’d bring it up.
>>>> 
>>>>  
>>>> 
>>>> I also second Phil’s comment that it would be good to understand the use cases that this is intended to solve before embarking on a particular solution path.
>>>> 
>>>>  
>>>> 
>>>>                                                                                         -- Mike
>>>> 
>>>>  
>>>> 
>>>> From: OAuth [mailto:oauth-bounces@ietf.org] On Behalf Of George Fletcher
>>>> Sent: Tuesday, July 29, 2014 3:25 PM
>>>> To: Phil Hunt; Thomas Broyer
>>>> Cc: oauth@ietf.org
>>>> Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
>>>> 
>>>>  
>>>> 
>>>> We also have a use case where the AS is provided by a partner and the RS is provided by AOL. Being able to have a standardized way of validating and getting data about the token from the AS would make our implementation much simpler as we can use the same mechanism for all Authorization Servers and not have to implement one off solutions for each AS.
>>>> 
>>>> Thanks,
>>>> George
>>>> 
>>>> On 7/28/14, 8:11 PM, Phil Hunt wrote:
>>>> 
>>>> Could we have some discussion on the interop cases?
>>>> 
>>>>  
>>>> 
>>>> Is it driven by scenarios where AS and resource are separate domains? Or may this be only of interest to specific protocols like UMA?
>>>> 
>>>>  
>>>> 
>>>> From a technique principle, the draft is important and sound. I am just not there yet on the reasons for an interoperable standard. 
>>>> 
>>>>  
>>>> 
>>>> Phil
>>>> 
>>>> 
>>>> On Jul 28, 2014, at 17:00, Thomas Broyer <t.broyer@gmail.com> wrote:
>>>> 
>>>> Yes. This spec is of special interest to the platform we're building for http://www.oasis-eu.org/
>>>> 
>>>>  
>>>> 
>>>> On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <hannes.tschofenig@gmx.net> wrote:
>>>> 
>>>> Hi all,
>>>> 
>>>> during the IETF #90 OAuth WG meeting, there was strong consensus in
>>>> adopting the "OAuth Token Introspection"
>>>> (draft-richer-oauth-introspection-06.txt) specification as an OAuth WG
>>>> work item.
>>>> 
>>>> We would now like to verify the outcome of this call for adoption on the
>>>> OAuth WG mailing list. Here is the link to the document:
>>>> http://datatracker.ietf.org/doc/draft-richer-oauth-introspection/
>>>> 
>>>> If you did not hum at the IETF 90 OAuth WG meeting, and have an opinion
>>>> as to the suitability of adopting this document as a WG work item,
>>>> please send mail to the OAuth WG list indicating your opinion (Yes/No).
>>>> 
>>>> The confirmation call for adoption will last until August 10, 2014.  If
>>>> you have issues/edits/comments on the document, please send these
>>>> comments along to the list in your response to this Call for Adoption.
>>>> 
>>>> Ciao
>>>> Hannes & Derek
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> 
>>>> 
>>>>  
>>>> 
>>>> -- 
>>>> Thomas Broyer
>>>> /tɔ.ma.bʁwa.je/
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>> 
>>>> 
>>>> 
>>>> _______________________________________________
>>>> OAuth mailing list
>>>> OAuth@ietf.org
>>>> https://www.ietf.org/mailman/listinfo/oauth
>> 
>> 
>> _______________________________________________
>> OAuth mailing list
>> OAuth@ietf.org
>> https://www.ietf.org/mailman/listinfo/oauth
>