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

Mark Dobrinic <> Tue, 29 July 2014 09:46 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 31D5B1A02F9 for <>; Tue, 29 Jul 2014 02:46:51 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.795
X-Spam-Status: No, score=0.795 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HELO_EQ_NL=0.55, HOST_EQ_NL=1.545, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id QYOrewuIqKvZ for <>; Tue, 29 Jul 2014 02:46:45 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 02AF21A0311 for <>; Tue, 29 Jul 2014 02:46:44 -0700 (PDT)
Received: from speedym.lan ( []) (authenticated bits=0) by (8.13.8/8.13.8) with ESMTP id s6T9kcUN031561 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Tue, 29 Jul 2014 11:46:40 +0200 (CEST) (envelope-from
Message-ID: <>
Date: Tue, 29 Jul 2014 11:46:38 +0200
From: Mark Dobrinic <>
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Justin Richer <jricher@MIT.EDU>, Phil Hunt <>
References: <> <> <> <> <> <>
In-Reply-To: <>
X-Enigmail-Version: 1.6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 8bit
X-Virus-Scanned: by XS4ALL Virus Scanner
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 09:46:51 -0000

Just some way I could look at this discussion:

One way to separate an AS and an RS is specified by UMA, so for UMA it
is required to have a standardized Token Introspection feature.

If there are no other uses for separating AS/RS, then UMA would be the
place for standardizing Token Introspection.

On the other hand, if there might be other uses for a standardized Token
Introspection, then it would make the most sense that it would be made a
feature of the set of OAuth specifications.

Personally, I've been surprised to find that the main OAuth spec does
not specify a standard way to return a token's info.



On 29/07/14 03:23, Justin Richer wrote:
> I think this perspective has a lot to do with your idea of OAuth's
> deployment model. You're right in that many people bundle the RS and the
> AS very tightly, but that's not always case, nor is it desirable. We're
> increasingly seeing cases where a group (often an enterprise) has their
> own AS on premises and wants to stand up an RS from a vendor. Without a
> means to connect the RS to the AS in a standard way, you're stuck with
> using whatever AS the RS vendor wants to sell you along side their RS.
> But with the right mechanisms (like JWT and token introspection), you're
> able to connect the RS from one vendor to the AS from another vendor,
> and it works together. I'm not sure what's unclear, but this is the very
> definition of interoperability.
> This is to say nothing of simply being able to locate the RS remotely
> from the AS within a particular security domain and still use
> artifact-style tokens (ie, tokens that don't encode everything within
> them).
> I have already had to deal directly with several cases of RS'es and
> AS'es from different vendors doing effectively the token introspection
> thing in different ways, in protecting vanilla OAuth within a single
> security domain. They were doing it slightly differently for no
> compelling reason other than having to invent the "I have a token and
> need to look it up" mechanism independently. When both sides were able
> to speak the same token introspection protocol (based on the individual
> draft I'd submitted), then we could actually make things work. And none
> of this was running UMA, which also makes use of this.
> I really don't see JWT as any different. To borrow your statement: In
> OAuth, a site may never implement JWT nor may it do it in the way that
> JWT describes. Why would that be a problem? (Hint: it isn't, they're
> free to do whatever token they want. Same with introspection, it's a
> tool that you can use if it makes sense for you to use it. So far a
> whole bunch of people have said it makes sense.)
>  -- Justin
> On 7/28/2014 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?
>> Phil
>> @independentid
>> <>
>> <>
>> 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. 
>>>> Phil
>>>> 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.
>>>>>     Ciao
>>>>>     Hannes & Derek
>>>>>     _______________________________________________
>>>>>     OAuth mailing list
>>>>> <>
>>>>> -- 
>>>>> Thomas Broyer
>>>>> /tɔ.ma.bʁ <>
>>>>> _______________________________________________
>>>>> OAuth mailing list
>>>>> <>
>>>> _______________________________________________
>>>> OAuth mailing list
>>> _______________________________________________
>>> OAuth mailing list
>>> <>
> _______________________________________________
> OAuth mailing list