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

Justin Richer <> Thu, 10 January 2013 16:53 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id 2C8E021F885C for <>; Thu, 10 Jan 2013 08:53:53 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -5.439
X-Spam-Status: No, score=-5.439 tagged_above=-999 required=5 tests=[AWL=-0.441, BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_MED=-4]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id FJSSi25XTta4 for <>; Thu, 10 Jan 2013 08:53:51 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 6BBEB21F882B for <>; Thu, 10 Jan 2013 08:53:50 -0800 (PST)
Received: from (localhost.localdomain []) by localhost (Postfix) with SMTP id 392571F0BB7; Thu, 10 Jan 2013 11:53:49 -0500 (EST)
Received: from IMCCAS04.MITRE.ORG ( []) by (Postfix) with ESMTP id 2C42C1F0BA9; Thu, 10 Jan 2013 11:53:49 -0500 (EST)
Received: from [] ( by IMCCAS04.MITRE.ORG ( with Microsoft SMTP Server (TLS) id 14.2.318.4; Thu, 10 Jan 2013 11:53:48 -0500
Message-ID: <>
Date: Thu, 10 Jan 2013 11:53:45 -0500
From: Justin Richer <>
User-Agent: Mozilla/5.0 (X11; Linux i686; rv:17.0) Gecko/17.0 Thunderbird/17.0
MIME-Version: 1.0
To: George Fletcher <>
References: <> <> <> <> <> <B33BFB58CCC8BE4998958016839DE27E06873FA8@IMCMBX01.MITRE.ORG> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------020404010301050606040207"
X-Originating-IP: []
Cc: "" <>
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:53:54 -0000

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