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

Sergey Beryozkin <sberyozkin@gmail.com> Wed, 30 July 2014 07:49 UTC

Return-Path: <sberyozkin@gmail.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 694881B2933 for <oauth@ietfa.amsl.com>; Wed, 30 Jul 2014 00:49:33 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -1.5
X-Spam-Level:
X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, SPF_PASS=-0.001, URI_NOVOWEL=0.5] 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 HDVKvI8vapgV for <oauth@ietfa.amsl.com>; Wed, 30 Jul 2014 00:49:31 -0700 (PDT)
Received: from mail-wi0-x22f.google.com (mail-wi0-x22f.google.com [IPv6:2a00:1450:400c:c05::22f]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 83E2F1ABB33 for <oauth@ietf.org>; Wed, 30 Jul 2014 00:49:30 -0700 (PDT)
Received: by mail-wi0-f175.google.com with SMTP id ho1so7036381wib.2 for <oauth@ietf.org>; Wed, 30 Jul 2014 00:49:29 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; bh=pAa826UacKyHp1y9k8eS89mWhd/sU8e+sBZjCIjb+wU=; b=b1uuptToNlMLKJFSdDolM3jPifRVhR1unlpj8LvCmG6gEbo+ia2y1glW5oMEbHan// mXMLJDH4+yn6ZZSK0KJUPVX1bntBIUuUeknBE09F9UlZoS8/1XJFswPcsB1xjIymyEW+ O5S5KuzWBnZzA0I+imwbFXMmfOy5+Q4YC5/joXv3i5/qE+BtjmEWoaQtzUiHLbzRn3JF yvFJjYP/EC+xWCxPc/0AQqKm67ZN68H3GhYJIG2thx7cdYxBKpR8YvMyhxUIhak+sU4i gYjBjXFXsZDNm8LOgqw/RPnQg+NoCK1nmG2snvEzRLZGllL0AOYvDdGOeCZJdiHK8Sgi XUfQ==
X-Received: by 10.180.12.79 with SMTP id w15mr4346422wib.35.1406706568963; Wed, 30 Jul 2014 00:49:28 -0700 (PDT)
Received: from [10.39.0.31] ([87.252.227.100]) by mx.google.com with ESMTPSA id 20sm3547828wjt.42.2014.07.30.00.49.27 for <oauth@ietf.org> (version=TLSv1 cipher=ECDHE-RSA-RC4-SHA bits=128/128); Wed, 30 Jul 2014 00:49:28 -0700 (PDT)
Message-ID: <53D8A386.6010309@gmail.com>
Date: Wed, 30 Jul 2014 10:49:26 +0300
From: Sergey Beryozkin <sberyozkin@gmail.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: oauth@ietf.org
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> <A729ABFB-9395-4E07-823E-E0D894D77769@oracle.com> <2E4485F3-8283-40E9-930E-53D149F2D5AA@xmlgrrl.com>
In-Reply-To: <2E4485F3-8283-40E9-930E-53D149F2D5AA@xmlgrrl.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Archived-At: http://mailarchive.ietf.org/arch/msg/oauth/2qo-2ISzp6QKoWYkvjEAQqmD3vE
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 07:49:33 -0000

On 30/07/14 04:45, Eve Maler wrote:
> I would say that if an RS and AS are relatively tightly coupled and have
> established their trust "off stage", then the RS will know where to go
> and how to interpret the results.
+1. It is an obvious answer, there has to be a trust established between 
RS and AS.
let me ask Phil: How does RS know today, when it asks AS to return the 
info about a given token that the AS endpoint is authoritative ?
Thanks, Sergey
> If an RS and AS are entirely loosely
> coupled, then there are a number of options for trust establishment for
> which UMA provides one solution, leveraging an OAuth-protected token
> introspection endpoint and an endpoint discovery mechanism.
>
> (BTW, I first wrote about this usage of token introspection on this list
> in November 2012
> <http://www.ietf.org/mail-archive/web/oauth/current/msg10230.html>,
> where I distinguished "shallow" and "deep" options for RS/AS communication.)
>
> Eve
>
> On 29 Jul 2014, at 6:17 PM, Phil Hunt <phil.hunt@oracle.com
> <mailto:phil.hunt@oracle.com>> wrote:
>
>> 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
>> <mailto: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
>>>> <mailto: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
>>>>> <mailto: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
>>>>>     <mailto:t.broyer@gmail.com>]
>>>>>     *Sent:* Tuesday, July 29, 2014 5:43 PM
>>>>>     *To:* Mike Jones
>>>>>     *Cc:* <oauth@ietf.org <mailto: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
>>>>>     <mailto: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
>>>>>     <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 <mailto: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 <mailto: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
>>>>>             <mailto: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 <mailto:OAuth@ietf.org>
>>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>             --
>>>>>             Thomas Broyer
>>>>>             /tɔ.ma.bʁwa.je/ <http://xn--nna.ma.xn--bwa-xxb.je/>
>>>>>
>>>>>             _______________________________________________
>>>>>             OAuth mailing list
>>>>>             OAuth@ietf.org <mailto:OAuth@ietf.org>
>>>>>             https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>>>
>>>>>
>>>>>         _______________________________________________
>>>>>
>>>>>         OAuth mailing list
>>>>>
>>>>>         OAuth@ietf.org  <mailto: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 <mailto:OAuth@ietf.org>
>> https://www.ietf.org/mailman/listinfo/oauth
>
>
> Eve Maler http://www.xmlgrrl.com/blog
> +1 425 345 6756 http://www.twitter.com/xmlgrrl
>
>
>
> _______________________________________________
> OAuth mailing list
> OAuth@ietf.org
> https://www.ietf.org/mailman/listinfo/oauth
>