[Openid-specs-ab] Lite Draft 9

John Bradley ve7jtb at ve7jtb.com
Thu Aug 25 00:15:20 UTC 2011


Brenno was the one that wanted to make the check session endpoint a standard OAuth protected resource, protecting and passing the token in abby way supported by OAuth.

I am not opposed to treating it as a non OAuth endpoint and passing things in as form encoded.  
We need to decide if passing them as URL parameters is safe.  (probably not a good idea)

Now that we need to pass both access and id_token the argument for protecting the id_token as if it were an access token is a bit weaker.

I still don't understand why passing the id_token as the access token is harder for the OP.

It should be easier for the client if it supports receiving multiple tokens for different endpoints as some of them do.

John 
On 2011-08-24, at 4:45 PM, Nat Sakimura wrote:

> That further increases the length of the id_token.
> 
> What Nov is making a point on is that, from a developer point of view,
> since usual access_token and id_token are very different in its
> characteristics, the argument that treating id_token as an
> access_token to the check session endpoint makes the life for the
> developer simpler because one can reuse OAuth library is simply not
> true.
> 
> In fact, it would pose a significant challenge in some cases, so it is
> better to make id_token as a parameter separate from an access_token
> for the check session endpoint.
> 
> Nov has been providing Rack-OAuth2 library for sometime, which is
> being used in many places, so he may have some point as a developer
> feedback.
> 
> =nat
> 
> 
> On Thu, Aug 25, 2011 at 2:56 AM, John Bradley <ve7jtb at ve7jtb.com> wrote:
>> Yes that is what the OP check session endpoint is supposed to do.
>> 
>> Google has however added a bit of a twist on the last call.
>> 
>> They are proposing that a hash of the access token be included in the id_token.
>> The idea is that that allows a RP to know if the received access token relates to the id_token.
>> 
>> That change would require the check session endpoint to take the user-info access token as a parameter, so that it can check the hash for the client.
>> 
>> This is still being discussed, but could cause a change in the current Check Session endpoint.
>> 
>> I am inclined to leave the check session endpoint as is, and make the client calculate the hash if they want to.
>> This correlation check between the two tokens is not required for the code flow, only the token flow to prevent cut and paste.
>> 
>> John
>> On 2011-08-23, at 7:03 PM, nov matake wrote:
>> 
>>> Aren't you talking about RPs?
>>> 
>>> If so, sorry for the confusing.
>>> I'm on OP side now.
>>> 
>>> This is the actual OP check session endpoint code in Ruby.
>>> I just verify signature and return extracted JSON here.
>>> https://github.com/nov/openid_connect_sample/blob/master/lib/check_session_endpoint.rb
>>> 
>>> On 2011/08/24, at 2:10, Breno de Medeiros wrote:
>>> 
>>>> On Mon, Aug 22, 2011 at 19:00, nov matake <nov at matake.jp> wrote:
>>>>> Since there is significant difference in its length between OAuth 2.0 access token and id_token,
>>>>> I personally doesn't want to store them in the same table in DB.
>>>>> 
>>>>> And I do access token validation in middleware layer in my Rails app, it's not so simple to lookup different token tables based on the requested endpoint.
>>>>> 
>>>>> So handling id_token as access token doesn't seem simpler solution for me.
>>>> 
>>>> The intended usage is to handle id_token as a cookie. You may rely on
>>>> static validation to treat as a stateless credential or if you have
>>>> session storage, you can store a shorter hash of the id_token to
>>>> prevent re-validation everytime.
>>>> 
>>>>> 
>>>>> Plus, in the current format of access token response, there are no information about the token type of id_token.
>>>>> When the type of access token is Bearer, the type of id_token is always Bearer too?
>>>>> What happens when the access token is MAC token or others?
>>>>> 
>>>>> If we use id_token as access token, I prefer defining new access token type. (eg. use IdToken as Authorization Scheme)
>>>>> 
>>>>> --
>>>>> nov matake
>>>>> 
>>>>> On 2011/08/23, at 5:21, John Bradley wrote:
>>>>> 
>>>>>> Treating the id_token as the access token for the Check session endpoint, makes it clear what you need to do with it.
>>>>>> We can invent a new unauthenticated API, but I think that is more complicated.
>>>>>> 
>>>>>> I have had other providers talk about delivering multiple access tokens from a single request.
>>>>>> I suspect that it will not be uncommon with OAuth 2.
>>>>>> 
>>>>>> There are lots of reasons why a IdP might want to use different access tokens fro different services. especialy if they are stateless.
>>>>>> 
>>>>>> John
>>>>>> On 2011-08-22, at 4:04 PM, Breno de Medeiros wrote:
>>>>>> 
>>>>>>> On Mon, Aug 22, 2011 at 13:00, Allen Tom <allentomdude at gmail.com> wrote:
>>>>>>>> Hi Breno -
>>>>>>>> I don't have much first hand experience with FB's signed_request, but my
>>>>>>>> understanding is allows FB to return a signed response to an app, so that
>>>>>>>> the app knows that it came from FB.
>>>>>>> 
>>>>>>> Actually, signed_request is intended to be the identity assertion so
>>>>>>> that apps can login users to their sites. The alternative is to make a
>>>>>>> call to their version of the user info endpoint. In other words, the
>>>>>>> FB Connect design is nearly identical to this.
>>>>>>> 
>>>>>>>> https://developers.facebook.com/docs/authentication/signed_request/
>>>>>>>> The docs don't say that there are two Access Tokens, instead the Access
>>>>>>>> Token is a signed parameter contained within the signed_request.
>>>>>>>> My concern regarding the id_token and the CheckSession API is that it could
>>>>>>>> be confusing to tell developers that the id_token is an Access Token, but
>>>>>>>> only for the CheckSession API. All other endpoints use the regular Access
>>>>>>>> Token.
>>>>>>> 
>>>>>>> The id_token can be statically validated, the CheckSession is a
>>>>>>> convenience mechanism for those who don't want to implement static
>>>>>>> validation.
>>>>>>> 
>>>>>>> I think the CheckSession endpoint is morally an
>>>>>>> non-authentication-required endpoint that cracks open the id_token.
>>>>>>> Passing the id_token instead of the access_token may make it easier to
>>>>>>> re-use code.
>>>>>>> 
>>>>>>>> Allen
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Mon, Aug 22, 2011 at 12:31 PM, Breno de Medeiros <breno at google.com>
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> On Mon, Aug 22, 2011 at 12:05, Allen Tom <allentomdude at gmail.com> wrote:
>>>>>>>>>> I think it might be confusing to developers to have multiple access
>>>>>>>>>> tokens.
>>>>>>>>>> I don't think I've seen any other Connect/OAuth
>>>>>>>>>> type implementations that
>>>>>>>>>> return multiple access tokens. Are there any examples out there?
>>>>>>>>> 
>>>>>>>>> Yes. Facebook Connect uses signed_request as the id_token.
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> --Breno
>>>>>> 
>>>>>> _______________________________________________
>>>>>> Openid-specs-ab mailing list
>>>>>> Openid-specs-ab at lists.openid.net
>>>>>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> --Breno
>>> 
>> 
>> 
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>> 
>> 
> 
> 
> 
> -- 
> Nat Sakimura (=nat)
> Chairman, OpenID Foundation
> http://nat.sakimura.org/
> @_nat_en

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 4767 bytes
Desc: not available
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110824/b3ac72a5/attachment.p7s>


More information about the Openid-specs-ab mailing list