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

[Nat Sakimura]

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:
>
>    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 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> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openid.net/pipermail/openid-specs-ab/attachments/20110107/6f07dd4c/attachment.html>