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

[Sergey Beryozkin <[e-mail]>]

Hi
On 09/01/13 21:47, 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.
>
That was my understanding too

Cheers, Sergey

> 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
>
>
>
> _______________________________________________
> OAuth mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/oauth