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

Justin Richer <jricher@MIT.EDU> Tue, 29 July 2014 01:24 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id EC8341A031F for <>; Mon, 28 Jul 2014 18:24:01 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -3.601
X-Spam-Status: No, score=-3.601 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, J_CHICKENPOX_22=0.6, RCVD_IN_DNSWL_MED=-2.3, RP_MATCHES_RCVD=-0.001, SPF_PASS=-0.001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id KD89jAS5nxHp for <>; Mon, 28 Jul 2014 18:23:59 -0700 (PDT)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 7806B1A02DF for <>; Mon, 28 Jul 2014 18:23:58 -0700 (PDT)
X-AuditID: 1209190c-f79ef6d000005dd6-87-53d6f7ac8e05
Received: from ( []) (using TLS with cipher AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id 61.D8.24022.DA7F6D35; Mon, 28 Jul 2014 21:23:57 -0400 (EDT)
Received: from ( []) by (8.13.8/8.9.2) with ESMTP id s6T1NteB021137; Mon, 28 Jul 2014 21:23:56 -0400
Received: from [] ( []) (authenticated bits=0) (User authenticated as jricher@ATHENA.MIT.EDU) by (8.13.8/8.12.4) with ESMTP id s6T1Nspc006721 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NOT); Mon, 28 Jul 2014 21:23:55 -0400
Message-ID: <>
Date: Mon, 28 Jul 2014 21:23:49 -0400
From: Justin Richer <jricher@MIT.EDU>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0
MIME-Version: 1.0
To: Phil Hunt <>
References: <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------040100070400000109050509"
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrMKsWRmVeSWpSXmKPExsUixG6nrrv2+7Vgg7f7WCxOvn3FZrFgfiO7 A5PHkiU/mTw+Pr3FEsAUxWWTkpqTWZZapG+XwJXxeHsvW8GNM4wVR29+Y2pg/NXI2MXIySEh YCJxb+sGdghbTOLCvfVsXYxcHEICs5kkTl//AJYQEtjIKNH3XhcicZtJYtaW5awgCV4BNYkF r2+DTWIRUJXofjyNGcRmA7Lnr7zFBGKLCkRJ3LnUD1UvKHFy5hMWEFtEQEXi29XrYL3MAkIS n49PBKrn4BAWKJc4f4ULYu8LRonvKxJBbE4BO4l/B64xQZSHSTz/8YdpAqPALCRTZyFJQdhm El1buxghbHmJ5q2zmSFsNYnb266yI4svYGRbxSibklulm5uYmVOcmqxbnJyYl5dapGuol5tZ opeaUrqJERTynJI8OxjfHFQ6xCjAwajEw7th7rVgIdbEsuLK3EOMkhxMSqK8B74ChfiS8lMq MxKLM+KLSnNSiw8xSnAwK4nwzl8ClONNSaysSi3Kh0lJc7AoifO+tbYKFhJITyxJzU5NLUgt gsnKcHAoSfDmfwNqFCxKTU+tSMvMKUFIM3FwggznARruAFLDW1yQmFucmQ6RP8VozDHn7rE2 Jo4FIFKIJS8/L1VKnFcfpFQApDSjNA9uGixtvWIUB3pOmHcOSBUPMOXBzXsFtIoJaBWL/2WQ VSWJCCmpBsbVly+pTv2U7jbJend8b0bx6/wDAX8FbH/G31TabXz8lfOV2/nrXxgurU5Svpb5 dn7sJLnTM8x9+abqiNZtzvR5teXNpdcPFdyfLH2W3K2TJpLx+toaN3ulZGUbrS2fTP9m/T5r XzLl1Lq9Zbr+ofdPVXF/Fnm2lW1jwJmVnElyz08X/K1tKNRWYinOSDTUYi4qTgQArf4siDYD AAA=
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 01:24:02 -0000

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 

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
>> <>