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

[John Bradley]

This is a access token for a openID info endpoint.   That endpoint could return the other access tokens for other services.
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.

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> wrote:
>>> I see two cases which may not work here:
>>> 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 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. 
>> 
>> 
>>> 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> 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://twitter.com/_nat_en
>>> _______________________________________________
>>> Openid-specs-ab mailing list
>>> 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/20110107/15c8df4d/attachment.html>
-------------- 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/20110107/15c8df4d/attachment.p7s>