[Openid-specs-ab] Connect Flows and Userinfo Endpoint

[Nat Sakimura]

Hideki's suggestion was to return a JWT token that has user_id etc. within
as access_token. It should work as long as the resource
endpoint understands the access_token.

A issue however comes up if we have a OAuth 2.0 Resource Endpoint that we do
not want to change. Then, the Authorization Server is constrained to issue
the access_token the way it has been doing and cannot convert the
access_token to the JWT token.

I am interested to find out if there are so many Resource Endpoints that
falls under this category. If it is negligible, then we can drop this
requirement.

=nat

On Sat, Jan 8, 2011 at 1:13 AM, Breno de Medeiros <breno at google.com> wrote:

>
>
> On Fri, Jan 7, 2011 at 08:06, Nat <sakimura at gmail.com> wrote:
>
>> That is the whole point I and Hideki was making.
>>
>> I assumed that what David is pointing out is that the protected resource
>> being a PoCo endpoint directly or existing OAuth endpoint.
>>
>
> Nat, could you be more explicit. I am not sure what point you and Hideki
> were making.
>
> As for the protected resource being an existing OAuth endpoint, I think
> that is an orthogonal issue to a large extent.
>
>
>>
>> =nat via iPhone
>>
>> On 2011/01/08, at 0:24, John Bradley <ve7jtb at ve7jtb.com> wrote:
>>
>> One of the motivating factors of the JWT is that it can be a oAuth access
>> token.
>>
>> It seems simpler to include claims like userID in the signed access token,
>>  rather than having to include a separate access token inside.
>> The access token is for the user info endpoint in ether case.
>>
>> Accessing public info at the user-info endpoint without a token should not
>> be impacted by the access token format.  Am I missing something?
>>
>> If you get the access token through some other flow there is no particular
>> issue with it being a JWT or some other format as long as the protected
>> resource understands it.
>>
>> Or are you talking about the protected resource being a PoCo endpoint
>> directly?
>>
>> John B.
>>
>>
>> On 2011-01-07, at 6:39 AM, Nat Sakimura wrote:
>>
>> Hmmm. That is interesting. So, it means that I should not optimize for the
>> OpenID/OAuth use cases. The two cases below are different use cases than the
>> OpenID/OAuth protected resource access. Is there any other use cases that
>> people have in mind?
>>
>> On Fri, Jan 7, 2011 at 4:43 PM, David Recordon < <dr at fb.com>dr at fb.com>wrote:
>>
>>>  I see two cases which may not work here:
>>>
>>>    1. you're requesting public data in which case just a userid is
>>>    required and no access token or JWT
>>>
>>> For accessing public data, one can always ask without a token.
>> (I actually like the <http://graph.facebook.com/username>
>> graph.facebook.com/username style access.)
>> Using JWT received as a token to access restricted content does not
>>  prevent this behavior.
>> Am I missing something? (In the older version of the connect proposal, it
>> was returning such URL instead of opaque user_id. That was good.) So this
>> does not seem to be a blocking factor.
>>
>>
>>
>>
>>>    1. you got the access token via a non-OpenID OAuth 2.0 flow. I can
>>>    imagine a PoCo endpoint doubling as the OpenID user info API.
>>>
>>> This probably is more relevant.
>>
>> Then the question would gets to the point Hideki pointed out:
>> why cannot we make "signed" as we call now the "access_token" with
>> token_type=signed_openid?
>> It will save us from defining an OAuth extension variable called "signed"
>> and more OAuth2.0 compliant.
>>
>> (As a side issue: I started to feel that we probably do not need "code" in
>> the OAuth2.0 spec., but just "access_token" with type="authz_code". "code"
>> is just another type of access_token which can only be used once and at the
>> authz endpoint.)
>>
>>
>>
>>>
>>>   On 1/6/11 11:40 PM, "Nat Sakimura" < <sakimura at gmail.com>
>>> sakimura at gmail.com> wrote:
>>>
>>>  Hi guys.
>>>
>>>  Do you have objection to passing the entire JWT ("signed") instead of
>>> access_token and user_id extracted to the UserInfo endpoint?
>>> That seems to be a lot simpler.
>>>
>>>  =nat
>>>
>>>
>>
>>
>> --
>> Nat Sakimura (=nat)
>> <http://www.sakimura.org/en/>http://www.sakimura.org/en/
>>  <http://twitter.com/_nat_en>http://twitter.com/_nat_en
>> _______________________________________________
>> Openid-specs-ab mailing list
>> <Openid-specs-ab at lists.openid.net>Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>>
>> _______________________________________________
>> Openid-specs-ab mailing list
>> Openid-specs-ab at lists.openid.net
>> http://lists.openid.net/mailman/listinfo/openid-specs-ab
>>
>>
>
>
> --
> --Breno
>



-- 
Nat Sakimura (=nat)
http://www.sakimura.org/en/
http://twitter.com/_nat_en
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110108/d63ed9fa/attachment.html>