Hi Breno, Can you describe the attack scenario with an example?
Thanks, Allen On 5/19/10 8:38 PM, "Breno de Medeiros" <[email protected]> wrote: > 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) >> >> > > _______________________________________________ specs mailing list [email protected] http://lists.openid.net/mailman/listinfo/openid-specs
