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

[George Fletcher <[e-mail]>]

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 
>>> <[e-mail] <mailto:[e-mail]>> wrote:
>>>
>>>> Hi Justin,
>>>>
>>>> Am 09.01.2013 um 20:35 schrieb Justin Richer <[e-mail] 
>>>> <mailto:[e-mail]>>:
>>>>
>>>>> 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 <[e-mail] 
>>>>>> <mailto:[e-mail]>>:
>>>>>>
>>>>>>> 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: 	<[e-mail]>
>>>>>>> To: 	<[e-mail]>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> 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:http://www.ietf.org/internet-drafts/draft-richer-oauth-introspection-01.txt
>>>>>>> Status:http://datatracker.ietf.org/doc/draft-richer-oauth-introspection
>>>>>>> Htmlized:http://tools.ietf.org/html/draft-richer-oauth-introspection-01
>>>>>>> Diff:http://www.ietf.org/rfcdiff?url2=draft-richer-oauth-introspection-01
>>>>>>>
>>>>>>> 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
>>>>>>> [e-mail] <mailto:[e-mail]>
>>>>>>> https://www.ietf.org/mailman/listinfo/oauth
>>>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> OAuth mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/oauth
>>
>