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

From: Justin Richer <[email-masked]>
Date: Wed, 9 Jan 2013 14:10:38 -0500

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: 	<[email-masked]>
To: 	<[email-masked]>

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

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 9 Jan 2013 20:22:57 +0100

Hi Justin,

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.

Generally, wouldn't it be simpler (spec-wise) to just return a JWT instead of inventing another set of JSON elements?

regards,
Torsten.

Am 09.01.2013 um 20:10 schrieb Justin Richer <[email-masked]>:

> Updated the introspection draft with feedback from the UMA WG, who have incorporated it into their latest revision of UMA. 
> 
> Subject:	New Version Notification for draft-richer-oauth-introspection-01.txt
> _______________________________________________
> OAuth mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/oauth

---

From: Justin Richer <[email-masked]>
Date: Wed, 9 Jan 2013 14:35:02 -0500

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.

>
> 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.

  -- Justin

> Am 09.01.2013 um 20:10 schrieb Justin Richer <[email-masked] 
> <mailto:[email-masked]>>:
>
>> Updated the introspection draft with feedback from the UMA WG, who 
>> have incorporated it into their latest revision of UMA.
>>
>> 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:
>> [email-masked] <mailto:[email-masked]>

---

From: Torsten Lodderstedt <[email-masked]>
Date: Wed, 9 Jan 2013 21:05:59 +0100

Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <[email-masked]>:

> 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.

> 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.

regards,
Torsten.

---

From: "Richer, Justin P." <[email-masked]>
Date: Wed, 9 Jan 2013 20:15:08 +0000

On Jan 9, 2013, at 3:05 PM, Torsten Lodderstedt <[email-masked]<mailto:[email-masked]>> wrote:

Hi Justin,

Am 09.01.2013 um 20:35 schrieb Justin Richer <[email-masked]<mailto:[email-masked]>>:

scope=myserver:read

scope=read
audience=myserver

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.

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 <[email-masked]<mailto:[email-masked]>>:

 -- Justin

-------- Original Message --------
Subject:        New Version Notification for draft-richer-oauth-introspection-01.txt
Date:   Tue, 8 Jan 2013 14:48:47 -0800
From:   <[email-masked]><mailto:[email-masked]>
To:     <[email-masked]><mailto:[email-masked]>

Abstract:

The IETF Secretariat

_______________________________________________
OAuth mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/oauth

---

From: George Fletcher <[email-masked]>
Date: Wed, 09 Jan 2013 16:47:31 -0500

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 
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>> Hi Justin,
>>
>>> 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
>>
> 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.
>
>>
>>>
>>>>
>>> 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".
>>>
>>> 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 
>> 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
>>>

---

From: Sergey Beryozkin <[email-masked]>
Date: Thu, 10 Jan 2013 11:05:24 +0000

Hi
> present the token to the 'mail service', it just needs to ask for the
That was my understanding too

Cheers, Sergey

---

From: Justin Richer <[email-masked]>
Date: Thu, 10 Jan 2013 09:18:28 -0500

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:
> 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.
>
> 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
>
>>>>> why is there a need for both scope and audience? I would assume 
>>>>> the scope of the authorization request is typically turned into an 
>>>> notion of audience restriction in its stored token metadata, then 
>>>> it just doesn't return the "audience" field.
>>>
>> 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 
>>>> 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 
>>>> new claims for things like "valid" and "scopes" and what not, so 
>>>> I'd be extending JWT anyway.
>>>>
>>>> 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.
>>>
>>>>>> Updated the introspection draft with feedback from the UMA WG, 
>>>>>> who have incorporated it into their latest revision of UMA.
>>>>>>

---

From: George Fletcher <[email-masked]>
Date: Thu, 10 Jan 2013 11:52:52 -0500

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.
>
>> 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.
>>
>> '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
>>
>>>>>> the scope of the authorization request is typically turned into 
>>>>>> an audience of an access token.
>>>>>
>>>>> 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.
>>>>
>>>> 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
>>>>
>>> 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.
>>>
>>>>>> Generally, wouldn't it be simpler (spec-wise) to just return a 
>>>>>> JWT instead of inventing another set of JSON elements?
>>>>>
>>>>> 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.
>>>>>
>>>>> 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".
>>>>>
>>>> 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

---

From: Justin Richer <[email-masked]>
Date: Thu, 10 Jan 2013 11:53:45 -0500

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:
> against things like "confused deputy" is the client_id which is 
> already one of the response fields.
>
>> 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.
>>
>> 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 
>>> 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?
>>>
>>> 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
>>>
>>>>>> 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.
>>>>>
>>>>> 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 
>>>> 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 
>>>> 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.
>>>>
>>>>>
>>>>>>
>>>>>>>
>>>>>> 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 
>>>>>> 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".
>>>>>>
>>>> and extending the namespace with the OAuth-specific parameters, 
>>>> like scope, that make sense here.
>>>>
>>>>  -- Justin
>>>>
>>>>> regards,
>>>>> Torsten.
>>>>>
>>>>>>
>>>>>>  -- Justin
>>>>>>

---

From: George Fletcher <[email-masked]>
Date: Thu, 10 Jan 2013 11:59:35 -0500

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:
>> 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.
>>
>>> 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.
>>>
>>>> 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.
>>>>
>>>> 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?
>>>>
>>>>>>> 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.
>>>>>>
>>>>>> 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
>>>>>>
>>>>> 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.
>>>>>
>>>>>>
>>>>>>>
>>>>>>>>
>>>>>>> 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.
>>>>>>>
>>>>>>> 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.
>>>>>>
>>>>> 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
>>>>>>>

---

From: Igor Faynberg <[email-masked]>
Date: Thu, 10 Jan 2013 12:08:39 -0500

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.

Igor

On 1/10/2013 11:59 AM, George Fletcher wrote:
>>>> 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.
>>>>
>>>>> 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 
>>>>> out that it is going to present the token to the 'mail service', 
>>>>> it just needs to ask for the 'readMail' scope.
>>>>>
>>>>> '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?
>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>> 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
>>>>>>>
>>>>>> 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.
>>>>>>
>>>>>>>> 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. 
>>>>>>>> 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".
>>>>>>>>
>>>>>>>> an unstructured token as input since the AS can store all of 
>>>>>>>> the token's metadata, like expiration, separately and use the 
>>>>>>> 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.
>>>>>>>
>>>>>>
>>>>>>>>> Am 09.01.2013 um 20:10 schrieb Justin Richer 
>>>>>>>>> <[email-masked] <mailto:[email-masked]>>:
>>>>>>>>>
>>>>>>>>>> Updated the introspection draft with feedback from the UMA 
>>>>>>>>>> WG, who have incorporated it into their latest revision of UMA.
>>>>>>>>>>

---

From: Justin Richer <[email-masked]>
Date: Thu, 10 Jan 2013 12:13:59 -0500

Igor,

The question is not whether to remove the parameter from the spec, but 
rather what one would expect as a "default" behavior from a "normal" 
OAuth2 provider. Option1 says that the default is to leave it out of the 
response. But it'll still be there in cases where the AS and PR know 
what the value means.

  -- Justin

On 01/10/2013 12:08 PM, Igor Faynberg wrote:
>  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.
>
> Igor
>
>>>> protect against things like "confused deputy" is the client_id 
>>>> which is already one of the response fields.
>>>>
>>>> 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.
>>>>
>>>>> '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 
>>>>> 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.
>>>>>
>>>>>> 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.
>>>>>>
>>>>>> 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 
>>>>>>>>> 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 
>>>>>>>> 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
>>>>>>>>
>>>>>>> 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?
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>>
>>>>>>>>> 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.
>>>>>>>>
>>>>>>>

---

From: George Fletcher <[email-masked]>
Date: Fri, 11 Jan 2013 12:38:00 -0500

Additional feedback on the introspection endpoint.

What is the expected error response if the introspection endpoint is 
using client credentials as recommended in section 2.1

The endpoint SHOULD also require some form of authentication to
    access this endpoint, such as the Client Authentication as described
    in OAuth 2 Core Specification [RFC6749  <http://tools.ietf.org/html/rfc6749>] or a separate OAuth2 Access
    Token.

and the client credentials are invalid. It doesn't seem correct to 
return an HTTP 200 with a body of { "valid: false } as the endpoint 
probably never even tried to validate the token parameter.

I can see a couple of options...

1. Follow the RFC 6749 /token endpoint and return an HTTP 40X response 
with the error described in JSON in the body of the response.

2. Follow RFC 6750 and return a WWW-Authenticate Response header that 
contains the error and optionally error_description.

Thanks,
George

---

From: "Richer, Justin P." <[email-masked]>
Date: Fri, 11 Jan 2013 18:04:21 +0000

It should follow the 6749 Token Endpoint error responses for bad client credentials. That's what this text at the end of 2.3 is supposed to mean:

   If the client credentials are invalid or there is another error, the
   Authorization Server responds with the appropriate error response
   from the OAuth2 Core.

Looking at it now, it's completely non-normative and stuffed into the examples section, which is probably not the best way to describe it.

There was some confusion about the {valid: false} response as well, so now I'm thinking that should be pulled into an "Errors" section, perhaps?

 -- Justin

On Jan 11, 2013, at 12:38 PM, George Fletcher <[email-masked]<mailto:[email-masked]>>
 wrote:

What is the expected error response if the introspection endpoint is using client credentials as recommended in section 2.1

The endpoint SHOULD also require some form of authentication to
   access this endpoint, such as the Client Authentication as described
   in OAuth 2 Core Specification [RFC6749<http://tools.ietf.org/html/rfc6749>] or a separate OAuth2 Access
   Token.

and the client credentials are invalid. It doesn't seem correct to return an HTTP 200 with a body of { "valid: false } as the endpoint probably never even tried to validate the token parameter.

1. Follow the RFC 6749 /token endpoint and return an HTTP 40X response with the error described in JSON in the body of the response.

2. Follow RFC 6750 and return a WWW-Authenticate Response header that contains the error and optionally error_description.

Thanks,
George

---

From: George Fletcher <[email-masked]>
Date: Fri, 11 Jan 2013 14:57:53 -0500

I definitely like the idea of an Errors section that normatively defines 
error responses.

Thanks,
George

On 1/11/13 1:04 PM, Richer, Justin P. wrote:
> It should follow the 6749 Token Endpoint error responses for bad 
> client credentials. That's what this text at the end of 2.3 is 
> supposed to mean:
>
> Looking at it now, it's completely non-normative and stuffed into the 
> examples section, which is probably not the best way to describe it.
>
> There was some confusion about the {valid: false} response as well, so 
> now I'm thinking that should be pulled into an "Errors" section, perhaps?
>
>  -- Justin
>
>> 1. Follow the RFC 6749 /token endpoint and return an HTTP 40X 
>> response with the error described in JSON in the body of the response.
>>