On Wed, May 19, 2010 at 20:36, David Recordon <[email protected]> wrote: > So because one thing is potentially insecure we should knowingly make two > things insecure? I'm not following your logic here. :-\
I am saying that the first insecure thing unlocks the second. > > On Wed, May 19, 2010 at 8:34 PM, Breno de Medeiros <[email protected]> wrote: >> >> On Wed, May 19, 2010 at 20:28, David Recordon <[email protected]> wrote: >> > 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. >> >> Isn't it likely that compromising the logged-in state at the client >> exposes the data protected by the access token anyway, since the >> client has access to the token and therefore the data was probably >> imported and is available in the client? >> >> > --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 >> > >> > >> >> >> >> -- >> --Breno >> >> +1 (650) 214-1007 desk >> +1 (408) 212-0135 (Grand Central) >> MTV-41-3 : 383-A >> PST (GMT-8) / PDT(GMT-7) > > -- --Breno +1 (650) 214-1007 desk +1 (408) 212-0135 (Grand Central) MTV-41-3 : 383-A PST (GMT-8) / PDT(GMT-7) _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
