Re: [OAUTH-WG] OAuth Digest, Vol 51, Issue 34

["LuongKhanhVan" <[e-mail]>]

Sent from my BlackBerry® smartphone

-----Original Message-----
From: [e-mail]
Sender: [e-mail]
Date: Thu, 10 Jan 2013 08:59:40 
To: <[e-mail]>
Reply-To: [e-mail]
Subject: OAuth Digest, Vol 51, Issue 34

If you have received this digest without all the individual message
attachments you will need to update your digest options in your list
subscription.  To do so, go to 

https://www.ietf.org/mailman/listinfo/oauth

Click the 'Unsubscribe or edit options' button, log in, and set "Get
MIME or Plain Text Digests?" to MIME.  You can set this option
globally for all the list digests you receive at this point.



Send OAuth mailing list submissions to
	[e-mail]

To subscribe or unsubscribe via the World Wide Web, visit
	https://www.ietf.org/mailman/listinfo/oauth
or, via email, send a message with subject or body 'help' to
	[e-mail]

You can reach the person managing the list at
	[e-mail]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of OAuth digest..."


Today's Topics:

   1. Re: Fwd: New Version Notification for
      draft-richer-oauth-introspection-01.txt (George Fletcher)


----------------------------------------------------------------------

Message: 1
Date: Thu, 10 Jan 2013 11:59:35 -0500
From: George Fletcher <[e-mail]>
To: "[e-mail]" <[e-mail]>
Subject: Re: [OAUTH-WG] Fwd: New Version Notification for
	draft-richer-oauth-introspection-01.txt
Message-ID: <[e-mail]>
Content-Type: text/plain; charset="windows-1252"; Format="flowed"

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.ietf.org/mail-archive/web/oauth/attachments/20130110/f1dea5d0/attachment.htm>

------------------------------

_______________________________________________
OAuth mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/oauth


End of OAuth Digest, Vol 51, Issue 34
*************************************