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 >
- [OAUTH-WG] Confirmation: Call for Adoption of "OA… Hannes Tschofenig
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Eve Maler
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Bill Mills
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Tirumaleswar Reddy (tireddy)
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Mark Dobrinic
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Paul Madsen
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Mike Jones
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Bill Mills
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Eve Maler
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… George Fletcher
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Mike Jones
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Mike Jones
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Justin Richer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Anthony Nadalin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Phil Hunt
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Eve Maler
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Tirumaleswar Reddy (tireddy)
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Thomas Broyer
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Sergey Beryozkin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Sergey Beryozkin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… John Bradley
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Sergey Beryozkin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… John Bradley
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Sergey Beryozkin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… George Fletcher
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… George Fletcher
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… George Fletcher
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… John Bradley
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Anthony Nadalin
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… John Bradley
- Re: [OAUTH-WG] Confirmation: Call for Adoption of… Brian Campbell