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

Igor Faynberg <> Thu, 10 January 2013 17:08 UTC

Return-Path: <>
Received: from localhost (localhost []) by (Postfix) with ESMTP id AA5FA21F8A06 for <>; Thu, 10 Jan 2013 09:08:44 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: -8.998
X-Spam-Status: No, score=-8.998 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, HTML_MESSAGE=0.001, J_BACKHAIR_22=1, J_CHICKENPOX_54=0.6, RCVD_IN_DNSWL_HI=-8]
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id GT03krEw57uV for <>; Thu, 10 Jan 2013 09:08:42 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id A39BB21F8A0D for <>; Thu, 10 Jan 2013 09:08:42 -0800 (PST)
Received: from ( []) by (8.13.8/IER-o) with ESMTP id r0AH8fiv000796 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=FAIL) for <>; Thu, 10 Jan 2013 11:08:41 -0600 (CST)
Received: from ( []) by (8.14.3/8.14.3/GMO) with ESMTP id r0AH8elB001120 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for <>; Thu, 10 Jan 2013 11:08:41 -0600
Received: from [] ( []) by (8.13.8/TPES) with ESMTP id r0AH8d1s020586; Thu, 10 Jan 2013 11:08:40 -0600 (CST)
Message-ID: <>
Date: Thu, 10 Jan 2013 12:08:39 -0500
From: Igor Faynberg <>
Organization: Alcatel-Lucent
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20110616 Thunderbird/3.1.11
MIME-Version: 1.0
References: <> <> <> <> <> <B33BFB58CCC8BE4998958016839DE27E06873FA8@IMCMBX01.MITRE.ORG> <> <> <> <> <>
In-Reply-To: <>
Content-Type: multipart/alternative; boundary="------------080702050805070909010106"
X-Scanned-By: MIMEDefang 2.57 on
X-Scanned-By: MIMEDefang 2.64 on
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 17:08:44 -0000

  I  chime in in support of option 1.   Rationale: nothing is worse than 
the presence of an obscure parameter. (Not only it pollutes the 
environment, but it is a potential attack vector.) So rather than invent 
an acceptable value for it, I would remove it.


On 1/10/2013 11:59 AM, George Fletcher wrote:
> 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.
> Thanks,
> George
> 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
> _______________________________________________
> OAuth mailing list