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

Mike Jones <> Tue, 29 July 2014 17:15 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id B171D1B2925 for <>; Tue, 29 Jul 2014 10:15:35 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -2.601
X-Spam-Status: No, score=-2.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id b0zTBItz9-dK for <>; Tue, 29 Jul 2014 10:15:30 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id DDD851B2920 for <>; Tue, 29 Jul 2014 10:15:29 -0700 (PDT)
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.995.14; Tue, 29 Jul 2014 17:15:28 +0000
Received: from (2a01:111:f400:7c10::177) by (2a01:111:e400:401e::29) with Microsoft SMTP Server (TLS) id 15.0.995.14 via Frontend Transport; Tue, 29 Jul 2014 17:15:28 +0000
Received: from ( by ( with Microsoft SMTP Server (TLS) id 15.0.990.10 via Frontend Transport; Tue, 29 Jul 2014 17:15:28 +0000
Received: from ([]) by ([]) with mapi id 14.03.0195.002; Tue, 29 Jul 2014 17:15:21 +0000
From: Mike Jones <>
To: Paul Madsen <>, Phil Hunt <>
Thread-Topic: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item
Date: Tue, 29 Jul 2014 17:15:20 +0000
Message-ID: <>
References: <> <> <> <> <> <>
In-Reply-To: <>
Accept-Language: en-US
Content-Language: en-US
x-originating-ip: []
Content-Type: multipart/alternative; boundary="_000_4E1F6AAD24975D4BA5B16804296739439ADF615DTK5EX14MBXC293r_"
MIME-Version: 1.0
X-EOPAttributedMessage: 0
X-Forefront-Antispam-Report: CIP:; CTRY:US; IPV:CAL; IPV:NLI; IPV:NLI; EFV:NLI; SFV:NSPM; SFS:(438002)(53754006)(479174003)(377454003)(24454002)(199002)(189002)(55846006)(83322001)(79102001)(84326002)(107046002)(99396002)(80022001)(95666004)(106116001)(84676001)(81156004)(77096002)(106466001)(21056001)(76482001)(31966008)(66066001)(50986999)(77982001)(15975445006)(6806004)(19617315012)(104016003)(54356999)(16236675004)(87936001)(68736004)(15974865002)(76176999)(19580405001)(93886003)(46102001)(15202345003)(19580395003)(19300405004)(64706001)(86362001)(4396001)(20776003)(74662001)(19625215002)(74502001)(83072002)(44976005)(81542001)(26826002)(16601075003)(86612001)(69596002)(92566001)(85306003)(33656002)(97736001)(81342001)(71186001)(512874002)(2656002)(85852003)(92726001); DIR:OUT; SFP:; SCL:1; SRVR:BLUPR03MB246;; FPR:; MLV:ovrnspm; PTR:InfoDomainNonexistent; MX:1; LANG:en;
X-Microsoft-Antispam: BCL:0;PCL:0;RULEID:
X-O365ENT-EOP-Header: Message processed by - O365_ENT: Allow from ranges (Engineering ONLY)
X-Forefront-PRVS: 0287BBA78D
Received-SPF: Pass ( domain of designates as permitted sender); client-ip=;;
Authentication-Results: spf=pass (sender IP is;
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: Tue, 29 Jul 2014 17:15:35 -0000

As I see it, there are two different kinds of standardization for introspection that could occur.  One is defining a standard endpoint for doing introspection on an access token and possibly refresh token.  The other is defining standard contents to be returned from the introspection.

I’m skeptical of the standard contents, given that access tokens and refresh tokens are intentionally opaque.  Implementations could range from being an integer index into a database table, to being a UUID to being an encrypted JWT with context-specific claims.  I don’t see anything in common in those implementations for introspection to return.

While I can see marginal utility to having a common endpoint and request syntax, I would be against trying to standardize the contents of what an introspection request might return.  It’s as deployment-specific as the access token representation itself.

                                                            -- Mike

From: OAuth [] On Behalf Of Paul Madsen
Sent: Tuesday, July 29, 2014 2:48 AM
To: Phil Hunt
Subject: Re: [OAUTH-WG] Confirmation: Call for Adoption of "OAuth Token Introspection" as an OAuth Working Group Item

Standardized Introspection will be valuable in NAPPS, where the AS and RS may be in different policy domains.

Even for single policy domains, there are enterprise scenarios where the RS is from a different vendor than the AS, such as when an API gateway validates tokens issued by an 'IdP' . We've necessarily defined our own introspection endpoint and our gateway partners have implemented it, (at the instruction of the customer in question). But of course it's proprietary to us.


On Jul 28, 2014, at 8:59 PM, Phil Hunt <<>> wrote:
That doesn’t explain the need for inter-operability. What you’ve described is what will be common practice.

It’s a great open source technique, but that’s not a standard.

JWT is much different. JWT is a foundational specification that describes the construction and parsing of JSON based tokens. There is inter-op with token formats that build on top and there is inter-op between every communicating party.

In OAuth, a site may never implement token introspection nor may it do it the way you describe.  Why would that be a problem?  Why should the group spend time on something where there may be no inter-op need.

Now that said, if you are in the UMA community.  Inter-op is quite foundational.  It is very very important. But then maybe the spec should be defined within UMA?



On Jul 28, 2014, at 5:39 PM, Justin Richer <jricher@MIT.EDU<mailto:jricher@MIT.EDU>> wrote:

It's analogous to JWT in many ways: when you've got the AS and the RS separated somehow (different box, different domain, even different software vendor) and you need to communicate a set of information about the approval delegation from the AS (who has the context to know about it) through to the RS (who needs to know about it to make the authorization call). JWT gives us an interoperable way to do this by passing values inside the token itself, introspection gives a way to pass the values by reference via the token as an artifact. The two are complementary, and there are even cases where you'd want to deploy them together.

 -- Justin

On 7/28/2014 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<>

OAuth mailing list<>