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

"Tirumaleswar Reddy (tireddy)" <> Wed, 30 July 2014 05:03 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id A3D821A0AD6 for <>; Tue, 29 Jul 2014 22:03:19 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -14.501
X-Spam-Status: No, score=-14.501 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_HI=-5, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001, USER_IN_DEF_DKIM_WL=-7.5] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id wvpqE85X6Bmy for <>; Tue, 29 Jul 2014 22:03:16 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 761C01A0AFA for <>; Tue, 29 Jul 2014 22:03:15 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;;; l=28762; q=dns/txt; s=iport; t=1406696595; x=1407906195; h=from:to:cc:subject:date:message-id:references: in-reply-to:mime-version; bh=3WgthYqCZHjGAmQ7ehPUICUW3BXPvsq/yS6oQidFVdI=; b=hq7mINWsNNMlJ47Dr8oSoYYHdVjGhtN9u0Ue9jjQ/xnFMFG6SlbBLt7k MqensvBWoFq7G0XHpwfPi5x9BhJXPhFuNKE7yptHZHUX5+9CmRd6AV7jQ j7CpIUL8LqnFmQkzoNqDTWZnZqRJZLeCiZxxaT0iqHDFqJfD88MdKWRkQ Q=;
X-IronPort-Anti-Spam-Filtered: true
X-IronPort-AV: E=Sophos; i="5.01,762,1400025600"; d="scan'208,217"; a="65057981"
Received: from ([]) by with ESMTP; 30 Jul 2014 05:03:12 +0000
Received: from ( []) by (8.14.5/8.14.5) with ESMTP id s6U53CNU028048 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=FAIL); Wed, 30 Jul 2014 05:03:12 GMT
Received: from ([]) by ([]) with mapi id 14.03.0123.003; Wed, 30 Jul 2014 00:03:12 -0500
From: "Tirumaleswar Reddy (tireddy)" <>
To: Justin Richer <jricher@MIT.EDU>, Mike Jones <>, Thomas Broyer <>
Thread-Topic: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
Date: Wed, 30 Jul 2014 05:03:11 +0000
Message-ID: <>
References: <> <> <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_913383AAA69FF945B8F946018B75898A282FCD52xmbrcdx10ciscoc_"
MIME-Version: 1.0
Cc: "<>" <>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Wed, 30 Jul 2014 05:03:20 -0000

Token revocation will require unsolicited update from AS to RS that the token is no longer valid, it will be useful to add this communication mechanism in this draft.


From: OAuth [] On Behalf Of Justin Richer
Sent: Wednesday, July 30, 2014 6:21 AM
To: Mike Jones; Thomas Broyer
Cc: <>
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

Not true if I revoke the token after it's been issued but before it expires.

On 7/29/2014 8:49 PM, Mike Jones wrote:
Yes, but that’s the simplest thing to determine – try the token and see whether it works or not.

From: Thomas Broyer []
Sent: Tuesday, July 29, 2014 5:43 PM
To: Mike Jones
Cc: <><>; 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" <<>> 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 [<>] On Behalf Of George Fletcher
Sent: Tuesday, July 29, 2014 3:25 PM
To: Phil Hunt; Thomas Broyer
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.

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.


On Jul 28, 2014, at 17:00, Thomas Broyer <<>> wrote:
Yes. This spec is of special interest to the platform we're building for

On Mon, Jul 28, 2014 at 7:33 PM, Hannes Tschofenig <<>> 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:

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.

Hannes & Derek

OAuth mailing list<>

Thomas Broyer
OAuth mailing list<>


OAuth mailing list<>


OAuth mailing list<>