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

Fri Jan 7 17:10:24 UTC 2011

On Fri, Jan 7, 2011 at 09:05, John Bradley <ve7jtb at ve7jtb.com> wrote:

> This is a access token for a openID info endpoint.   That endpoint could
> return the other access tokens for other services.
>

That makes the OpenID endpoint very different from an API endpoint, as it
also mints tokens.

It'd be more OAuth2-like to have OpenID be just like another API scope in an
OAuth2 request.

> I think it is just the access token for the openID Info endpoint that we
> are talking about being a JWT.  Though others could be as well.
>

The JWT token is a self-validating OpenID session token. There's no need for
it to be an access token to any API.

>
> John B.
> On 2011-01-07, at 1:46 PM, Nat Sakimura wrote:
>
> 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
>
>
>

-- 
--Breno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110107/83a9de0c/attachment.html>