And given that the server would return one token good for both the `openid`
and `calendar` scopes, leaking it via HTTP cookies would be bad. Thus in my
proposal the access token remains secret and is useful for a variety of
scopes while the signature – sure another form of a "token" – can become
public and not compromise security.

--David


On Wed, May 19, 2010 at 8:18 PM, Allen Tom <[email protected]> wrote:

>  Whoa, I think it’s premature to say that Yahoo supports OpenID Connect,
> but I would imagine that only a single Access Token would be returned to
> coolcalendar.com – the Access Token would presumably be good for both
> “openid” and “calendar” scope. Why would the OP want to return 2 tokens?
>
> Allen
>
>
> On 5/19/10 5:27 PM, "Dirk Balfanz" <[email protected]> wrote:
>
>
> Let's say I'm coolcalendar.com <http://coolcalendar.com> , and I want to
> "connect" one of my user's accounts to his Yahoo! account. I don't want to
> roll my own auth system, so I'm happy to see that Yahoo! supports OpenID
> Connect. To connect, I'll send the user over to Yahoo! with
> scope=openid%20yahoo-calendar. What I get back, in your proposal, is two
> different kinds of "tokens": the access token that my servers use to access
> Yahoo! and something I'll call "openid connect token" (which in your
> proposal comprises a few different parameters - user id, timestamp,
> signature, etc.) that browsers use (in form of a cookie) to access my own
> servers at coolcalendar.com <http://coolcalendar.com> .
>
>
> Why do those two tokens look different? They serve the same purpose -
> authenticating access from a client to a server, so they should look the
> same.
>
> Why should Yahoo! run different code to authenticate requests coming from
> my server than the code I'm running on my servers to authenticate requests
> coming from browsers - we have to solve the same task, so we should run the
> same code. It's simpler.
>
>
_______________________________________________
specs mailing list
[email protected]
http://lists.openid.net/mailman/listinfo/openid-specs

Reply via email to