Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt

George Fletcher <> Thu, 10 January 2013 16:59 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id A518721F894E for <>; Thu, 10 Jan 2013 08:59:39 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -1.798
X-Spam-Status: No, score=-1.798 tagged_above=-999 required=5 tests=[AWL=-0.800, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_54=0.6]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id pqkMvSbvlqoz for <>; Thu, 10 Jan 2013 08:59:38 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id B13F621F8939 for <>; Thu, 10 Jan 2013 08:59:37 -0800 (PST)
Received: from ( []) by (Outbound Mail Relay) with ESMTP id 0ADCA1C0001BB; Thu, 10 Jan 2013 11:59:37 -0500 (EST)
Received: from ( []) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by (MUA/Third Party Client Interface) with ESMTPSA id 3133CE0000B3; Thu, 10 Jan 2013 11:59:36 -0500 (EST)
Message-ID: <>
Date: Thu, 10 Jan 2013 11:59:35 -0500
From: George Fletcher <>
Organization: AOL LLC
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/20130107 Thunderbird/17.0.2
MIME-Version: 1.0
To: "" <>
References: <> <> <> <> <> <B33BFB58CCC8BE4998958016839DE27E06873FA8@IMCMBX01.MITRE.ORG> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------090603030902060308070900"
x-aol-global-disposition: G
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20121107; t=1357837176; bh=19a8Ydky0P7GpCMkYNnK0d/tYfW9U6NIV75PQ/hEIMQ=; h=From:To:Subject:Message-ID:Date:MIME-Version:Content-Type; b=ybLrzAggtjb13WcQ9CdwmftI8wMirkI0qBJB8UeoWIu1UaCHu3CLn32X/R76tp+12 rP1Us54dUNfDAsGsFM1xUqrrJ7V9B4B/aJosC7PB+dNQeYoHB9s5lr5riv+8kgRyeH eYWZE5CG2tkBHA1M3U6uIR/xWzvQjYLs4sl/SuPA=
X-AOL-SCOLL-SCORE: 0:2:501499776:93952408
x-aol-sid: 3039ac1d290250eef3781d38
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for draft-richer-oauth-introspection-01.txt
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: OAUTH WG <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Thu, 10 Jan 2013 16:59:39 -0000

That makes sense as well:)

Hopefully some others will chime in as I think this is an area that 
could use some "best practice" guidelines.


On 1/10/13 11:53 AM, Justin Richer wrote:
> I'm leaning towards 1 because the client is more the "authorized 
> presenter" of the token, not its audience.
>  -- Justin
> On 01/10/2013 11:52 AM, George Fletcher wrote:
>> So in the default case I see two options for an AS that wants to 
>> implement this endpoint...
>> 1. Omit 'audience' from the response: The rationale here is that 
>> there really isn't an explicit audience and what clients need to 
>> protect against things like "confused deputy" is the client_id which 
>> is already one of the response fields.
>> 2. Make the 'audience' value the same as the 'client_id' value: The 
>> rationale here is that the "audience" of the token is the entity for 
>> which the token was minted which in the default OAuth2 case is the 
>> client_id.
>> Any thoughts as to which is the best option? For now I'm going with 
>> option 2.
>> Thanks,
>> George
>> On 1/10/13 9:18 AM, Justin Richer wrote:
>>> In traditional OAuth, there really isn't a baked-in notion of 
>>> 'audience' since the AS<->PR connection is completely out of scope. 
>>> However, in practice, when you've got more than one PR per AS, 
>>> you'll have some notion of 'audience'. It's definitely possible to 
>>> handle this with 'scope', especially if you want the client to have 
>>> a say in the matter. But since you could have your scopes and 
>>> audiences defined independently (one scope across several audiences, 
>>> one audience with many scopes, and any other combination thereof) I 
>>> think it makes sense to at least define a place for the AS to 
>>> express this back to the PR. JWT has the exact same claim for the 
>>> exact same reason.
>>> As George points out below, this also really comes into play in the 
>>> chaining case, where you've got one PR calling another PR and you 
>>> need to keep things straight in a large backend.
>>> So while I agree it'd be better if OAuth had an 'audience' concept 
>>> all the way through, I don't think it should be precluded from the 
>>> introspection response just because it doesn't.
>>>  -- Justin
>>> On 01/09/2013 04:47 PM, George Fletcher wrote:
>>>> I had the same confusion about "what is 'audience' in OAuth?" today 
>>>> working on a completely different project.
>>>> I think for the default OAuth2 deployment, scopes take the place of 
>>>> audience because the scopes identify the authorization grant(s) at 
>>>> the resource servers affiliated with the Authorization Server. The 
>>>> client can present the token to any resource server and if the 
>>>> necessary authorization grant(s) are present, the protected 
>>>> resource is returned. The client doesn't have to explicitly call 
>>>> out that it is going to present the token to the 'mail service', it 
>>>> just needs to ask for the 'readMail' scope.
>>>> So, in regards to an AS implementation of the introspection 
>>>> endpoint, what are the expectations for how the AS fills in the 
>>>> 'audience' field. Should the AS not return the field if there is no 
>>>> audience? Should the AS return "itself" as the audience? If a token 
>>>> has scopes of 'readMail writeMail readBuddyList sendIM' then what 
>>>> is the correct 'audience' of the token? Should it be an array of 
>>>> the resource servers that depend on those scopes?
>>>> I can see value in the chaining scenario of a client asking the AS 
>>>> for a token that it will give to another party to present and 
>>>> storing that intermediate party in the token. But for the default 
>>>> OAuth2 case, should audience be omitted? or be the same value as 
>>>> 'client_id'?
>>>> Thanks,
>>>> George
>>>> On 1/9/13 3:15 PM, Richer, Justin P. wrote:
>>>>> On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt 
>>>>> < <>> wrote:
>>>>>> Hi Justin,
>>>>>> Am 09.01.2013 um 20:35 schrieb Justin Richer < 
>>>>>> <>>:
>>>>>>> Thanks for the review, answers inline:
>>>>>>>> why is there a need for both scope and audience? I would assume 
>>>>>>>> the scope of the authorization request is typically turned into 
>>>>>>>> an audience of an access token.
>>>>>>> You can have an audience of a single server that has multiple 
>>>>>>> scopes, or a single scope that's across multiple servers. Scope 
>>>>>>> is an explicit construct in OAuth2, and while it is sometimes 
>>>>>>> used for audience restriction purposes, they really are 
>>>>>>> independent. Note that both of these are optional in the 
>>>>>>> response -- if the AS has no notion of audience restriction in 
>>>>>>> its stored token metadata, then it just doesn't return the 
>>>>>>> "audience" field.
>>>>>> You are making an interesting point here. To differentiate the 
>>>>>> resource server and the permissions of a particular at this 
>>>>>> server makes a lot of sense. BUT: the authorization request does 
>>>>>> not allow the client to specify both in separate parameters. 
>>>>>> Instead both must be folded into a single "scope" parameter. If I 
>>>>>> got your example correctly, the scope of the request would be
>>>>>> scope=myserver:read
>>>>>> whereas the results of the introspection would be
>>>>>> scope=read
>>>>>> audience=myserver
>>>>>> It's probably the different semantics of scope that confused me.
>>>>> No, sorry if I was unclear: scope is scope, no different 
>>>>> semantics. In this example case, you'd ask for scope=myserver:read 
>>>>> and get back scope=myserver:read. I'm not suggesting that these be 
>>>>> split up. Since the AS in this case knows that there's an 
>>>>> audience, so it can return audience=myserver as well. The fact 
>>>>> that it knows this through the scope mechanism is entirely 
>>>>> system-dependent.
>>>>> I agree that the lack of a method for specifying audience does 
>>>>> make returning this field a little odd for simple OAuth 
>>>>> deployments, but since audience restriction is a big part of 
>>>>> clustered and enterprise deployments (in my personal experience), 
>>>>> then it's something very useful to have the server return.
>>>>>>>> Generally, wouldn't it be simpler (spec-wise) to just return a 
>>>>>>>> JWT instead of inventing another set of JSON elements?
>>>>>>> What would be the utility in returning a JWT? The RS/client 
>>>>>>> making the call isn't going to take these results and present 
>>>>>>> them elsewhere, so I don't want to give the impression that it's 
>>>>>>> a token. (This, incidentally, is one of the main problems I have 
>>>>>>> with the Ping introspection approach, which uses the Token 
>>>>>>> Endpoint and invents a "token type" as its return value.) Also, 
>>>>>>> the resource server would have to parse the JWT instead of raw 
>>>>>>> JSON, the latter of which is easier and far more common. 
>>>>>>> Besides, I'd have to invent new claims for things like "valid" 
>>>>>>> and "scopes" and what not, so I'd be extending JWT anyway.
>>>>>>> So while I think it's far preferable to use an actual JSON 
>>>>>>> object, I'd be fine with re-using JWT claim names in the 
>>>>>>> response if people prefer that. I tried to just use the expanded 
>>>>>>> text since size constraints are not an issue outside of a JWT, 
>>>>>>> so "issued_at" instead of "iat".
>>>>>>> Finally, note that this is *not* the same as the old OIDC 
>>>>>>> CheckId endpoint which merely parsed and unwrapped the data 
>>>>>>> inside the token itself. This mechanism works just as well with 
>>>>>>> an unstructured token as input since the AS can store all of the 
>>>>>>> token's metadata, like expiration, separately and use the 
>>>>>>> token's value as a lookup key.
>>>>>> I probably didn't describe well what I meant. I would suggest to 
>>>>>> return a JWT claim set from the introspection endpoint. That way 
>>>>>> one could use the same claims (e.g. iat instead of issued_at) for 
>>>>>> structured and handle-based tokens. So the logic operating on the 
>>>>>> token data could be the same.
>>>>> OK, I follow you now. I'd be fine with re-using the JWT claim 
>>>>> names and extending the namespace with the OAuth-specific 
>>>>> parameters, like scope, that make sense here.
>>>>>  -- Justin
>>>>>> regards,
>>>>>> Torsten.
>>>>>>>  -- Justin
>>>>>>>> Am 09.01.2013 um 20:10 schrieb Justin Richer < 
>>>>>>>> <>>:
>>>>>>>>> Updated the introspection draft with feedback from the UMA WG, 
>>>>>>>>> who have incorporated it into their latest revision of UMA.
>>>>>>>>> I would like this document to become a working group item.
>>>>>>>>>  -- Justin
>>>>>>>>> -------- Original Message --------
>>>>>>>>> Subject: 	New Version Notification for 
>>>>>>>>> draft-richer-oauth-introspection-01.txt
>>>>>>>>> Date: 	Tue, 8 Jan 2013 14:48:47 -0800
>>>>>>>>> From: 	<>
>>>>>>>>> To: 	<>
>>>>>>>>> A new version of I-D, draft-richer-oauth-introspection-01.txt
>>>>>>>>> has been successfully submitted by Justin Richer and posted to the
>>>>>>>>> IETF repository.
>>>>>>>>> Filename:	 draft-richer-oauth-introspection
>>>>>>>>> Revision:	 01
>>>>>>>>> Title:		 OAuth Token Introspection
>>>>>>>>> Creation date:	 2013-01-08
>>>>>>>>> WG ID:		 Individual Submission
>>>>>>>>> Number of pages: 6
>>>>>>>>> URL:
>>>>>>>>> Status:
>>>>>>>>> Htmlized:
>>>>>>>>> Diff:
>>>>>>>>> Abstract:
>>>>>>>>>     This specification defines a method for a client or protected
>>>>>>>>>     resource to query an OAuth authorization server to determine meta-
>>>>>>>>>     information about an OAuth token.
>>>>>>>>> The IETF Secretariat
>>>>>>>>> _______________________________________________
>>>>>>>>> OAuth mailing list
>>>>>>>>> <>
>>>>> _______________________________________________
>>>>> OAuth mailing list