So because one thing is potentially insecure we should knowingly make two things insecure? I'm not following your logic here. :-\<div><br></div><div><br><div class="gmail_quote">On Wed, May 19, 2010 at 8:34 PM, Breno de Medeiros <span dir="ltr"><<a href="mailto:breno@google.com">breno@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">On Wed, May 19, 2010 at 20:28, David Recordon <<a href="mailto:recordond@gmail.com">recordond@gmail.com</a>> wrote:<br>
> And given that the server would return one token good for both the `openid`<br>
> and `calendar` scopes, leaking it via HTTP cookies would be bad. Thus in my<br>
> proposal the access token remains secret and is useful for a variety of<br>
> scopes while the signature – sure another form of a "token" – can become<br>
> public and not compromise security.<br>
<br>
</div>Isn't it likely that compromising the logged-in state at the client<br>
exposes the data protected by the access token anyway, since the<br>
client has access to the token and therefore the data was probably<br>
imported and is available in the client?<br>
<div><div></div><div class="h5"><br>
> --David<br>
><br>
> On Wed, May 19, 2010 at 8:18 PM, Allen Tom <<a href="mailto:atom@yahoo-inc.com">atom@yahoo-inc.com</a>> wrote:<br>
>><br>
>> Whoa, I think it’s premature to say that Yahoo supports OpenID Connect,<br>
>> but I would imagine that only a single Access Token would be returned to<br>
>> <a href="http://coolcalendar.com" target="_blank">coolcalendar.com</a> – the Access Token would presumably be good for both<br>
>> “openid” and “calendar” scope. Why would the OP want to return 2 tokens?<br>
>><br>
>> Allen<br>
>><br>
>><br>
>> On 5/19/10 5:27 PM, "Dirk Balfanz" <<a href="mailto:balfanz@google.com">balfanz@google.com</a>> wrote:<br>
>><br>
>><br>
>> Let's say I'm <a href="http://coolcalendar.com" target="_blank">coolcalendar.com</a> <<a href="http://coolcalendar.com" target="_blank">http://coolcalendar.com</a>> , and I want to<br>
>> "connect" one of my user's accounts to his Yahoo! account. I don't want to<br>
>> roll my own auth system, so I'm happy to see that Yahoo! supports OpenID<br>
>> Connect. To connect, I'll send the user over to Yahoo! with<br>
>> scope=openid%20yahoo-calendar. What I get back, in your proposal, is two<br>
>> different kinds of "tokens": the access token that my servers use to access<br>
>> Yahoo! and something I'll call "openid connect token" (which in your<br>
>> proposal comprises a few different parameters - user id, timestamp,<br>
>> signature, etc.) that browsers use (in form of a cookie) to access my own<br>
>> servers at <a href="http://coolcalendar.com" target="_blank">coolcalendar.com</a> <<a href="http://coolcalendar.com" target="_blank">http://coolcalendar.com</a>> .<br>
>><br>
>> Why do those two tokens look different? They serve the same purpose -<br>
>> authenticating access from a client to a server, so they should look the<br>
>> same.<br>
>><br>
>> Why should Yahoo! run different code to authenticate requests coming from<br>
>> my server than the code I'm running on my servers to authenticate requests<br>
>> coming from browsers - we have to solve the same task, so we should run the<br>
>> same code. It's simpler.<br>
>><br>
><br>
><br>
</div></div><div><div></div><div class="h5">> _______________________________________________<br>
> specs mailing list<br>
> <a href="mailto:specs@lists.openid.net">specs@lists.openid.net</a><br>
> <a href="http://lists.openid.net/mailman/listinfo/openid-specs" target="_blank">http://lists.openid.net/mailman/listinfo/openid-specs</a><br>
><br>
><br>
<br>
<br>
<br>
</div></div><font color="#888888">--<br>
--Breno<br>
<br>
+1 (650) 214-1007 desk<br>
+1 (408) 212-0135 (Grand Central)<br>
MTV-41-3 : 383-A<br>
PST (GMT-8) / PDT(GMT-7)<br>
</font></blockquote></div><br></div>